journal 重启_集群JournalNode服务重启导致NameNode挂掉分析

温馨提示：如果使用电脑查看图片不清晰，可以使用手机打开文章单击文中的图片放大查看高清原图。

Fayson的github：

https://github.com/fayson/cdhproject

提示：代码块部分可以左右滑动查看噢

1.问题描述

在我们的集群中修改了JournalNode服务的配置后需要重启时配置生效，在进行重启操作时导致NameNode服务挂掉，具体操作步骤如下：

1.选择sgpd229-013节点的JournalNode服务重启

2.在sgpd229-013节点的JournalNode服务启动成功后，重启剩余两个节点的JN服务

3.重启成功剩余两个节点的JournalNode服务后，CM界面报NameNode服务异常退出

4.所有JournalNode服务正常启动后，重启NameNode服务，故障恢复

2.异常分析

1.在2018-07-26 09:55:19分重启sgpd229-013节点的JournalNode服务

2.重启成功后，NameNode的异常日志如下，此时NameNode的服务均正常

通过NN服务的日志可以看到此时sgpd229-013节点的NN服务无法连接sgpd229-013节点的JN服务，但NN服务任然正常运行，因为sgpd229-012和sgpd229-014节点的JN服务正常。

3.待sgpd229-013节点的JN服务正常后，接着在CM上同时重启sgpd229-012和sgpd229-014节点的JN服务

重启成功后，此时sgpd229-012节点的NameNode服务异常退出，异常日志如下：

通过日志可以看到NN显示无法连接sgpd229-012和sgpd229-014节点的JN服务，此时NN服务判断JN服务不可用，直接SHUTDOWN，导致NameNode服务异常退出。

3.总结

1.在高可用的Hadoop集群中，JN服务至少要有两个在正常运行，否则会导致NameNode服务异常退出。在Fayson的这个异常分析中就出现了同时重启两个JN服务从而导致NameNode服务异常退出。

2.在启用HDFS的HA时，部署JN服务时不能少于3个。

3.在集群中需要注意重启JN服务时，则需要确保JN集群至少有两个服务正常运行，建议通过CM的滚动重启来完成。

关于QJM的设计及实现过程，Fayson摘自网上，供大家参考：

实现过程：

(1)初始化后，Active把editlog日志写到2N+1上JN上，每个editlog有一个编号，每次写editlog只要其中大多数JN返回成功(即大于等于N+1)即认定写成功。

(2)Standby定期从JN读取一批editlog，并应用到内存中的FsImage中。

(3)如何fencing： NameNode每次写Editlog都需要传递一个编号Epoch给JN，JN会对比Epoch，如果比自己保存的Epoch大或相同，则可以写，JN更新自己的Epoch到最新，否则拒绝操作。在切换时，Standby转换为Active时，会把Epoch+1，这样就防止即使之前的NameNode向JN写日志，也会失败。

(4)写日志：

(a) NN通过RPC向N个JN异步写Editlog，当有N/2+1个写成功，则本次写成功。

(b) 写失败的JN下次不再写，直到调用滚动日志操作，若此时JN恢复正常，则继续向其写日志。

(c) 每条editlog都有一个编号txid，NN写日志要保证txid是连续的，JN在接收写日志时，会检查txid是否与上次连续，否则写失败。

(5)读日志：

(a) 定期遍历所有JN，获取未消化的editlog，按照txid排序。

(b) 根据txid消化editlog。

(6)切换时日志恢复机制

(a) 主从切换时触发

(b) 准备恢复(prepareRecovery)，standby向JN发送RPC请求，获取txid信息，并对选出最好的JN。

(c) 接受恢复(acceptRecovery)，standby向JN发送RPC，JN之间同步Editlog日志。

(d) Finalized日志。即关闭当前editlog输出流时或滚动日志时的操作。

(e) Standby同步editlog到最新

(7)如何选取最好的JN

(a) 有Finalized的不用in-progress

(b) 多个Finalized的需要判断txid是否相等

(c) 没有Finalized的首先看谁的epoch更大

(d) Epoch一样则选txid大的。