CDH 集群机房搬迁这件事，本质上不是"搬服务器"，而是一次受控的数据中心级别的灾备切换 + 集群重建工程。
如果方案思路错了，结果往往是：
• HDFS 数据拷贝耗时极长（几十 TB / 上百 TB）
• NameNode 元数据损坏或版本不一致
• Yarn / Hive / HBase / Impala 全部异常
• 权限、Kerberos、Ranger、元数据库各种隐性坑
• 业务停摆远超预期
一、先明确一个关键结论（非常重要）
CDH 机房搬迁 = 严禁做"服务器整体搬家"或"磁盘级复制"
CDH/HDFS 强依赖机器 IP、主机名、rack 信息、block 位置信息。
你如果试图：
• 拔服务器搬走
• 做磁盘级镜像
• rsync 数据目录
• 做虚拟机整体迁移
99% 最后集群起不来，这是典型踩坑。
正确思路只有一个：
在新机房 重新搭建一套全新的 CDH 集群，
再把数据"迁移"过去，而不是"搬过去"。
这是行业标准做法。
二、标准迁移架构（推荐）
旧机房 CDH 集群（持续数据同步） →→→→ 新机房 CDH 集群（最终切换）
迁移分三阶段：
阶段 名称 是否停机 耗时
阶段1 新集群搭建 无需停机 耗时1~2天
阶段2 数据长时间同步 无需停机 几天~几周（后台跑）
阶段3 最终停机切换 需要停机 耗时2~6 小时，取决于数据量
三、核心迁移原理
利用 HDFS 自带能力：
DistCp + Snapshot 差异同步
这套方案是 Hadoop 官方用于跨机房迁移/容灾的标准方案。
原理：
- 先全量复制一次（不停机）
- 期间业务继续写数据
- 最终停机
- 同步最后差异数据（非常快）
- 切业务到新集群
不是拷 TB 数据，是只拷最后几 GB 差异。
四、完整迁移路线图
阶段1：新机房准备（关键但简单）
在新机房：
• 安装同版本 CDH（版本必须一致）
• 规划相同的：
o Kerberos
o Ranger
o 用户组
o Hive Metastore 数据库
o HDFS 副本数、block size
• 不需要任何数据
此时新集群是空集群。
阶段2：不停机大规模数据同步（最耗时但对业务无影响）
在旧集群执行：
hdfs dfsadmin -allowSnapshot /data
hdfs dfs -createSnapshot /data snap1
然后：
hadoop distcp hdfs://oldcluster/data hdfs://newcluster/data
这一步可能跑：
20TB → 2~3天
100TB → 1周+
但业务无感知。
阶段3：关键停机窗口（真正的搬迁时刻）
- 业务停写
- 再打一个快照：
hdfs dfs -createSnapshot /data snap2 - 执行差异同步（极快）
hadoop distcp
-diff snap1 snap2
hdfs://oldcluster/data
hdfs://newcluster/data
通常只需要 几十分钟 ~ 2小时。
阶段4：迁移的不只是 HDFS（很多人忽略的坑）
组件 迁移方式
Hive 元数据库 mysqldump 导出导入
HBase Snapshot 导出
Oozie DB 导出
Ranger DB 导出
Kafka（如有） MirrorMaker
用户权限 同步 /etc/passwd 或 LDAP
Kerberos 复制 KDC 或重建
真正复杂的是这些，不是 HDFS。
阶段5：业务切换
改所有：
• Hive JDBC 地址
• Yarn RM 地址
• HDFS nameservice
• Impala 地址
• 调度系统地址
业务直接指向新集群。
五、为什么这是"正确姿势"
因为：
错误做法 后果
搬服务器 HDFS block 元数据错乱
rsync data 目录 NameNode 直接报废
虚拟机整体迁移 IP 改变后集群瘫痪
期望零停机 不可能
而 DistCp + Snapshot：
这是 Hadoop 官方跨机房迁移的唯一推荐方案
六、实际项目中机房搬迁时间线
假设 60TB 数据：
第1天 新集群搭建完成
第2~5天 后台全量 DistCp
第6天晚上 停机2小时，差异同步
第7天 业务全部切换
停机只有 2 小时
七、现在最需要关注的不是命令，而是这些信息
下一步应该确认：
- HDFS 数据量多少 TB
- 是否有 HBase
- 是否有 Kerberos / Ranger
- Hive 元数据库多大
- 两机房带宽多少（这决定迁移天数）
这些决定详细方案。
八、一句话总结
CDH 机房搬迁 ≠ 搬机器
CDH 机房搬迁 = 新建集群 + 持续同步 + 快速切换
这是大数据行业里非常成熟的一套方法。