优先考虑方案！！！
如果hadoop ha情况下有一台是正常的activate
修复 Edit Log 问题：
如果 nn3 无法恢复，可以尝试从 nn2（当前 Active NameNode）同步数据。
在 nn1 上执行以下命令，强制从 nn2 同步数据：
BASH
hdfs namenode -bootstrapStandby
然后重启 nn1：
BASH
hdfs --daemon start namenode
===================================================
1.cd /tmp/hadoop/dfs/
2.所有节点的journalnode都备份一下(不用新建journalnode,万一没解决恢复原样)
mv journalnode journalnode.bak
3.删除掉所有目录的journalnode （最稳妥 ）
rm -rf /tmp/hadoop/dfs/journalnode/djcluster
4.重新格式化 NameNode （记得先启动journalnode）
hdfs namenode -initializeSharedEdits
5./tmp/hadoop/dfs/目录下就会自动生成journalnode
6.启动集群start-all.sh
hdfs namenode -initializeSharedEdits
将所有journal node的元文件的VERSION文件的参数修改成与namenode的元数据相同
hdfs namenode -bootstrapStandby
将active namenode的 {dfs.namenode.name.dir} 目录的内容复制到 standby namenode的{dfs.namenode.name.dir} 目录下
通过代码可以看到当流里面没有数据或者流里面的第一个txid大于你传进来的值，都会跳出循环，跳出循环后将会抛出一个IOException，即是我们上面截图所报的异常；
最好是退役旧节点之后在操作
拷贝 /data/module/hadoop-3.1.3/tmp/dfs/name
以及 /tmp/hadoop/dfs/journalnode 到新机器上
FSImage
Namenode会将HDFS的文件和目录元数据存储在一个叫fsimage的二进制文件中，每次保存fsimage之后到下次保存之间的所有hdfs操作，将会记录在editlog文件中，当editlog达到一定的大小（bytes，由fs.checkpoint.size参数定义）或从上次保存过后一定时间段过后（sec，由fs.checkpoint.period参数定义），namenode会重新将内存中对整个HDFS的目录树和文件元数据刷到fsimage文件中。Namenode就是通过这种方式来保证HDFS中元数据信息的安全性；
Fsimage是一个二进制文件，当中记录了HDFS中所有文件和目录的元数据信息；
hdfs --daemon start journalnode
当NN启动时，Hadoop将加载fsimage并应用所有编辑日志，同时进行大量的一致性检查，如果检查失败，它将中止；
解决方法：
1 在hadoop的目录下执行指令 bin/hadoop namenode -recover;
2 选择yes 然后选择C，再选择C;
3 重新启动namenode节点
刷新NameNode
[atguigu@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes
Refresh nodes successful
2）开启数据均衡命令：
[atguigu@hadoop105 hadoop-3.1.3] sbin/stop-balancer.sh
