扩容Amazon EMR集群后出现BlockMissingException问题求助

这是个在EMR集群扩容时很容易碰到的HDFS副本管理问题，我来帮你梳理清楚根源和解决办法：

核心原因拆解 #

你的场景里几个关键细节凑到一起，才引发了这个异常：

• 初始集群有3个核心节点，而/user/oozie/share/lib/路径的副本因子设为3——这意味着该路径下每个文件的所有块，3个副本正好分别存在3个核心节点上（每个节点存一个副本）。
• 扩容到5个核心节点后，HDFS默认不会自动触发副本均衡（Balancer是手动触发机制），所以这些块的副本依然只集中在原来的3个节点上。
• 此时如果原来的3个节点中任意一个出现临时故障（比如磁盘IO异常、网络短暂分区、DataNode进程重启），就会导致对应块的可用副本数降到2个，无法满足副本因子3的要求，读取时自然就抛出BlockMissingException。

另外还有一种小概率情况：扩容过程中NameNode的元数据和DataNode的实际块状态出现短暂不一致，比如某个节点的块报告延迟，导致NameNode误以为副本丢失。

具体解决步骤 #

• 第一步：排查节点状态
  先确认所有核心节点的DataNode是否正常运行，用以下命令查看集群节点和磁盘状态：

  hdfs dfsadmin -report
  

  重点看Live datanodes和Decommissioned datanodes部分，有没有节点离线或者磁盘损坏的情况。

• 第二步：定位具体丢失的块
  用fsck命令精准定位/user/oozie/share/lib/下哪些文件的块出了问题：

  hdfs fsck /user/oozie/share/lib/ -files -blocks -locations
  

  这个命令会列出每个文件的块位置、副本数，以及是否有丢失的块，方便你针对性处理。

• 第三步：手动触发副本均衡
  运行HDFS Balancer把副本分散到新加入的节点上，降低旧节点故障的影响：

  hdfs balancer -threshold 10
  

  这里的-threshold 10表示当节点间磁盘使用率差异小于10%时停止均衡，你可以根据集群实际存储情况调整这个阈值。

• 第四步：修复丢失的块
  如果fsck确实检测到有块丢失，有两种高效修复方式：

  • 对于Oozie共享库的jar包，最简单的方式是重新上传对应jar到该路径，HDFS会自动生成3个副本并分布到各个节点；
  • 如果是自定义文件，可以用HDFS的distcp命令从其他可用副本复制到丢失节点，或者等待NameNode自动启动复制任务（它会在检测到副本不足时自动触发）。

预防措施 #

• 集群扩容后，建议自动触发Balancer（比如通过EMR的自定义步骤或者crontab定时任务），避免副本长期集中在旧节点；
• 定期监控DataNode的状态和磁盘健康，及时处理异常节点；
• 可以考虑把/user/oozie/share/lib/的副本因子调整为集群核心节点数的1/2左右，既保证冗余又不会过度浪费存储。

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