温馨提示：如果使用电脑查看图片不清晰，可以使用手机打开文章单击文中的图片放大查看高清原图。
Fayson的github：
提示：代码块部分可以左右滑动查看噢
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大的。
提示：代码块部分可以左右滑动查看噢
为天地立心，为生民立命，为往圣继绝学，为万世开太平。
温馨提示：如果使用电脑查看图片不清晰，可以使用手机打开文章单击文中的图片放大查看高清原图。
推荐关注Hadoop实操，第一时间，分享更多Hadoop干货，欢迎转发和分享。
原创文章，欢迎转载，转载请注明：转载自微信公众号Hadoop实操