standby 节点报错 Encountered exception loading fsimage 加载fsimage时遇到异常

关键：Encountered exception loading fsimage 加载fsimage时遇到异常

排查路径

dfs.namenode.name.dir目录

1、确保宽握Active NameNode是正常工作，不要从Active NameNode节点/hadoop/hdfs/namenode目录下拷贝任何数据到Standby NameNode.

2、物唯在Standby NameNode节点上执行

hdfs namenode -bootstrapStandby

Allows the standby NameNode's storage directories to be bootstrapped by copying the latest namespace snapshot from the active NameNode. This is used when first configuring an HA cluster.

该命令会恢复Standby NameNode节点的元数罩巧培据

3、通过Ambari启动Standby NameNode

4、通过Ambari重启ZKFailoverController

1、关闭整个集群，确认服务均已关闭

2、拷贝current数据至故障NN

scp -r root@xx.xx.40.32:/export/hadoop/hdfs/namenode/current .

3、授权

chown -R hdfs.hadoop current

4、删除/tmp 目录下的临时文件

5、重启集群

NameNode主要是 用来保存HDFS的元数据信息，比如命名空间信息，块信息等 。当它运行的时候，这些信息是 存在内存中 的。但是这些信息也可以持久化到磁盘上。

上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件：

fsimage - 它是在NameNode启动时对整个 文件系统的快照

edit logs - 它是在NameNode启动后，对 文件系统的改动序列

只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。在这种情况下就会出现下面一些问题：

edit logs文件会变的很大，怎么去管理这个文件是一个挑战。

NameNode的重启会花费很长时间，因为有很多改动[笔判首者注:在edit logs中]要合并到fsimage文件上。

如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。

因此为了克服这个问题，我们需要一个 易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。 这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么，这些跟Secondary NameNode又有什么关系呢？

Secondary NameNode

SecondaryNameNode就是来帮助解决上述问题的，它的 职责是合并NameNode的edit logs到fsimage文件中。

这里写图片描述

上面的图片展示了Secondary NameNode是怎么工作的。

首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode自己的fsimage]

一旦它有了新的fsimage文件，它 将其拷贝回NameNode中 。

NameNode在下次重启时会使用这个新的fsimage文件， 从而减少重启慎激的时间 。

Secondary NameNode的整个 目的是在HDFS中提供一个检查点 。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

现在，我们明白了宽冲袜Secondary NameNode所做的不过是在文件系统中设置一个检查点 来帮助NameNode更好的工作 。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。

该 *** 作基本只和NameNode进行交互

NameNode在目录树数据结构上对应位置创建新的目录节点并持久化到日志中。

NameNode标记需要删除的文件激兆并且持久化到日志中，等到DataNode提交心跳的时会获取到删除的命令，之后DataNode执行该删除指令，此时数据才会真正的被删除。

重复2，3步

读取完毕后关闭输入流

2，3步对Client是透明的，实际是由DFSInputStream来进行的，Client是仅跟DFSInputStream进行交互

在读取的时候会同时获取数据以及数据校验和进行校验数据的一致性，若是校验错误则报告给NameNode，并尝试从别的数据节点中读取另外一个副本的文件内容。让客户端来进行校验可以降低数据节点的负载，均衡各节点的计算能力

如果读取的时候数据节点发生错误，那么Client会尝试读取下一个数据块的位置并且记住故障的数据节点并不再进行尝试。

NameNode并不会一次性返回所有数据块的信息，每次仅返回一组数据块的信息

若是写的时候有数据节点故障，则

① 数据流写通道关闭

② 已经发送到管道却还没收到ack的数据会被添加到输出队列

③ 当前正常工作的DataNode上的数据块（指正在写的这个块）会被赋予一个新的版本号并报告NameNode，故障的DataNode恢复过来的时候会因为数据块版本号跟NameNode保存的版本号不一致而被删除。

④ 数据流管道中删除错误DataNode，重新建立管道并继续写数据到正常的DataNode

只要成功写入的副本数满足dfs.replication.min（默认1）的值，则认为写 *** 作是成功的。后续这个数亏纤据块会被复制，直到满足文件的副本系数要求。

Client对文件系统的目录树进行修改的 *** 作都会被NameNode记录在编辑日志里，保证出现故障的时候可以快速恢复。为了避免编辑日志过大销铅仿导致恢复时间过长，HDFS引入了检查点机制（fsimage）

fsimage是文件系统元数据的持久性检查点

NameNode与DataNode的交互

NameNode需要只需要准备一个DatanodeCommand数组，里面存放各种 *** 作指令。在DataNode提交心跳的时候会拉取该数组回去并且执行里面的 *** 作指令。

---