Hadoop中Namenode单点故障的解决方案

Hadoop中Namenode单点故障的解决方案

需求：

实现namenode元数据的备份，解决namenode单点宕机导致集群不可用的问题。

方案描述：

当namenode所在服务器宕机的时候，我们可以利用namenode备份的元数据迅速重构新的namenode来投入使用。

1.Hadoop本身提供了可利用secondarynamenode的备份数据来恢复namenode的元数据的方案，但因为checkpoint(在每次 checkpoint的时候secondarynamenode才会合并并同步namenode的数据)的问题，secondarynamenode的备份数据并不能时刻保持与namenode同步，也就是说在namenode宕机的时候secondarynamenode可能会丢失一段时间的数据，这段 时间取决于checkpoint的周期。我们可以减小checkpoint的周期来减少数据的丢失量，但由于每次checkpoint很耗性能，而且这种方案也不能从根本上解决数据丢失的问题。所以如果需求上不允许这种数据的丢失，这种方案可直接不予考虑。

2.Hadoop提供的另一种方案就是NFS，一种即时备份namenode元数据的方案，设置多个data目录（包括NFS目录），让namenode在持 久化元数据的时候同时写入多个目录，这种方案较第一种方案的优势是能避免数据的丢失（这里我们暂时不讨论NFS本身会丢失数据的可能性，毕竟这种几率很小 很小）。既然可以解决数据丢失的问题，说明这套方案在原理上是可行的

参考下面一样:

Hadoop集群中，NameNode节点存储着HDFS上所有文件和目录的元数据信息

如果NameNode挂了，也就意味着整个Hadoop集群也就完了

所以，NameNode节点的备份很重要，可以从以下2个方面来备份NameNode节点

1. 在hdfs-site.xml中，配置多个name的dir到不同的磁盘分区上：

dfs.name.dir
/pvdata/hadoopdata/name/,/opt/hadoopdata/name/

2. 在另外的一台服务器上配置Secondary NameNode：它是NameNode的一个备份

Secondary NameNode会定期合并fsimage和edits日志，将edits日志文件大小控制在一个限度下

合并的时机是由2个配置参数决定的：

fs.checkpoint.period，指定连续两次检查点的最大时间间隔， 默认值是1小时。
fs.checkpoint.size定义了edits日志文件的最大值，一旦超过这个值会导致强制执行检查点（即使没到检查点的最大时间间隔）。默认值是64MB。

Secondary NameNode的配置过程如下：

在conf/masters中指定第二名称节点的主机名

在core-site.xml中指定checkpoint的目录

fs.checkpoint.dir
/opt/hadoopdata/secondname,/pvdata/hadoopdata/secondname
Determines where on the local filesystem the DFS secondary
name node should store the temporary images to merge.
If this is a comma-delimited list of directories then the image is
replicated in all of the directories for redundancy.

如果NameNode节点挂了，可以按照如下步骤来从Secondary NameNode来恢复：

在dfs.name.dir指定的位置建立一个空文件夹

从Secondary NameNode上把secondname的目录给scp到新的NameNode机器的fs.checkpoint.dir下

使用hadoop/bin/hadoop namenode -importCheckpoint来启动NameNode，主要不要执行format命令

使用hadoop fsck /user命令检查文件Block的完整性。