集群JournalNode服务重启导致NameNode挂掉的示例分析

这篇文章主要介绍了集群JournalNode服务重启导致NameNode挂掉的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。

成都创新互联公司是一家专业的成都网站建设公司,我们专注网站制作、网站设计、网络营销、企业网站建设,外链1元广告为企业客户提供一站式建站解决方案,能带给客户新的互联网理念。从网站结构的规划UI设计到用户体验提高,创新互联力求做到尽善尽美。

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服务

集群JournalNode服务重启导致NameNode挂掉的示例分析

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

集群JournalNode服务重启导致NameNode挂掉的示例分析

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

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

集群JournalNode服务重启导致NameNode挂掉的示例分析

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

集群JournalNode服务重启导致NameNode挂掉的示例分析

集群JournalNode服务重启导致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的滚动重启来完成。

集群JournalNode服务重启导致NameNode挂掉的示例分析

集群JournalNode服务重启导致NameNode挂掉的示例分析

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

集群JournalNode服务重启导致NameNode挂掉的示例分析

实现过程:

(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大的。

感谢你能够认真阅读完这篇文章,希望小编分享的“集群JournalNode服务重启导致NameNode挂掉的示例分析”这篇文章对大家有帮助,同时也希望大家多多支持创新互联,关注创新互联行业资讯频道,更多相关知识等着你来学习!


文章标题:集群JournalNode服务重启导致NameNode挂掉的示例分析
转载源于:http://ybzwz.com/article/jjssjh.html