本文档为cdh集群，下线/上线节点操作文档。
CM 集群下线节点，主要参考官方文档：
操作前调优文档： https://docs.cloudera.com/documentation/enterprise/6/latest/topics/cm_mc_decomm_host.html#concept_urw_wyw_cy操作文档：https://docs.cloudera.com/documentation/enterprise/6/latest/topics/cm_mc_host_maint.html#cm_mc_host_maint
具体步骤如下：
开始下线前的自检
# 自检 hdfs 文件是否有损坏hdfs fsck / -list-corruptfileblocks -openforwrite -files -blocks -locations# 如果文件有损坏，需要进行修复hdfs fsck file_name -move
选择需要下线的主机，开始下线。为了避免下线过程中出现数据丢失的风险，一次下线的主机数量要小于 hdfs block 的副本数量。
选择迁移时是否要同步迁移数据，一般时要选择同步迁移数据。然后开始下线节点
接着会显示节点下线的进度。同时在NameNode web ui 上会显示 hdfs block 文件向其他节点的同步进度（主要看 Number of Under-Replicated Blocks）。
在 NameNode Summary 页面，可以看到正在下线的节点数量和待迁移的 hdfs block 数量。
下线结束后，可以去集群后台使用命令查看各个节点在迁移后的磁盘使用率
hdfs dfsadmin -report
在下线过程中，可能存在以下情况：
参数调优时，设置参数过大，同步速度快但是集群负载高，导致失败；网络波动导致 NameNode 主备切换，web界面显示下线过程结束了，但后台还在进行；
这时会出现block还未迁移完的情况（Under-replicated blocks显示不为0），可以等hdfs自动修复(推荐)，也可以手动修复（速度也很慢）。
手动修复执行脚本如下：
hdfs fsck / | grep 'Under replicated' | awk -F':' '{print $1}' >> /tmp/under_replicated_files 然后循环修复：for hdfsfile in `cat /tmp/under_replicated_files`; do echo "Fixing $hdfsfile :" ; hadoop fs -setrep 3 $hdfsfile; done
数据迁移完后，开始从CM上删除节点。先进行从集群中删除主机，然后进行Remove Hosts From Cloudera Manager，直接在对应的页面中使用默认选项确定即可，注意Remove Hosts From Cloudera Manager中需要先去下线节点上手动停止cm-agent然后直接点击确定即可，这里貌似也会解除授权角色，自动进行数据迁移到其他节点，但我没有这么操作过。
附录：
hdfs fsck 参数详解：
参数说明：
Total size ： hdfs集群存储大小，不包括复本大小。
Total blocks (validated) : 总共的块数量，不包括复本。
Number of data-nodes ： datanode的节点数量
Number of racks ： 机架数量
Default replication factor ： 默认的复制因子
Average block replication ： 当前块的平均复制数，如果小 default replication factor，则有块丢失
Under-replicated blocks ： 正在复制块数量，可采用 hadoop fsck -blocks 解决问题
Mis-replicated blocks ： 正复制的缺少复制块的数量
Missing replicas ： 缺少复制块的数量，通常情况下Under-replicated blocksMis-replicated blocksMissing replicas 都为0，则集群健康，如果不为0，则缺失块了
Corrupt blocks ： 坏块的数量，这个值不为0，则说明当前集群有不可恢复的块，即数据有丢失了
当下架节点时Under-replicated blocksMis-replicated blocksMissing replicas，这三个参数会显示当前，需要补的块的数量，集群会自动补全，当三个参数都为0时，则集群块的复制块完全了。