Linux Hadoop集群重启时NameNode报fsimage无对应MD5文件的咨询

针对问题A：报错的具体含义 #

这个报错是NameNode启动时元数据加载校验环节直接失败导致的：

• HDFS的NameNode会把全量文件系统元数据以fsimage镜像的形式，存在你配置的本地目录/home/xxx/tmp/hadoop/name/current/下
• 为了防止fsimage因磁盘损坏、意外篡改出现元数据错乱，HDFS每次生成fsimage时，会同步生成一个同名的MD5校验文件，启动加载时会先比对当前fsimage的哈希值和校验文件是否一致，确认文件完整后才会继续读取元数据
• 现在的报错就是程序在目标目录下，根本没找到和fsimage_0000000000000480607配对的.md5校验文件，直接终止了启动流程，NameNode根本没走到后续的加载步骤。

针对问题B：是否与存在坏块的异常Slave节点相关 #

完全无关。

• NameNode的所有元数据文件（fsimage、edits事务日志、校验文件）都存在Master节点自己的本地磁盘上，Slave节点的datanode只负责存实际的用户数据块，既不参与NameNode的元数据生成、存储过程，也读不到NameNode本地的这些文件。
• 你之前已经试过把坏块Slave摘掉，只留两个节点启动依然报同样的错，这本身就坐实了问题在Master自己的元数据目录上。那个Slave的磁盘坏块只会影响它自己存的数据块可用性，根本碰不到NameNode的启动逻辑。

针对问题C：是否存在无需重新格式化HDFS即可恢复的方案 #

有，完全不需要格式化，操作前只要把整个/home/xxx/tmp/hadoop/name/目录做个全量备份就行，不会损坏原有元数据：

1. 先停掉所有节点上所有正在运行的Hadoop进程，避免文件被占用。
2. 登录NameNode节点，进入元数据存储的current目录：
   cd /home/xxx/tmp/hadoop/name/current/
3. 列目录看文件状态，排查MD5文件缺失的原因：
   • 如果是权限问题导致程序读不到MD5文件，直接把目录下所有文件的权限改成Hadoop运行用户可读即可，不用额外改动。
   • 如果MD5文件确实因为磁盘问题丢了，直接手动生成对应fsimage的MD5校验值就行：
     md5sum fsimage_0000000000000480607 > fsimage_0000000000000480607.md5
     HDFS的校验逻辑很简单，只要这个MD5值和当前fsimage的实际哈希值一致，就能通过校验。
4. 启动NameNode验证：
   • 如果启动后依然报fsimage损坏，说明这个丢MD5的fsimage本身已经因为磁盘问题内容损坏了。这时候只要把这个坏的fsimage文件临时移到目录外的备份位置，保留目录下所有带完整MD5校验的旧fsimage和对应的edits日志就行——NameNode启动时会自动选校验通过的最新可用fsimage，通过回放后续的edits事务日志，把元数据恢复到最后一次提交事务的状态，完全碰不到格式化的步骤。
5. 等NameNode正常起来之后再处理那个坏块Slave：给它换正常的磁盘分区，清空旧的datanode存储目录，重启datanode进程，它会自动向NameNode注册，靠集群的副本机制从其他正常节点同步缺失的数据，不影响集群整体运行。

内容的提问来源于stack exchange，提问作者Eric