namenode元数据容错

 由于目前的生产环境 namenode ha都只是配置了一块磁盘，如果磁盘坏了，估计就game over了。所以想着怎样做namenode的元数据容错。后来查阅hdfs的相关配置，发现一个恰好可以解决该问题的配置:

　　<property>

　　　　<name>dfs.namenode.name.dir</name>

　　　　<value>file://${hadoop.tmp.dir}/dfs/name</value>

　　　　<description>Determines where on the local filesystem the DFS name node should store the name table(fsimage). If this is a comma-delimited list of directories then the name table is replicated(复制) in all of the directories, for redundancy(冗余).在实际的生产环境中应该配置成多块磁盘 </description>

　　</property>

　　原来该配置是可以多块磁盘的，冗余元数据，达到元数据备份的目的。

 

　　既然知道了可以做，那下面就是记录一下本次的工作步骤：

　　a.修改hdfs-site.xml配置：

　　　　<!-- 这是原来的配置：

　　　　<property>

　　　　　　<name>dfs.namenode.name.dir</name>

　　　　　　<value>/data2/hadoop/hd_space/dfs/name</value>

　　　　</property>

　　　　-->

　　修改为下面的配置，也就是新增了一块磁盘：注意：/data1/hadoop/hd_space/dfs/name目录要事先创建好，否则会报错。

　　　　<property>

　　　　　　<name>dfs.namenode.name.dir</name>

　　　　　　<value>/data2/hadoop/hd_space/dfs/name,/data1/hadoop/hd_space/dfs/name</value>

　　　　</property>

 

　　修改完两个namenode节点的配置文件之后就可以开始进行操作了: 然后重启本来正常集群的两个namenode节点，然后观察active namenode节点的目录下的变化。大概一个小时之后，发现/data1/hadoop/hd_space/dfs/name目录正常生成了fsimage文件，且和先前磁盘的大小一致，所以估计是成功了。

 

　　这里有一个问题：为什么是一个小时呢？因为该配置dfs.namenode.checkpoint.period是3600

 

　　b.观察standby的namenode的/data1/hadoop/hd_space/dfs/name，发现也正常生成了fsimage文件，并且大小和原来的一致。说明正常。

 

　　c.操作一下HDFS的文件，看看增删改查是否，结论:正常。

 

　　d.为了进一步进行测试，于是做了以下步骤：

　　　　将active namenode下的先前的正常的磁盘目录：/data2/hadoop/hd_space/dfs/name的权限改成hadoop用户不可读写，这样做的目的是模仿磁盘坏掉。然后做如下观察：

　　　　　　(1) namenode进程是否正常。如果正常，就操作几个文件。然后进行下一步：

　　　　　　(2) 新的磁盘目录是否能够正常生成fsimage文件，这里又得是一个小时之后进行观察

　　　　　　(3) 观察文件是否正常

　　　　以上正常

 

　　(4) 将磁盘/data2/hadoop/hd_space/dfs/name恢复原样，看是否能够正常同步fsimage文件。发现不行。这就好比一块磁盘坏了，你后来又新加上去，肯定要重启才行，现在重启namenode再看效果。效果就是居然重新将该盘进行了格式化。。。。。。。好在后面会重新进行同步。。。。。。

 

　　发现一切正常，可以上线了。。。。。

　　因为刚刚的操作是在测试环境，所以随便重启都是可以的，但是生产不能这么干。上面仅仅是为了验证该方案的可行性。

　　生产环境的操作步骤:

　　1. 修改两个namenode节点的配置文件。上面已经说过了.

　　2. 重启standby节点,待fsimage正常同步后，然后重启active节点。这样就不会对生产造成影响。