盘点下常见 HDFS JournalNode 异常的问题原因和修复方法
盘点下常见 HDFS JournalNode 异常的问题原因和修复方法
最近在多个客户现场以及公司内部环境，都遇到了因为 JournalNode 异常导致 HDFS 服务不可用的问题，在此总结下相关知识。
1 HDFS HA 高可用和 JournalNode 概述
HDFS namenode 有 SPOF 单点故障，因为对客户端提供元数据读写服务的是单一的一个 NameNode，Secondary NameNode 仅仅提供了 HDFS 故障时的可恢复性，而没有提供整个 HDFS 服务的高可用性；
之所以说 Secondary NameNode 仅仅提供了 HDFS 故障时的可恢复性而不是高可用性，是因为 HDFS 发生故障时，Secondary NameNode 并不会自动晋升为 nameNode, 运维管理员需要介入进行手动处理后才能恢复 HDFS 对外服务；
在底层，Secondary NameNode 提供了 fsimage 和 editLog 的合并功能（old fsimage + edit logs = new fsimage），这一过程称为 checkpoint，是基于参数 dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns，按照时间和事件共同触发的;
为解决 HDFS NAMENODE 的 SPOF，可以配置启用 HDFS 的 HA 高可用，此时其架构如下，可以看到包括 active 与 standby 两个 namenode 互为主备，包括奇数个 zkfc 基于 zk 提供 nn 的故障检测和自动转移，包括奇数个 JournalNode 提供两个 nn 之间共享 editLogs;
Active Namenode 与 StandBy Namenode 为了同步 editLog 状态数据，会通过一组称作 JournalNodes 的独立进程进行相互通信: 当 active 状态的 NameNode 的命名空间有任何修改时，Active Namenode 会向 JournalNodes 中写 editlog 数据, 而 StandBy Namenode 会一直监控 JournalNodes 中 editLog 的变化，并把变化应用于自己的命名空间，从而确保两者命名空间状态的同步和一致，当 Active Namenode 故障出错时，standby Namenode 就可以不丢失数据地实时晋升为 Active Namenode 对外提供服务；
HDFS HA 的详细架构图如下：
HDFS NN 存储元数据信息的本地文件系统目录结构和关键文件如下：
HDFS JN 存储元数据信息的本地文件系统目录结构和关键文件如下：
2 HDFS JournalNode 异常的常见原因
从上述分析可知，HDFS HA 的正常工作依赖于 JournalNode 的正常工作，当集群中半数以上的 JournalNode 节点发生异常后，HDFS HA 就无法正常工作了；
由于 JournalNode 如此重要，绝大部分的大数据集群管理软件如 ClouderaManager/Ambari 等，都会监控 JournalNode 并在其异常时发送告警通知；
如下即是 ClouderaManager 对 JN 同步状态和磁盘空间常见的的监控报警信息：
造成 HDFS JournalNode 异常的常见原因有：
JournalNode 节点的本地磁盘故障或磁盘满，导致写入的 editLog 数据异常；
JournalNode 节点异常并重装了操作系统；
出于扩展集群的需求，新增了 JournalNode 节点；
3 HDFS JournalNode 异常的常规修复方法
HDFS JournalNode 异常，大体应该遵循如下逻辑进行修复：
准备工作：确定当前可以正常工作的 JournalNode 节点，其 editLog 文件的存放位置(即参数 dfs.journalnode.edits.dir 的值),以及当前最新的 editLog 文件 （各个节点各个 editLog 文件的文件名中都包含了递增的 sequence number 序列号，比如历史 editLog 文件 edits_0000000000056586378-0000000000056586407 和 当前 editLog 文件 edits_inprogress_0000000000056586408，序列号最大的即是最新的 editLog 文件）；
停止 HDFS 集群;
删除 editLog 脏数据：如果是 JournalNode 节点的本地磁盘故障或磁盘满，则修复/更换磁盘或清理磁盘空间，并删除已经写入的异常的 editLog 文件（也可以删除 dfs.journalnode.edits.dir 目录下的所有子目录和文件，包括 VERSION 文件, edits 文件等；删除前建议先备份）；
恢复 editLog 数据：从当前可以正常工作的 JournalNode 节点，拷贝其正常的 editLog 数据文件，可以拷贝 dfs.journalnode.edits.dir 目录下的所有子目录和文件，包括 VERSION 文件, edits 文件等 （事实上只拷贝 VERSION 文件和最新的 editLog 文件也可以，此时后续启动 JournalNode 后，会自动拷贝其它历史 editLog）；
确保拷贝过来的所有文件的用户和用户组是 HDFS：chown -R hdfs:hdfs ./*;
启动 HDFS 服务，查看日志，确保恢复正常;
问题 journalnode 节点修复重启后，自动同步和滚动 editLog 的部分日志如下：
4 HDFS JournalNode 异常修复时遇到的常见问题
JournalNotFormattedException：即 Journal 未格式化异常，这种错误经常出现在重装 Journal 节点操作系统时，或添加新 Journal 节点时，修复方法为从其它正常 Journal 节点拷贝 VERSION 文件即可，详细报错如下:
editLog 过期损坏异常：这种错误经常出现在某个 Journal 节点因磁盘异常或其它原因，长期没有跟其它 Journal 节点同步 editLog 数据，导致其最新的 editLog 文件（即 edits_inprogressxxx 文件）过期异常，修复方法为按照上述步骤，删除其异常的 edits_inprogressxxx 文件或全部的 editLog 文件，然后重启 Journal 角色即可（重启后会自动从其它正常 Journal 节点拷贝 editLog 文件）,详细报错如下:
/dfs/jn/ns1/in_use.lock 文件锁异常：这种错误经常出现在目录 /dfs/jn 或其子目录和文件的 owner/group 不是 JournalNode 进程的启动用户（一般是 HDFS:HDFS）,或者异常启动了多个 JournalNode 进程， 修复方法为更改 /dfs/jn 目录及其子目录和文件的 owner/group 为 JournalNode 进程的启动用户，（chown -R hdfs:hdfs /dfs/jn）并重启 JournalNode 服务进程，详细报错如下:
版权声明: 本文为 InfoQ 作者【明哥的IT随笔】的原创文章。
原文链接:【http://xie.infoq.cn/article/0d8832a2886e3d0be7d2e5446】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
Keep Striving! 2018-04-25 加入
明哥，十四年 IT经验，六年大数据经验； 做过大数据集群的搭建运维，大数据应用系统的开发优化，也做过大数据平台的技术选型以及架构咨询； 目前聚焦于泛大数据生态，包括数据仓库/数据湖，云计算和人工智能。
评论