本文汇总了 HDFS 使用时的常见问题。

NameNode服务重启时特别慢。

• 现象描述：在整体运转正常的 HDFS 集群中，重启了 NameNode 服务，结果发现 NameNode 重启耗时特别长（超过 10 分钟），始终处于加载 FsImage 和 EditsLog 文件的状态，在此期间 NameNode 一直是“safeMode on ”状态。
• 原因剖析：由于 NameNode 启动时加载 FsImage 和 EditsLog 会占用大量内存，并且 NameNode 只有加载完最新的 FsImage 和之后所有的 EditLog 文件之后，才会脱离安全模式。
• 解决方案：推荐在 HDFS 的配置文件中增大 NameNode HeapSize，以加快元数据文件的加载进程。

如何处理Missing Blocks 或Corrupted Blocks问题？

• 现象描述：在使用 fsck 命令查看 hdfs 文件系统的健康状态时，会提示 Missing Blocks 或 Corrupted Blocks 。
• 原因剖析：当出现 DataNode 服务停止、磁盘损坏、或异常操作等情况时，都会造成数据丢失。
• 解决方案：倘若有 DataNode 服务停止，请将其重新启动。要是磁盘损坏或异常操作致使数据丢失，需要进行人工恢复，您可以通过 hdfs fsck / -files 命令扫描损坏的文件，导出文件列表，删除后重新上传。

NameNode的元数据目录中有大量的Editslog文件

• 现象描述：NameNode 节点数据目录占用磁盘空间较大，存在大量的 Editslog 文件。
• 原因剖析：查看 Secondary NameNode 的健康状态，发现其服务不正常，致使 Editslog 文件未能及时合并。该服务不正常可能是内存不足所致。
• 解决方案：适当调整 Secondary NameNode 的 HeapSize，以使其正常启动。

集群外读写HDFS

• 现象描述：集群外无法对 HDFS 数据进行读、写、删操作
• 原因剖析：当 HDFS 客户端访问 HDFS 时，从 NameNode 获取的元数据信息中包含了 DataNode 地址，该地址默认是内网 IP。由于集群外与内网 IP 无法通讯，所以无法读写删除 HDFS 数据。
• 解决方案：
  • 通过专线、VPN 等方式打通集群外客户端与集群内网的网络。
  • 将 HDFSDataNode 绑定公网 IP，并将 dfs.client.use.datanode.hostname 配置为 true，此时返回的 DataNode 地址为主机名。然后配置 HDFS 客户端的 /etc/hosts，将主机名映射到公网 IP 即可。