域名解析反向代理_hadoop2升级的那点事情(详解)

前言

不久前，该公司从.02升级到.4.1。 我记录了升级步骤和遇到的问题，分享给大家。 希望其他人能够少走一些弯路。

技术选型

目前使用版本：

1.0.2

蜂巢0.10

升级目标版本

2.4.1

蜂巢0.13

升级风险点

HDFS升级

其中最重要的升级就是HDFS的升级。 HDFS升级是否成功是升级的关键。 如果升级过程中数据丢失，其他升级将变得毫无意义。

解决方案：

1、备份HDFS的元数据。 升级完成后，对比升级前后的文件信息。

2、升级单机，观察升级前后的块数。

注意：文件数和块数并不完全相同。 和 的计数方法不同，差异可能在2%左右。

纱线升级

Yarn的升级没有HDFS的升级压力大。 不过由于以前用的是Hive，现在直接用的是YARN，所以兼容性问题比HDFS多很多。 幸运的是，我们的任务基本上是使用 Hive，所以我们面临着 hive0.13 和 hive0.10 之间的兼容性问题。

在我们的升级过程中，yarn兼容性问题主要是资源配置错误，兼容性问题并不多。 不过hive升级遇到的兼容性问题比较多，所以在升级过程中，我们更多需要测试的就是hive升级。 问题。

hdfs升级步骤

1.下载.4.1，${}/etc//hdfs-site.xml中dfs..name.dir和dfs..data.dir属性的值指向${}/conf/hdfs-site的分别为.x。 xml中dfs.name.dir和dfs.data.dir的值。

2、升级：/usr/local/2.4.1/sbin/-.sh start –

3、升级：/usr/local/2.4.1/sbin/-.sh start

升级HDFS的时间并不长，比启动集群的时间长2-3倍。 升级过程中几乎不存在数据丢失的风险。 详情请参考代码：

升级：org...hdfs...（如果你想检查你的版本是否可以升级到.4.1，可以查看这里的代码。0.20以上的都可以升级到2.4.1）

升级：org...hdfs...

组织...hdfs...

如果升级失败，您可以随时回滚。 如果回滚，数据将回滚到升级前那一刻的数据。 升级后所有数据修改均无效。 启动回滚的步骤如下：

1、启动：/usr/local/.0.2/bin/-.sh start –

2.启动：/usr/local/.0.2/bin/-.sh start –

hdfs升级遇到的问题

1、block数量过多，启动时做block时，由于rpc调用的字节数限制，导致block失败。

解决办法是修改core-site.xml添加ipc..data。 属性，将值设置为几百兆，根据具体情况进行调整。

2、一百台以上同时启动时会卡顿。 这个问题应该是一个bug。

解决办法就是写一个脚本，然后一一启动。

3. Full GC次数过多。 每次GC发生时，系统会暂停3-4分钟。

由于元数据保存在内存中，因此老年代的压力比较大。 每次执行full gc时，系统都会卡住几分钟。 解决方法如下：

(1). 使用cms gc算法

（2）。 修改新生代和老年代的比例为1:2。 如果是1:4的话，会导致在做ygc的时候大对象直接进入老年代，导致老年代内存快速增长，full gc更加频繁。

4. 超时

使用jdk1.6时，在做SNN时，会超时，导致错误。 不过改成jdk1.7的时候就不会出现超时，也不会报错。

当问题定位到SNN请求的jetty服务器上时，文件传输完成，但Jetty并没有关闭连接，导致SNN读取数据时超时退出。

最终的解决方案是将从 SNN 读取数据的超时时间从默认的 1 分钟更改为 20 分钟。 Jetty会自动关闭连接，SNN读取数据后可以正常退出。 这种方法不是一个优雅的解决方案。 。

5. 突然它运行得很慢。 每隔几秒，rpc 服务器就会卡住 10 秒。

因为接口机启动了一个，注册的时候就获取不到这个意外的。 最致命的是，注册时，底层系统类获取了写锁。 写完锁后，做IP的反域名解析。 此操作最多可能需要 10 秒。

并且注册增加了重试机制。 即使出现错误，也会不断重试，导致服务速度非常慢。

最终的解决方案是杀掉接口机器，但问题的根本原因是HDFS的一个bug，需要修复这段代码：

    org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode
       org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode
       final String message = "hostname cannot be resolved (ip="
          + ip + ", hostname=" + hostname + ")";
       LOG.warn("Unresolved datanode registration: " + message);

如果您怀疑非法连接导致集群缓慢，可以检查日志并查找关键字：

6.HDFS非常慢。 它每天只能存储2TB的数据。 结果，集群中的某些机器具有 100% 的存储容量，但大多数机器的存储非常闲置。

代码重写的方式非常保守，根本无法配置和优化参数，所以只能改代码。

修改 org...hdfs... 从 30 秒到 1 秒。 这样可以大大提高速度。 在我负责的生产环境中，一次迭代通常只需5s即可完成，但再次检测时却要等待30s。 实在是无力抱怨。 。

修改 org...hdfs....run(, p, conf) 并注释掉以下代码

if (!done) {
    Thread.sleep(sleeptime);
}

更多优化请查看org...hdfs...进行优化。

优化后每天只能12TB-20TB左右，勉强满足要求。

继续优化。 优化的根本问题是提高每次迭代的吞吐量。 如果太慢，则是 bug 造成的。 请修改以下代码。

组织...hdfs.....

 (!srcBlockList.isEmpty() || blocksToReceive>0)) {
         PendingBlockMove pendingBlock = chooseNextBlockToMove();
         if (pendingBlock != null) {
+          noPendingBlockIteration=0;//添加这行代码，resetnoPendingBlockIteration,修复bug
           // move the block
           pendingBlock.scheduleBlockMove();
           continue;

错误参考

最后的长ETCH也从2GB修改为300MB（重要，补丁没有这个参数，但是不加的话吞吐量还是无法提升）

优化后吞吐量可达每天64TB。

7、在高可用环境下，会间歇性卡顿，HDFS客户端偶尔会连接，导致HDFS服务偶尔变慢。 经过调查，确定每分钟进行一次合并。 合并过程中，所有服务都会被锁定，导致会出现3秒甚至10秒的间歇性卡顿。

代码问题出在org...hdfs...ha...

错误修复参考

纱线升级步骤

由于使用hive进行任务计算，所以yarn升级非常简单，启动yarn即可。 唯一需要注意的是，升级到yarn后，资源分配方式发生了变化，所以要根据自己的生产环境修改相关的资源配置。 纱线兼容性问题很少。

相反，Hive在任务计算方面遇到的问题更多。 当hive从0.10升级到hive0.13时，语法更加苛刻和严格。 因此，在升级之前，尽量测试一下hive的兼容性。 hive0.13可以在.02上运行。 因此，在升级之前，请将hive升级到hive0.13或以上版本。 如果遇到问题，没有好的解决办法，只是更改hive sql和hive参数。

1yarn 任务速度慢得不合理。 通常，一个应该需要 30 秒的简单任务在 5 分钟内就无法成功运行。 经过跟踪发现启动时同步了初始化（下载jar包和下载作业描述文件）代码。 修改代码，将初始化操作改为并发即可解决问题。

代码问题出在org...yarn...utor。（方法是）

bug修改参考

我只是为了方便查看而复制的。