Hadoop重新格式化HDFS的方法

2019-01-01  本文已影响0人  鹅鹅鹅_

一、记一次“不合格”的方法


这种方法也是网上参考博客得来的,一开始就觉得有问题,后来真的发现了问题。

[hadoop@localhost ~]$ stop-all.sh 
[hadoop@localhost ~]$ rm -rf tmp
[hadoop@localhost ~]$ hadoop namenode -format
#启动hadoop
[hadoop@localhost ~]$ start-all.sh 
#在hadoop文件系统中新建一个测试目录
[hadoop@localhost ~]$ hdfs dfs -mkdir /test
#分别在master和slave节点上查看新建的test目录,发现目录都可以查看到
[hadoop@localhost ~]$ hdfs dfs -ls /
Found 1 items
drwxr-xr-x   - hadoop supergroup          0 2017-03-19 14:19 /test

显然,在HDFS文件系统中新建的test目录在mater和slave节点中都可以查看的到,但是,这就说明重新格式化成功了吗?

[hadoop@localhost ~]$ jps
22533 Jps
22369 NodeManager

二、问题产生的原因及修正方法


在网上查资料发现,问题产生的原因是重新格式化HDFS时,只删除了master节点上的指定目录,但是没有删除slaves节点上的相应目录。
当我们执行文件系统格式化时,会在namenode数据文件夹(即配置文件中dfs.name.dir在本地系统的路径)中保存一个current/VERSION文件,记录namespaceID,标识了所格式化的 namenode的版本。如果我们频繁的格式化namenode,那么datanode中保存(即配置文件中dfs.data.dir在本地系统的路径)的current/VERSION文件只是你第一次格式化时保存的namenode的ID,因此就会造成datanode与namenode之间的id不一致。

[hadoop@localhost ~]$ cat tmp/dfs/name/current/VERSION 
#Sun Mar 19 14:13:51 CST 2017
namespaceID=901261394
clusterID=CID-5f83be8b-32e9-46ec-818c-404bd6dae38a
cTime=0
storageType=NAME_NODE
blockpoolID=BP-358141862-10.10.18.236-1489904031006
layoutVersion=-63
[hadoop@localhost ~]$ cat tmp/dfs/data/current/VERSION 
#Sun Mar 19 14:08:39 CST 2017
storageID=DS-91139d5d-43a0-4f9f-b523-8c4c8172f96c
clusterID=CID-9a1fa32b-018a-4466-af12-366444622470
cTime=0
datanodeUuid=b492e32e-a90e-4bab-84b0-ee4b4092b1d0
storageType=DATA_NODE
layoutVersion=-56

并没有在slave节点中发现namespaceID,不过master和slave都有clusterID,我尝试将slave节点中的clusterID改为和master的clusterID一致,然后重启hadoop,发现正常了:

[hadoop@localhost ~]$ hdfs dfs -ls /
Found 1 items
drwxr-xr-x   - hadoop supergroup          0 2017-03-19 14:19 /test

三、总结


hadoop namenode -format  
上一篇下一篇

猜你喜欢

热点阅读