实验情景:
- datanode是文件系统的工作节点。他们根据需要存储并检索数据块(受客户端或namenode调度),并且定期向namenode发送他们所存储的块的列表。没有namenode,文件系统将无法使用。事实上,如果运行namenode服务的机器毁坏,文件系统上所有的文件将会丢失,因为我们不知道如何根据datanode的块重建文件。因此,对namenode实现容错非常重要,Hadoop为此提供两种机制。
我们接下来通过在实验的方式来验证下namenode和datanode之间的关系;
打开ambari管理页面可以找到关于datanode和namenode对应的目录,分别打开其中的current/VERSION文件,进行对比。 - 分别打开其中的current/VERSION文件,进行对比
- NAME_NODE节点的VERSION
[root@knode1 current]# cat VERSION
#Thu May 14 09:46:23 CST 2020
namespaceID=311386469
clusterID=CID-cdb06145-911d-4978-8ce0-1b0cb7f8285a
cTime=1589420783394
storageType=NAME_NODE
blockpoolID=BP-404223873-192.168.15.76-1589420783394
layoutVersion=-64
DATA_NODE节点的VERSION
[root@knode1 current]# cat VERSION
#Thu May 14 10:01:18 CST 2020
storageID=DS-a202c716-c149-4f81-b266-b5ba0be3503e
clusterID=CID-cdb06145-911d-4978-8ce0-1b0cb7f8285a
cTime=0
datanodeUuid=b8847b7e-0c3f-40b0-b8ad-dd3b64b5971b
storageType=DATA_NODE
layoutVersion=-57
从上图我们可以看出,clusterID的是一致的;为了验证Hadoop3.0遇到的DataNode和Namenode的clusterID不一致无法启动的问题,我们重新格式化一下nanenode,让它重新生成一个clusterID;
现象:
当我们多次格式化文件系统(hadoop namenode -format)时,会出现DataNode无法启动,我们先在ambari上暂停nanenode的服务
[hdfs@knode1 ~]$ hadoop namenode -format
WARNING: Use of this script to execute namenode is deprecated.
WARNING: Attempting to execute replacement "hdfs namenode" instead.
namenode is running as process 9492. Stop it first.
解决方法一:
删除DataNode的所有资料及将集群中每个datanode节点的/dfs/data/current中的VERSION删除,然后重新执行hadoop namenode -format进行格式化,重启集群,错误消失。
解决方法二:(推荐)
将name/current下的VERSION中的clusterID复制到data/current下的VERSION中,覆盖掉原来的clusterID
修改之后,重启三个Datanode就可以,恢复正常工作
出现该问题的原因:在第一次格式化dfs后,启动并使用了hadoop,后来又重新执行了格式化命令(hdfs namenode -format),这时namenode的clusterID会重新生成,而datanode的clusterID 保持不变