问题：
正常start-all.sh无法启动datanode进程，但是./hadoop-daemon.sh start datanode又可以启动。过一会后datanode进程又莫名消失。
原理：
多次hdfs namenode -format导致namenode生成了新的clusterID, 和datanode的不一致。
解决：
查日志，发现异常信息如下：
2019-07-22 17:46:09,856 WARN org.apache.hadoop.hdfs.server.common.Storage: Failed to add storage directory [DISK]file:/home/wjy/hadoop/tmp/dfs/data java.io.IOException: Incompatible clusterIDs in /home/wjy/hadoop-3.1.1/tmp/dfs/data: namenode clusterID = CID-8041cf56-7cbd-423e-a0b6-f782c1e1340f; datanode clusterID = CID-0d8412e3-e59b-4b1b-acdf-871b8cfa2f79
照着网上说的删除本地dfs.data.dir下的所有内容然后重启进程并没有解决我的问题。这个dfs.data.dir是在hdfs-site.xml里找的（由于我用的hadoop3.1.1，所以是dfs.datanode.data.dir）：
把data下面的current文件夹删了以后再次格式化namenode，还是那个问题，不同的是namenode的clusterID发生了改变（这很正常，因为重新格式化以后又生成了新的clusterID),datanode的clusterID却一直没变。按理说datanode的clusterID应该是在data/current/VERSION里面被记录的，但是现在我根本就把这个文件夹给删掉了。。。 而且启动datanode时应该会生成一个和namenode一样的clusterID的，并没有。把namenode的VERSION给复制过去做适当的修改还是没用。
后来我发现在下图这个路径下面还有一个data文件夹，下面的VERSION文件中的clusterID正是错误信息中的那个！
原来我之前删错了。。。 把这个current给删掉再重启一次datanode果然就好了（完全分布式记得要删除所有节点的哦，不然slave的datanode也会起不来的）。
可是很奇怪，为什么这个文件不生成在设置的dfs.datanode.name.dir的文件夹下面呢？而是在这个默认路径里面。