前言

格式化NameNode后集群的数据会全部丢失，格式化之前需做好数据备份工作。

格式化步骤

1. 格式化之前，首先需删除Hadoop系统日志，默认路径为${HADOOP_HOME}/logs。
2. 然后删除主节点目录以及数据节点目录，默认路径分别为${hadoop.tmp.dir}/dfs/name和${hadoop.tmp.dir}/dfs/data。hadoop.tmp.dir默认值是/tmp/hadoop-${user.name}，可以在core-site.xml配置文件中的hadoop.tmp.dir属性设置。而上面的主节点目录和数据节点目录也可以在hdfs-site.xml配置文件中的dfs.namenode.name.dir和dfs.namenode.data.dir属性中设置。（在dfs/name/current目录下的VERSION文件中记录集群的版本信息，其中clusterID是集群版本标识，每次format都会生成不同的ID。在dfs/data/current目录下的VERSION文件中记录datanode的版本相关信息，其中clusterID标识它是属于哪个集群的，namenode 和 datanode的这两个值一致时，才会认为是同一个集群。格式化后，namenode的clusterID会改变，但datanode节点目录dfs/data/current如果在格式化时仍存在，则datanode的clusterID不会变化。这种情况下，启动集群，datanode进程虽然也会启动，但与namenode确认clusterID后，发现不一致，就会自动退出了。）
3. 格式化NameNode，命令为hdfs namenode -format。

参考资料

1. Hadoop 集群实现重新格式化
2. Hadoop namenode重新格式化需注意问题

前情提要

近段时间测试环境被研发整了一个特别离谱的事情，因为HDFS重启没启动起来，直接执行了format操作，大言不惭说的是百度这么说的，过了年以后我上环境看的时候，发现环境直接不能用了，然后启动也启动不起来，项目经理追着维护人员恢复环境，对开发把环境整崩的事情闭口不提，也是离谱。

过程记录

这种情况数据就别指望恢复了，直接怼HDFS进行格式化吧，因为服务器资源就这么些，这个环境还不能重装系统，最保险的方式就是重新格式化HDFS了，否则到时候重装各种组件，旧文件删除不完全啥的，都是坑。

准备工作

停止HDFS进程

停止所有假死的HDFS进程，保证没有进程还存在

删除数据

由于研发格式化过一次，产生了新的集群信息和数据信息，手动删除一下，具体路径可以参考配置文件hdfs-site.xml的dfs.datanode.data.dir：

删除日志和临时目录

具体的路径可以查看配置文件中的hadoop.tmp.dir和日志配置项：

启动JournalNode服务

由于启用了HA，所以格式化过程中会去连接JournalNode服务，如果不保证JN服务正常提供服务，初始化会失败：

格式化HDFS

执行NameNode格式化

保证JN服务正常后，再次format，注意！必须使用正确的用户进行，如果之前启动HDFS的用户是hdfs用户，就必须使用hdfs用户进行，否则会出现文件权限问题，需要手动授权：

hdfs namenode -format

格式化完成后，启动NameNode，此时可以访问WebUI检查状态：

恢复Standby NameNode

此时的HDFS还不是HA，切换到hdfs用户，执行bootstrapStandby命令：

启动Standby NameNode

此时可以正常启动Standby的NameNode，并检查WebUI：

恢复依赖服务

接下来依次恢复其他的依赖服务，如HBASE、HIVE等：

小结

环境一定不要让乱搞的研发人员上去操作，百度到的命令不管什么含义都敢直接执行，这种人能带来的灾难绝对不止一点。

 Tail 
1、tail -f filename  
说明：监视filename文件的尾部内容（默认10行，相当于增加参数 -n 10），刷新显示在屏幕上。退出，按下CTRL+C。  

2、tail -n 20 filename  
说明：显示filename最后20行。  

3、tail -r -n 10 filename  
说明：逆序显示filename最后10行。

head 仅仅显示前面几行  

head -n 10  test.log   查询日志文件中的头10行日志;  

head -n -10  test.log   查询日志文件除了最后10行的其他所有日志; 

grep主要是跟正则连用的