Hadoop HA:active节点失效后standby 节点无法被拉起

被这个问题困扰很久,网上也查不到类似的问题;因此记录下来希望帮到其他小伙伴

当然也是因为我话多/困扰太久/解决后太兴奋/想嘚瑟/想锻炼下表述能力/加深理解/整理思路/记性太差怕忘记等诸多原因。。。

第一次写,写得不好还请见谅(当然这是我的托辞,下次要是还写不好我也能找出其他理由)

另外,如果有错误或表述不清的地方还请指正;


所以我们现在开始正题:


hadoop集群结构:

Cluser结构;两台namenode;一主一备

使用JournalNode+zookeeper(※)实现HA

※:

JournalNode:

用于同步namenode(active&standby)间的数据;

Zookeeper:

用于监控namenode状态;若发现active节点异常;则将standby状态切换到active状态


错误现象:

将主备namenode都启动;kill掉active机上的namenode进程后;standby主机的状态并没有变成active

即active节点崩坏后,standby并没有被自动切换为active


调查过程:

首先想到可能是负责实现HA的以下两个应用出了问题:

1)JournalNode(比如某些原因导致standby无法获得active的数据)

2)Zookeeper

于是清空hadoop安装目录下的日志;重现了一下错误现象;

1)hadoop安装目录下并无日志产生(active和standby均没有)

因此可以排除是journalnode同步失败引起(journalnode同步有错的话会报在该日志中)

2)zookeeper下没有事务日志产生

(PS:事务日志产生在配置文件zoo.cfgd的dataLogDir下,而安装目录下的log中产生的是运行日志);

3)输入命令zkCli.sh连接zookeeper Server命令行输入ls /,确认是否有hadoop ha目录生成(--有)

4)2),3)可以排除故障并非zookeeper不作为引起


调查陷入胶着状态;

于是转而继续研究hadoop HA的实现原理,希望能获得些思路;

调查过程中发现hadoop进行HA切换时会有一种避免脑裂(brain split)的机制:

以下援引博客中查到的相关信息:

[4.如何在状态切换时避免brain split(脑裂)?

脑裂:active namenode工作不正常后,zkfc在zookeeper中写入一些数据,表明异常,这时standby namenode中的zkfc读到异常信息,并将standby节点置为active。但是,如果之前的active namenode并没有真的死掉,出现了假死(死了一会儿后又正常了,哈哈,是不是很搞笑),这样,就有两台namenode同时工作了。这种现象称为脑裂。

解决方案:standby namenode感知到主用节点出现异常后并不会立即切换状态,zkfc会首先通过ssh远程杀死active节点的 namenode进程(kill -9 进程号)。但是(这样还不行,惊讶),如果kill指令没有执行成功咋办??如果在一段时间内没有收到执行成功的回执,standby节点会执行一个自定义脚本,尽量保证不会出现脑裂问题!这个机制在hadoop中称为fencing(包括ssh发送kill指令,执行自定义脚本两道保障)]

从解决方案中可知;当发生active节点崩坏时;hadoop会进行以下两个操作:

1)通过ssh kill掉active节点的namenode进程

2)执行自定义脚本

于是查看目前hadoop集群的配置文件hdfs-site.xml中相关属性

dfs.ha.fencing.methods

dfs.ha.fencing.methods

shell(/bin/true)

只配置上述解决方案中的2)自定义脚本;于是猜测是否为缺少ssh相关配置;导致防脑裂机制的流程有误因此standby没有被拉起来

于是追加了ssh相关设置:


Hadoop HA:active节点失效后standby 节点无法被拉起_第1张图片

重新进行kill active上的namenode试验;成功;

active挂掉后standby可自动被拉起成active节点;实现了高可用性


呃……当然为什么这么修改之后问题就解决了;究竟后台运作是什么机制,是不是就如同我的设想其实我也不是特别明白。。。

但可以肯定的是问题点就在这里;重新配置后问题解决了。。。。。

有知道的小伙伴还请不吝指教~

你可能感兴趣的:(Hadoop HA:active节点失效后standby 节点无法被拉起)