HDFS罢工

Posted 2021-04-14 下士闻道之每日必读

HDFS罢工

hdfs罢工，通过hadoop fs -ls /等操作均长时间无响应；查看NameNode的日志发现大量的如下日志：

2017-01-05 11:33:45,923 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Recovering [Lease.  Holder: libhdfs3_client_random_511975289_count_1_pid_776687_tid_140094310148128, pendingcreates: 1], s

rc=/hawq_data/gpseg14/16385/76836054/79884472.1

2017-01-05 11:33:45,923 INFO org.apache.hadoop.hdfs.server.namenode.LeaseManager: [Lease.  Holder: libhdfs3_client_random_511975289_count_1_pid_776687_tid_140094310148128, pendingcreates: 1] has expired h

ard limit

原因是因为hdfs有大量的操作租约到期，发生了大量的恢复（recovering）操作导致了HDFS宕机。

解决办法：

关掉NameNode进程；

重启并严禁应用访问；

观察一小时后，使用下面的命令看看是否有OPENFORWRITE：

hdfs fsck -files -blocks -locations -openforwrite | grep OPENFORWRITE

如果没有，则系统已经正常；如果还有则：

把OPENFORWRITE的文件统一移动（mv指令）到hdfs上面一个临时文件夹；然后再从临时文件夹拷贝（cp指令）回去即可

问题解决。

但是这里有问题，从日志来看是租约（lease）到期，这是个什么玩意儿？

当HDFS cllient向Master发出写请求的时候，将会别分配一个租约，因为HDFS遵从了文件的访问模式：多读者-单写者模式（multi-reader, single-writer semantics），避免大量的客户端访问hdfs造成资源争抢；1分钟是软租约（soft lease），一小时是硬租约（hard lease），所谓软租约是指三分钟之后其他客户端可以强制获得你的租约，硬租约是指hdfs将会直接断掉和你的链接。所以如果是长时间的操作，hdfs client记得要续约啊。

日志里面出现的“Recovering”（恢复）是怎么回事？recovering一般都是伴随着租约到期，因为租约到期后，会被链接会被回收，如果此时文件数据还在replication，写副本将可能会被中断，这个时候就需要恢复。版本恢复也是分三种情况，分别是租约恢复（lease recovery），block的恢复，pipeline的恢复。

租约恢复的流程就是获取新的Generation Stamp（GS），然后更新DatNode的GS，通知Namenode更新完成，NameNode将会clouse该文件之前的client（的TCP链接）；lease recovery其实就是将租约给重新释放出来，和数据库连接池回收链接一样；但是在lease recovery的时候将会发生block recovery，block recovery必然是发生在lease recovery的；确保replication是完整的（确保途中replica 1和replica2数据传输完毕）。

这些恢复都是有连续状态的；但是恢复同样耗费资源；上面的问题就是因为大量的租约到期导致租期恢复引发的性能问题；解决方式很简单，因为DataNode的状态是会被保存，但是NameNode的状态不会被保存，当NameNode重启之后，之前的很多异常状态会被认为是正常。

对于pipleline（多副本流程） recovery稍微复杂了一些：首先要明白pipeline分为三个阶段，setup， streaming（客户端调用hflush）以及clouse，pipeline需要恢复就是因为Client发现某个节点的DataNode发生异常。

在setup阶段的恢复，如果是新文件，则通过访问NameNoe获取新的pipeline；如果是append到既存文件中，则继续向好用的DataNode写；

在streaming阶段的恢复将是在原有的pipeline中将有故障的DataNode排除，然后从头再把文件向无故障的节点发放；对于之前已经接受过的文件片，DataNode将会忽略。

在close阶段恢复，从原有的pipeline中将有故障的DataNode排除，好的DataNode继续设置自己的状态为finalize。

所以可以看到，一旦文件写入了，形成了block-replica1-replica2...这样一条链，才去的策略就是从链中剔除掉坏的节点，好的节点继续；不过，在这三个阶段都隐含了一个操作：在恢复之初将会向NameNode申请一个新的Generation stamp（GS）；在恢复过程中将会更新各个节点的GS。

什么是GS，GS是一个八位的单调递增的数据，可以理解类似于时间戳的东西，他的主要作用是记录块和副本之间的同步关系。

1）如果副本的GS比块的副本要小，说明，这个副本可能因为某个原因之前的某次append被跳过了；

2）还有一种可能就是某个副本下线了很长时间，后来又回来了。

http://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/

http://blog.cloudera.com/blog/2015/03/understanding-hdfs-recovery-processes-part-2/

https://discuss.pivotal.io/hc/en-us/articles/115002177727-NameNode-is-Unresponsive-and-Streaming-Recovering-Lease-Messages