1 namenode元数据被破坏，修复
解决：恢复一下namenode
hadoop namenode -recover
复制代码一路选择c，一般就OK了
2 core-site.xml配置:
- 1：指定fs.defaultFS 默认的Hdfs实例访问空间。比如：bd-cluster
- 2: 设置集群zookeeper的访问地址。比如:Master:2181,Worker1:2181,Worker2:2181
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://bd-cluster</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/log_all/hadoop</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>Master:2181,Worker1:2181,Worker2:2181</value>
</property>
</configuration>
复制代码3 hdfs-site.xml配置:
- 1：指定dfs.nameservices，也即Hdfs实例。比如：bd-cluster
- 2：指定namenode Id ,初始化两个namenode实例。比如：nn1,nn2
- 3：设置Hdfs实例对应的两个namenode实例对应的rpc-address和http-address。比如：Master:8020和Master:50070
- 4：指定自动容错机制automatic-failover，比如：设置为True
- 5：指定共享存储指定目录shared.edits.dir。比如：路径为qjournal://Master:8485;Worker1:8485;Worker2:8485/bd-cluster
<configuration>
<property>
<name>dfs.nameservices</name>
<value>bd-cluster</value>
</property>
<property>
<name>dfs.ha.namenodes.bd-cluster</name>
<value>nn1,nn2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.bd-cluster.nn1</name>
<value>Master:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.bd-cluster.nn2</name>
<value>Worker1:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.bd-cluster.nn1</name>
<value>Master:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.bd-cluster.nn2</name>
<value>Worker1:50070</value>
</property>
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://Master:8485;Worker1:8485;Worker2:8485/bd-cluster</value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/usr/local/soft/cdh_support/hadoop-2.6.0-cdh5.9.3/journal</value>
</property>
<property>
<name>dfs.client.failover.proxy.provider.bd-cluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/admin/.ssh/id_rsa</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.connect-timeout</name>
<value>6000</value>
</property>
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.replication</name>
<value>3</value>
</property>
<property>
<name>dfs.datanode.max.xcievers</name>
<value>8192</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:/hadoop/datanode</value>
</property>
<property>
<name>dfs.namenode.datanode.registration.ip-hostname-check</name>
<value>false</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/hadoop/namenode</value>
</property>
<property>
<name>dfs.permissions</name>
<value>false</value>
</property>
</configuration>
复制代码4 参数详解
- dfs.ha.automatic-failover.enabled
这里是把主备自动切换关闭，需要手工来切换。在下一篇文章会介绍通过配置zookeeper来实现主备自动切换。 - fs.ha.namenodes.mycluster
中的nn1,nn2分别是active namenode和standby namenode的namenode id，你也可以自己起一个namenode id，只要在参数中都保持一致就可以了。 - dfs.namenode.shared.edits.dir
配置一组journalnode（3,5,7,...,2n+1）的URI，用于active namenode和standby namenode读写edits文件（原理可以参考前面的文章《hadoop2.0的HA介绍》），中的mycluster是dfs.nameservices保持一致。你可以自己起一个nameservice ID，只要在参数中都保持一致就可以了。 - dfs.journalnode.edits.dir
是在journalnode节点上用于存放active namenode和standby namenode共享的edits文件的目录。 - dfs.ha.log-roll.period
active namenode的edits文件轮转的时间间隔，前面没有设置这个参数，默认值是120秒。即standby namenode会隔120秒要求active namenode切出一个edits文件，然后通过journalnode去同步这个文件。
active namenode会隔120秒会切出一个新edits文件，并且给这些edits文件一个编号，越新的edits文件编号越大。
日志轮转的时候开始会先生成一个新的“inprogress” edits文件（文件名带着“inprogress”），说明日志正在生成，轮转没完成。当过了120秒之后，日志轮转完成，文件改名，文件名字带着一个目前最大的编号（文件名没有“inprogress”）。然后生成一个新的“inprogress” edits文件，开始下一次edits文件轮转。
当发生主备切换的时候，会触发一次edit文件的轮转，这样standby namenode就会把剩下的edits文件同步过来，在切换到active状态时元数据能保持一个最新的状态。 - dfs.ha.tail-edits.period
standby namenode每隔多长时间去检测新的edits文件。它只会检查已经完成轮转的edits文件，不会检查“inprogress” edits文件。 - dfs.ha.fencing.methods
系统在任何时候只有一个namenode节点处于active状态。在主备切换的时候，standby namenode会变成active状态，原来的active namenode就不能再处于active状态了，否则两个namenode同时处于active状态会造成所谓的“脑裂”问题。所以在failover的时候要设置防止2个namenode都处于active状态的方法，可以是java类或者脚本。
fencing的方法目前有两种，sshfence和shell
sshfence方法是指通过ssh登陆到active namenode节点杀掉namenode进程，所以你需要设置ssh无密码登陆，还要保证有杀掉namenode进程的权限。
shell方法是指运行一个shell脚本/命令来防止“脑裂”问题，脚本需要自己写。
注意，QJM方式本身就有fencing功能，能保证只有一个namenode能往journalnode上写edits文件，所以是不需要设置fencing的方法就能防止“脑裂”问题的。但是，在发生failover的时候，原来的active namenode可能还在接受客户端的读请求，这样客户端很可能读到一些过时的数据（因为新的active namenode的数据已经实时更新了）。因此，还是建议设置fencing方法。如果确实不想设置fencing方法，可以设置一个能返回成功（没有fencing作用）的方法，如“shell(/bin/true)”。这个纯粹为了fencing方法能够成功返回，并不需要真的有fencing作用。这样可以提高系统的可用性，即使在fencing机制失败的时候还能保持系统的可用性。 - dfs.ha.automatic-failover.enabled
需要设置为true，启动自动切换。
5 HA namenodes启动及初始化过程：
- 1:先在journalnode机器上启动journalnode $HADOOP_HOME/sbin/hadoop-daemon.sh start journalnode
- 2:在namenode1上初始化namenode，namenode1表示原先的nameNode节点，通过initializeSharedEdits命令已经把edits文件共享到journalnode上
如果是首次启动，在namenode1上运行format命令:$HADOOP_HOME/bin/hadoop namenode -format
如果是非首次启动，则在namenode1上运行以下命令:$HADOOP_HOME/bin/hdfs namenode -initializeSharedEdits
复制代码- 3:在namenode1上启动namenode:
$HADOOP_HOME/sbin/hadoop-daemon.sh start namenode
复制代码- 4:在namenode2上初始化namenode:
namenode2是不需要format的,并且需要运行bootstrapStandby命令来同步namenode1的元数据，和namenode1的元数据保持一致。
$HADOOP_HOME/sbin/hadoop-daemon.sh start namenode -bootstrapStandby
复制代码- 5:在namenode2上启动namenode:
$HADOOP_HOME/sbin/hadoop-daemon.sh start namenode
复制代码- 6 在zookeeper中初始化，在zookeeper上创建一个/hadoop-ha/mycluster/的znode
$HADOOP_HOME/bin/hdfs zkfc -formatZK
复制代码- 7 启动zkfc(zookeeper failover controller)，需要在namenode1和namenode2上都启动zkfc daemon进程
$HADOOP_HOME/sbin/hadoop-daemon.sh start zkfc
复制代码本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
