集群出现块丢失，块找回，以及相关底层原理，fsck等

红太狼 2023-01-20 14:48 17阅读 0赞

### 1.集群报块丢失的原因？   ###

集群报块丢失的原因很多，如物理磁盘损坏，节点不正常下线退役，集群高负载时如内存打满卡死，网络拥堵，系统本身问题等造成节点掉线，如cdh集群的agent和server失去联系，非正常下线，心跳超时等原因造成yarn界面出现块丢失现象。出现这种现象的底层原理，以及出现这种情况该如何分析，如何应对？

**下图如namenode界面出现提示块丢失**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70][]

**后台监控到的hdfs图标**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 1][]

### 1.集群报块丢失的原理？ ###

要想弄明白快丢失的原理，首先要弄明白下面的知识点

**1. datanode与namenode的通信**

**    所有Datanode会定期向Namenode汇报自身所保存的文件block信息，而namenode则会负责保持文件的副本数量满足配置（dfs.replication，默认是3，我们公司是2），根据datanode汇报结果进行删除多余块以及复制副本不足的块等操作。**

**2. 心跳机制的作用**

**     datanode通过心跳机制与namenoe进行通信，默认是dfs.heartbeat.interval=3s与namnenode通信一次，也是通过心跳机制接受任务等。当namenode连续10次（30s）没有收到datanode的心跳报告，会判断datanode可能异常，如出现死亡。此时namenode会主动向datanode主动发送一次检查，发送一次检查的时间是5分钟（默认dfs.namenode.heartbeat.recheck-interval=300000 单位ms）。这个时候如果namenode与datanode通信还是异常，没有应答，则namenode会继续重试一次。如果第二次仍读取不到datanode信息，则namenode会判定该datanode死亡。合计时间也就是5min\*2+30s=10min30s。**

**3.datanode块汇报机制**

**      datanode块汇报分为两种，IBR（增量块汇报incremental block reports）、FBR（全量块汇报 full block reports ）。DataNode的BPServiceActor线程在datanode启动后会一直执行，持续循环发送heartbeat、IBR、FBR。然后根据增量块汇报会更新各种记录时间的变量用来辅助调用IBR。比如强制触发IBR等 。**

**      IBR: 注意dfs.blockreport.incremental.intervalMsec 默认值是0  。 也就是说只要datanode有如下三种块变动，即可就会向namenode汇报：1.接受完毕（写完）的块。2.刚刚删除完成的块。3.正在接收（写入）的块。这样的好处是元数据维护的及时更新，坏处是过多的RPC请求会增加namenode的负载（因为更新元数据的锁机制）。如果公司集群单namenode，负载很高的话，可以适当将这个值调整一些比如200ms，实现datanode的IBR延时汇报，这样datanode可以在间隔时内积攒的所有block一次提交给namenode,进而降低namenode的负载。**

**     FBR:上面说了IBR是针对增量块的变动汇报。datanode的上block的元数据信息，如block位置，block的状态等信息都存放在内存中。每隔6个小时，datanode会进行一次Directory Scanners（具体参数：**dfs.datanode.directoryscan.interval =21600**），通过Directory Scannners检查内存中block信息和磁盘上实际存储的block一致性情况。当Directory Scanners发现block文件、meta文件丢失时，或者多余时（即和磁盘存储的结果不一致的那些block），会将block标记为corrupted/**i**nvalidates等，datanode然后在下一次汇报中（3s心跳机制），将这个块汇报给namenode。注意Directory Scanners只检查finalized状态的block（增量block不管）。因为FBR给namenode的压力太大，尤其对于几亿blocks的大集群来说，所以每个datanode的全量块汇报是在6个小时内逐步完成的（多批次）。这样的结果就是节点非增量块的丢失一般极限的话要6个小时后namenode才会感知，并且通知到用户。**

### 2.块丢失后如何分析与处理？ ###

**2.1.块报丢失实际并没有丢失**

A:**生产中某个节点磁盘突然坏盘**

**          **datanode会向namenode汇报block corrupted,namenode提示block corrupted。这个时候如果集群是双副本，突然单节点坏盘是不会出现两个副本丢失的情况，这个时候namenode提示的blocck corrupted可以不用管的，最多等6个小时全量块汇报完成后，就会找回。但是如果是多个节点多个磁盘出现同时损坏，有可能造成数据永久丢失（恰好某个block的所有的副本所在的磁盘都损坏了）。超过6个小时如果没有找回，基本就是真的丢失了。具体进度可以参考hdfs的监控图标，如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 2][]

**     B:节点掉线超过10分30秒（如agent掉线，主机内存打满卡死，rpc请求拥堵等）**

**         这种情况也是namenode检测到节点掉线，会启动副本机制补足该节点上的所有副本，这个时候很容易出现RPC风暴，对于网络带宽也是个很大的挑战。这种如果集群3副本机制，同时掉线两台也不会出现真正数据丢失；同理集群是2副本的话，同时出现一台异常，也不会真的数据丢失。一般这种情况被动的做法是等待6小时，等待完成全量块汇报找回结果。如下出现节点掉线后的带宽监控，网络风暴**![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 3][]

**2.2 块丢失是真的丢失**

**       通常情况namenode可以恢复绝大多数故障。如果是正好3个副本都同时出现物理永久丢失（注意：如3个副本所在节点同时故障掉线，这种情况即使超过6小时全量块汇报后仍然显示丢失，但等这三个节点重新上线后数据依旧可以找回，多余块会被删除。但如果是这个三个节点的同时坏盘，数据不可修复的那种，数据通过修复块或者汇报的方式不可找回）这种情况下，只能通过重跑任务，重新生成数据了。**

### 3.fsck命令的使用 ###

HDFS支持fsck命令来检查各种块不一致情况。它设计用于报告各种文件的问题，例如，文件缺少的块或复制不足的块。**但是注意fsck不检查正在打开的文件，即正在写入的文件。fsck主要就是用来检查文件系统的健康状态，以及定位问题的。**

<table> 
 <thead> 
 <tr> 
 <th>COMMAND_OPTION</th> 
 <th>Description</th> 
 </tr> 
 </thead> 
 <tbody> 
 <tr> 
 <td>path</td> 
 <td> hdfs fsck 后面跟的path是需要fsck检查的文件目录，或者文件路径如 hfds fsck&nbsp; /user/hive/warehouse/aaa.db/，这个path是必须带的，最简单也得是/ 用来检查文件系统的健康状态 </td> 
 </tr> 
 <tr> 
 <td>-delete</td> 
 <td> 这个参数用来删除指定目录下的损坏块，一般用来删除不可恢复的块。这种情况要想让块丢失提示消失，使用这种方式。 它会删除所有损坏的块的数据文件，会导致数据彻底丢失 </td> 
 </tr> 
 <tr> 
 <td>-files</td> 
 <td> Print out files being checked. 输出正在被检测的文件 </td> 
 </tr> 
 <tr> 
 <td>-files&nbsp;-blocks</td> 
 <td>Print out the block report 输出block的详细报告 </td> 
 </tr> 
 <tr> 
 <td>-files&nbsp;-blocks&nbsp;-locations</td> 
 <td> Print out locations for every block. 输出block的位置信息 </td> 
 </tr> 
 <tr> 
 <td>-files&nbsp;-blocks&nbsp;-racks</td> 
 <td> Print out network topology for data-node locations. 输出文件块位置所在的机架信息 </td> 
 </tr> 
 <tr> 
 <td>-files&nbsp;-blocks&nbsp;-replicaDetails</td> 
 <td>Print out each replica details.</td> 
 </tr> 
 <tr> 
 <td>-files&nbsp;-blocks&nbsp;-upgradedomains</td> 
 <td>Print out upgrade domains for every block.</td> 
 </tr> 
 <tr> 
 <td>-includeSnapshots</td> 
 <td>Include snapshot data if the given path indicates a snapshottable directory or there are snapshottable directories under it.</td> 
 </tr> 
 <tr> 
 <td>-list-corruptfileblocks</td> 
 <td>Print out list of missing blocks and files they belong to.常用，打印出所有坏块的信息，比如进行补数据等。因为namenode界面显示是不完整的。</td> 
 </tr> 
 <tr> 
 <td>-move</td> 
 <td>Move corrupted files to /lost+found.</td> 
 </tr> 
 <tr> 
 <td>-openforwrite</td> 
 <td>Print out files opened for write.</td> 
 </tr> 
 <tr> 
 <td>-showprogress</td> 
 <td>Deprecated. A dot is print every 100 files processed with or without this switch.</td> 
 </tr> 
 <tr> 
 <td>-storagepolicies</td> 
 <td>Print out storage policy summary for the blocks.</td> 
 </tr> 
 <tr> 
 <td>-maintenance</td> 
 <td>Print out maintenance state node details.</td> 
 </tr> 
 <tr> 
 <td>-blockId</td> 
 <td>Print out information about the block.</td> 
 </tr> 
 </tbody> 
</table>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70]: /images/20221021/b3a44275bc8040b48e6c6c1b21a9baaa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 1]: /images/20221021/255ee665515d41bdbed2cf96abefcd58.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 2]: /images/20221021/a443099a455c4d07b9a08941fbc206c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2NDQyNTUz_size_16_color_FFFFFF_t_70 3]: /images/20221021/1a10e638cd53430d8edfef8b65e97b8d.png