CDH hdfs集群核心服务器磁盘损坏应急恢复运维

CDH 集群核心服务器磁盘损坏应急恢复运维手册

文档版本：1.0
适用场景：NameNode 节点磁盘物理损坏，MySQL 数据目录受损，集群未启用 HDFS HA
恢复策略：文件系统只读抢救 → MySQL 强制恢复 → 逻辑导出重建 → CM 元数据恢复 → HDFS 从 SecondaryNameNode 恢复 → 组件重配 → 高可用加固

一、灾难背景与恢复目标

1.1 初始状态

• 物理服务器磁盘出现磁道损坏（Ext4 文件系统 I/O 错误）。
• 该服务器同时运行以下关键服务：
  • HDFS NameNode（单点，未启用 HA）
  • HDFS SecondaryNameNode
  • MySQL 数据库（存储 Cloudera Manager 元数据及其他组件元数据）
• 集群无有效备份：
  • MySQL 无定期逻辑备份
  • HDFS 元数据仅存在于 SecondaryNameNode 的 Checkpoint 中

1.2 恢复目标

1. 抢救 MySQL 数据：在磁盘进一步损坏前，完整提取 CM 及其他组件元数据。
2. 重建健康 MySQL 实例：彻底抛弃存在物理不一致性的数据文件。
3. 恢复 Cloudera Manager 服务：重新获得集群管理能力。
4. 恢复 HDFS 文件系统：利用 SecondaryNameNode 重建 NameNode 元数据，接受少量增量数据丢失。
5. 修复相关组件：调整 Hive、Hue、Oozie 等指向新 MySQL 实例。
6. 启用高可用：防止单点故障再次引发灾难。

二、准备工作

2.1 资源准备

2.2 关键信息收集

• 原 MySQL 版本：mysql --version输出
• 原 CDH 版本：/opt/cloudera/parcels/CDH目录名
• 原 NameNode 数据目录路径：/dfs/nn
• 原 SecondaryNameNode 数据目录路径：/dfs/snn
• 所有依赖 MySQL 的组件列表：Hive、Hue、Oozie 等

三、详细恢复步骤

阶段 0：故障服务器止损操作

目标：防止磁盘坏道扩散造成二次损坏，停止一切写入操作。

步骤 0.1：停止故障服务器上的所有服务

# SSH 登录故障服务器（如仍可连接）systemctl stop cloudera-scm-agent systemctl stop mysqld# 停止所有 Hadoop 相关进程（如有残留）pkill-fhadooppkill-fhivepkill-fooziepkill-fhdfs

步骤 0.2：物理隔离

# 断开网络连接或关闭服务器shutdown-hnow

验证检查点：

• 确认服务器已完全关机，无任何进程活动。

阶段 1：数据文件只读备份

目标：在磁盘彻底失效前，尽可能完整读取 MySQL 数据目录、NameNode 和 SecondaryNameNode 的元数据目录。

步骤 1.1：以只读方式挂载故障磁盘

将故障磁盘连接到一台健康服务器（或通过 Live CD 启动原服务器），执行只读挂载。

mkdir-p/mnt/recoverymount-text4-oro,noload /dev/sdX1 /mnt/recovery# 替换 sdX1 为实际分区

验证检查点：

• mount | grep /mnt/recovery显示包含ro选项。
• ls /mnt/recovery可正常列出目录内容。

步骤 1.2：备份 MySQL 数据目录

cd/mnt/recovery/data/mysql# 或实际 MySQL 数据路径tar-czvf/safe_storage/mysql_data_backup.tar.gz.

验证检查点：

• 压缩过程中无 “Input/output error” 报错。
• 压缩包大小与原目录大小基本一致（du -sh /mnt/recovery/data/mysql）。
• 使用tar -tzf /safe_storage/mysql_data_backup.tar.gz | head查看内容正常。

步骤 1.3：备份 HDFS 元数据目录

# 备份 NameNode 元数据（如磁盘仍可读）cd/mnt/recovery/dfs/nntar-czvf/safe_storage/nn_backup.tar.gz current/# 备份 SecondaryNameNode 元数据（通常位于另一节点或磁盘，但也需备份）cd/mnt/recovery/dfs/snntar-czvf/safe_storage/snn_backup.tar.gz current/

验证检查点：

• 两个压缩包创建成功，current/VERSION文件包含在内。

阶段 2：MySQL 强制恢复与逻辑导出

目标：利用临时服务器，通过innodb_force_recovery强行拉起 MySQL，导出完整的逻辑备份（SQL 文件）。

步骤 2.1：在临时服务器 A 搭建同版本 MySQL 5.6

yuminstall-ymysql-community-server-5.6.xx# 版本号必须与原环境完全一致

验证检查点：

• mysql --version输出与原服务器一致。
• MySQL 服务可正常启动并停止。

步骤 2.2：替换数据目录并配置强制恢复

systemctl stop mysqldrm-rf/data/mysql/*tar-xzf/safe_storage/mysql_data_backup.tar.gz-C/data/mysql/chown-Rmysql:mysql /data/mysql

编辑/etc/my.cnf，在[mysqld]下添加：

innodb_force_recovery = 4 # 从 4 开始尝试，逐步增加至 6 或 7

参数说明：

• 4：跳过损坏的索引页，尝试启动。
• 5：跳过 undo 日志回滚，强制拉起。
• 6：跳过 redo 日志前滚，仅用于紧急导出。

验证检查点：

• /data/mysql目录下存在ibdata1及各数据库子目录。
• 配置文件参数已生效（grep innodb_force_recovery /etc/my.cnf）。

步骤 2.3：逐步尝试启动 MySQL

systemctl start mysqld

若启动失败，观察错误日志：

tail-100/data/mysql/log/mysql_error.log

根据错误类型调整innodb_force_recovery级别，常见错误及对策：

验证检查点：

• MySQL 进程成功启动（ps aux | grep mysqld）。
• 可无密码或使用已知密码登录（见下一步）。

步骤 2.4：无 Root 密码情况下的数据导出

若不知道原 root 密码，使用--skip-grant-tables绕过权限验证。

① 停止当前 MySQL 服务

systemctl stop mysqld

② 手动启动 MySQL 跳过权限表（注意保持innodb_force_recovery配置）

sudo-umysql /usr/sbin/mysqld --defaults-file=/etc/my.cnf--user=mysql --skip-grant-tables --skip-networking&

验证检查点：

• ps aux | grep mysqld显示进程正在运行。
• mysql -u root -p提示输入密码时直接回车即可登录。

③ 执行逻辑导出

# 导出全部数据库mysqldump-uroot --all-databases --single-transaction--routines--triggers--events>/safe_storage/full_backup.sql# 单独导出 scm 库（Cloudera Manager 核心库,如果后面full_backup.sql导入不报错，这个就没用了）mysqldump-uroot--databasesscm --single-transaction>/safe_storage/scm_backup.sql

阶段 3：重建健康 MySQL 实例并导入数据

目标：在新生产服务器 B 上安装干净 MySQL，导入逻辑备份，彻底消除物理不一致性。

步骤 3.1：在新服务器 B 安装同版本 MySQL

yuminstall-ymysql-community-server-5.6.xx

步骤 3.2：初始化新数据库

systemctl stop mysqldrm-rf/data/mysql/* mysql_install_db--user=mysql--datadir=/data/mysql

步骤 3.3：移除innodb_force_recovery配置

编辑/etc/my.cnf，删除或注释掉innodb_force_recovery行。

步骤 3.4：启动并设置 Root 密码

systemctl start mysqld# MySQL 5.6 初始化后会生成随机密码grep'temporary password'/data/mysql/log/mysql_error.log

登录并修改密码：

mysql-u root-pSETPASSWORDFOR'root'@'localhost'=PASSWORD('YourNewStrongPassword');FLUSHPRIVILEGES;

验证检查点：

• 能使用新密码成功登录 MySQL。
• show databases;仅显示系统库（mysql,information_schema,performance_schema）。

步骤 3.5：导入逻辑备份

mysql-uroot-p</safe_storage/full_backup.sql

验证检查点：

• 导入过程中无 “ERROR” 输出。
• 重启 并 登录 MySQL 后show databases;包含scm,hive,hue,oozie等库。
• use scm; select count(*) from CM_VERSION;返回正常值。

步骤 3.6：授权 CM 及其他组件访问

一般全库导入的sql会包含用户信息，如果没有用户信息需要自己重建用户并授权。

重建用户并授权: 原环境中 CM Server 及其他组件通过特定用户名连接 MySQL，需重建授权。

-- 示例：授予 scm 用户权限GRANTALLPRIVILEGESONscm.*TO'scm'@'%'IDENTIFIEDBY'scm_password';GRANTALLPRIVILEGESONscm.*TO'scm'@'localhost'IDENTIFIEDBY'scm_password';-- 同样处理 hive, hue, oozie 等用户FLUSHPRIVILEGES;

验证检查点：

• 从新服务器本地执行mysql -u scm -p -h 127.0.0.1 scm可成功连接。

阶段 4：恢复 Cloudera Manager 服务

目标：使 CM Server 连接至新 MySQL 实例，恢复集群监控与管理功能。

步骤 4.1：停止原 CM Server（如仍在运行）

systemctl stop cloudera-scm-server

步骤 4.2：修改 CM Server 数据库配置

编辑/etc/cloudera-scm-server/db.properties：

com.cloudera.cmf.db.type=mysql com.cloudera.cmf.db.host=<新MySQL服务器IP>:3306 com.cloudera.cmf.db.name=scm com.cloudera.cmf.db.user=scm com.cloudera.cmf.db.password=scm_password

步骤 4.3：启动 CM Server

systemctl start cloudera-scm-server

步骤 4.4：监控启动日志

tail-f/var/log/cloudera-scm-server/cloudera-scm-server.log

关键成功标志：

• 出现INFO WebServerImpl:com.cloudera.server.cmf.WebServerImpl: Started Jetty server。
• 无SQLException或Communications link failure错误。

验证检查点：

• 浏览器访问http://<CM_Server_IP>:7180，使用默认账号admin/admin登录。
• 主页显示所有集群主机状态（此时应大部分为红色告警）。

阶段 5：HDFS NameNode 元数据恢复（从 SecondaryNameNode 复制）

目标：利用已备份的 SecondaryNameNode 元数据，重建 NameNode。

注意：若原 NameNode 数据目录已彻底损坏且 SecondaryNameNode 元数据较新，此方法可恢复至最近一次 Checkpoint。丢失的数据为 Checkpoint 至故障时刻之间的写入。

步骤 5.1：准备新 NameNode 节点

• 确保新节点主机名、IP 地址与原 NameNode完全一致。
• 安装cloudera-manager-agent并指向当前 CM Server。

yuminstall-ycloudera-manager-agentvi/etc/cloudera-scm-agent/config.ini# 设置 server_hostsystemctl start cloudera-scm-agent

步骤 5.2：在 CM 界面停止 HDFS 服务

• 登录 CM，进入HDFS服务。
• 点击操作→停止。
  验证检查点：
• HDFS 服务状态变为已停止。

步骤 5.3：复制 SecondaryNameNode 元数据至新 NameNode

# 在 SecondaryNameNode 节点打包（或使用阶段1的备份）cd/dfs/snntar-czf/tmp/snn_current.tar.gz current/# 传输至新 NameNode 节点scp/tmp/snn_current.tar.gz root@<新NameNode_IP>:/tmp/# 在新 NameNode 节点解压mkdir-p/dfs/nncd/dfs/nntar-xzf/tmp/snn_current.tar.gzchown-Rhdfs:hdfs /dfs/nn

步骤 5.4：验证 VERSION 文件一致性（关键！）

# 查看 NameNode 的 VERSIONcat/dfs/nn/current/VERSION# 记录 namespaceID, clusterID, blockpoolID# 在任意 DataNode 节点查看 VERSIONcat/dfs/dn/current/VERSION

验证检查点：

• 上述三个 ID 在两个文件中完全一致。若不一致，必须停止操作，手动修改 NameNode 的 VERSION 文件以匹配 DataNode。

步骤 5.5：在 CM 界面添加 NameNode 角色

• 进入 HDFS 服务 →实例。
• 点击添加角色，选择NameNode，分配至新主机。
• 点击启动。

步骤 5.6：验证 NameNode 启动状态

# 查看 NameNode Web UI（50070 端口）# 或通过命令行检查sudo-uhdfs hdfs dfsadmin-report

验证检查点：

• report输出显示所有 DataNode 处于Live状态。
• HDFS Web UI 中Safe Mode状态在 DataNode 全量注册后自动退出。
• CM 界面中 HDFS 服务健康状态为绿色或黄色（可能因丢块告警）。

步骤 5.7：处理丢失数据块

# 检查文件系统健康状态sudo-uhdfs hdfsfsck/-files-blocks-locations# 列出损坏文件sudo-uhdfs hdfsfsck/ -list-corruptfileblocks# 删除无法恢复的文件（确认可丢弃后执行）sudo-uhdfs hdfsfsck/-delete

验证检查点：

• 再次执行hdfs fsck /，Missing blocks数量为 0。

阶段 6：修复其他组件数据库连接配置

目标：更新所有使用 MySQL 的组件（Hive、Hue、Oozie 等）的连接信息，指向新 MySQL 服务器。

步骤 6.1：识别依赖 MySQL 的组件

常见列表：Hive Metastore、Hue、Oozie、Sentry、Navigator Audit 等。

步骤 6.2：通过 CM 界面修改配置

1. 进入组件服务页面（例如Hive）。
2. 点击配置。
3. 搜索database或connection。
4. 修改以下属性：
   • 数据库主机：改为新 MySQL IP 或主机名。
   • 数据库名称、用户名、密码：与阶段 3 授权一致。
5. 点击保存更改。

步骤 6.3：重启受影响组件

• 点击组件服务旁的操作→重启。
• 观察各组件日志确认无连接错误。

验证检查点：

• 各组件服务状态在 CM 中变为绿色。
• 以 Hive 为例，执行beeline -u jdbc:hive2://...能正常连接并show tables;。

阶段 7：启用 HDFS 高可用（强制执行）

目标：从根本上消除 NameNode 单点故障风险。

步骤 7.1：在 CM 界面启用 HA

1. 进入HDFS服务。
2. 点击操作→启用 High Availability。
3. 按照向导完成以下步骤：
   • 选择备用 NameNode 主机。
   • 配置 JournalNode（至少 3 个节点）。
   • 自动迁移元数据至共享存储。
4. 等待向导完成并启动所有服务。

验证检查点：

• CM 界面中 HDFS 实例页显示两个 NameNode，一个为Active，一个为Standby。
• 执行手动 Failover 测试：hdfs haadmin -failover nn1 nn2可成功切换。

阶段 8：配置自动备份策略

目标：确保未来可快速从类似灾难中恢复。

8.1 MySQL 每日逻辑备份

8.2 HDFS 元数据定期拉取

在任一 NameNode 节点添加 crontab：

03* * *sudo-uhdfs hdfs dfsadmin-fetchImage/backup/nn_fsimage_$(date+\%Y\%m\%d)

验证检查点：

• /backup/目录下生成fsimage文件，且大小与 NameNode 当前fsimage相近。