背景描述：
机房断电重启后发现HDFS服务不正常
发现步骤：
-
检查HDFS文件系统健康 通过命令的方式查看或者web ui 信息进行查看
hdfs fsck / -
检查对应哪些Block发生了损坏（显示具体的块信息和文件路径信息）
hdfs fsck -list-corruptfileblocks
数据处理流程：MySQL-----> Hadoop，解决方式只需要重新同步一份该表的数据即可
深层次的思考：
- 如何获取文件块的具体信息？
- 1个文件对应多个块，每个块分布在不同的机器上面？
使用命令查看块信息：
hdfs fsck xxx -files -locations -blocks -racks
对应参数的含义：
- files 文件分块信息，
- blocks 在带-files参数后才显示block信息
- locations 在带-blocks参数后才显示block块所在datanode的具体IP位置，
- racks 在带-files参数后显示机架位置
对于损坏块的文件，是无法进行显示的，对于好的没有损坏的文件是可以显示其分布的详细信息的可以获取对应的块信息的分布，到指定的linux机器上删除损坏的块，或者使用Hadoop提供的命令删除损坏的块：hdfs fsck / -delete，该命令是删除损坏的块对应的文件，那么该文件对应的其他的块也将被删除掉。
解决方式汇总：
方式一：delete方式暴力删除
最终删除损坏块的文件，然后对应的业务系统数据重刷
命令：hdfs fsck / -delete
注：该命令仅仅只是删除损坏块所对应的文件，而不是删除损坏的那个块
思考：
- 如果仅仅删除损坏块对应的文件，那么对应的数据丢了多少我们是不知道的，如何去确保数据补回来呢? 这是需要思考的。
- 如果是日志类的数据，丢一点点是没有关系的，那就没事
- 如果对应的数据是业务数据，比如订单数据，那是不能丢的，数据重刷和维护都是需要报告的
方式二：debug方式优雅处理
手动修复Block的命令(最多重试10次)：
hdfs debug recoverLease -path /blockrecover/bigdata.md -retries 10
这样做是基于这样的思考：1个block有对应的三个副本，其中一个副本损坏了，但是有另外两个副本存在，是可以利用另外两个副本进行修复的，因此我们可以使用debug命令进行修复
方式三：配置参数自动修复
在HDFS中实际上也可以配置块的自动修复的，当数据块损坏后，DataNode节点在执行directoryscan操作之前，都不会发现损坏directoryscan操作间隔6h进行
dfs.datanode.directoryscan.interval : 21600
在DataNode向NameNode进行blockreport之前，都不会恢复数据块;blockreport操作是间隔6h
dfs.blockreport.intervalMsec : 21600000