【裂开系列】Hadoop集群异常：两个NameNode都处于Standby状态_hadoop 集群中一个节点状态为standby

前言

【写在最前】内容更新范围，欢迎交流进步！

问题分析

  由于测试环境是组内小伙伴学习的途径，都可以操作，暂时无法定位问题。按网上教程，先重启Zookeeper，问题还是存在，想尝试强制切换Namenode Active状态，考虑后果，放弃。
  了解小伙伴是在root用户下启动了Zookeeper集群的slave03节点，果然在Zookeeper的log目录下出现root用户的日志文件，而Zookeeper是部署在hadoop用户下启动，造成hadoop用户下Zookeeper节点与root用户下的节点数据不一致，因为hadoop用户无权限读取root用户下的文件。

问题修复

  既然知道是slave03节点数据存在问题，那么删除数据，从其他节点同步一份数据过来恢复即可，由于是测试环境，直接删除了data和log里的version-2目录(生产环境操作建议先备份)，还是太年轻，踩了个大坑。从其他节点同步过来之后启动，登录./zkCli.sh，并没有其他HA组件的目录，失败了。再提一嘴，Zookeeper保存日志和数据并不是三个节点像hdfs一样是副本，**最新的数据有可能出现在任意一个节点。**下面只能最大可能恢复Zookeeper数据。

Zookeeper数据恢复

  数据恢复首先需要想到数据如何存储。为了保证数据操作的原子性和持久性，Zookeeper也是采用WAL(Write-Ahead-Log)预写日志的方式保证数据的一致性，所以完整数据就会包含两部分：最新日志及合并后的快照。接下来从三个部分介绍Zookeeper数据恢复

1、Zookeeper的事务日志

  事务日志指Zookeeper系统在正常运行过程中，针对所有的更新操作，在返回客户端“更新成功”的响应前，Zookeeper会保证已经将本次更新操作的事务日志已经写到磁盘上，只有这样，整个更新操作才会生效。
  根据上文所述，可以通过zoo.cfg文件中的dataLogDir配置项找到事物日志存储地点：

  在log/目录下存在一个文件夹version-2，该文件夹中保存着事物日志文件:

  从截图中我们可以看出，日志文件的命名规则为log.* *，文件大小为64MB，**表示写入该日志的第一个事务的ID，十六进制表示，这个ID对我们恢复数据非常中重要。

2、Zookeeper的snapshot

  Zookeeper的数据在内存中是以DataTree结构进行存储的，而快照就是每隔一段时间就会把整个DataTree的数据序列化后存储在磁盘中，这就是Zookeeper的快照文件。
Zookeeper快照日志的存储路径同样可以在zoo.cfg中查看，如上文截图所示。访问dataDir路径可以看到version-2文件夹:

  从截图中可以看出，Zookeeper快照文件的命名规则为snapshot.* *，其中**表示Zookeeper触发快照的那个瞬间，提交的最后一个事务的ID。
有了事务日志和snapshot我们就可以最大限度的恢复Zookeeper的数据。

3、zookeeper的数据恢复

1. 分别找到集群中事务id最大的log和snapshot，log和snapshot的后缀名就是事务id，Zookeeper的snapshot是全量数据的snapshot，后缀名表示最后一个写进snapshot的事务id，log的后缀名表示第一个写进事务log的事务id，所以理论上只要拿到最大的事务id的snapshot和log，就可以最大程度的恢复集群的数据。由于集群的性质，最大事务id的snapshot和log很可能不在同一个节点，所以要查看集群的所有机器，备份之前先关掉集群，然后备份这两个文件。

2. 将集群中所有机器的 logs/version-2/和 data/version-2下的所有文件删除。

3. 将备份的文件分别scp到zookeeper集群每一台机器的 log/version-2/和 data/version-2下

4. 启动zookeeper所有节点

5. 重启hadoop，standby问题解决

思考

  理论上Zookeeper出现数据一致性问题，都可以按上述方法执行，但是必须注意先做好备份，本次数据恢复后，还造成HBase无法启动问题，因为Zookeeper恢复数据与HBase本地不一致，这里不展开，谨慎操作。