CDH 集群核心服务器磁盘损坏应急恢复运维手册文档版本1.0适用场景NameNode 节点磁盘物理损坏MySQL 数据目录受损集群未启用 HDFS HA恢复策略文件系统只读抢救 → MySQL 强制恢复 → 逻辑导出重建 → CM 元数据恢复 → HDFS 从 SecondaryNameNode 恢复 → 组件重配 → 高可用加固一、灾难背景与恢复目标1.1 初始状态物理服务器磁盘出现磁道损坏Ext4 文件系统 I/O 错误。该服务器同时运行以下关键服务HDFS NameNode单点未启用 HAHDFS SecondaryNameNodeMySQL 数据库存储 Cloudera Manager 元数据及其他组件元数据集群无有效备份MySQL 无定期逻辑备份HDFS 元数据仅存在于 SecondaryNameNode 的 Checkpoint 中1.2 恢复目标抢救 MySQL 数据在磁盘进一步损坏前完整提取 CM 及其他组件元数据。重建健康 MySQL 实例彻底抛弃存在物理不一致性的数据文件。恢复 Cloudera Manager 服务重新获得集群管理能力。恢复 HDFS 文件系统利用 SecondaryNameNode 重建 NameNode 元数据接受少量增量数据丢失。修复相关组件调整 Hive、Hue、Oozie 等指向新 MySQL 实例。启用高可用防止单点故障再次引发灾难。二、准备工作2.1 资源准备资源类型要求临时服务器 A用于临时恢复 MySQL配置与原服务器相同版本操作系统和 MySQL 5.6新生产服务器 B用于长期运行 CM Server 和 MySQL建议独立于 Hadoop 节点新 NameNode 节点硬件配置、主机名、IP 地址与原 NameNode 节点完全一致备份存储空间至少 2 倍于 MySQL 数据目录大小的可用空间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文件包含在内。阶段 2MySQL 强制恢复与逻辑导出目标利用临时服务器通过innodb_force_recovery强行拉起 MySQL导出完整的逻辑备份SQL 文件。步骤 2.1在临时服务器 A 搭建同版本 MySQL 5.6yuminstall-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逐步尝试启动 MySQLsystemctl start mysqld若启动失败观察错误日志tail-100/data/mysql/log/mysql_error.log根据错误类型调整innodb_force_recovery级别常见错误及对策错误特征调整动作Tablespace ... missing增加至 5InnoDB: Cannot initiate database recovery, running in read-only-mode检查配置文件是否存在innodb_read_only或启动命令含只读参数Log sequence number ... mismatch删除ib_logfile*后重试验证检查点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--usermysql --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 安装同版本 MySQLyuminstall-ymysql-community-server-5.6.xx步骤 3.2初始化新数据库systemctl stop mysqldrm-rf/data/mysql/* mysql_install_db--usermysql--datadir/data/mysql步骤 3.3移除innodb_force_recovery配置编辑/etc/my.cnf删除或注释掉innodb_force_recovery行。步骤 3.4启动并设置 Root 密码systemctl start mysqld# MySQL 5.6 初始化后会生成随机密码greptemporary password/data/mysql/log/mysql_error.log登录并修改密码mysql-u root-pSETPASSWORDFORrootlocalhostPASSWORD(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.*TOscm%IDENTIFIEDBYscm_password;GRANTALLPRIVILEGESONscm.*TOscmlocalhostIDENTIFIEDBYscm_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.propertiescom.cloudera.cmf.db.typemysql com.cloudera.cmf.db.host新MySQL服务器IP:3306 com.cloudera.cmf.db.namescm com.cloudera.cmf.db.userscm com.cloudera.cmf.db.passwordscm_password步骤 4.3启动 CM Serversystemctl 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登录。主页显示所有集群主机状态此时应大部分为红色告警。阶段 5HDFS 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 UI50070 端口# 或通过命令行检查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 界面修改配置进入组件服务页面例如Hive。点击配置。搜索database或connection。修改以下属性数据库主机改为新 MySQL IP 或主机名。数据库名称、用户名、密码与阶段 3 授权一致。点击保存更改。步骤 6.3重启受影响组件点击组件服务旁的操作→重启。观察各组件日志确认无连接错误。验证检查点各组件服务状态在 CM 中变为绿色。以 Hive 为例执行beeline -u jdbc:hive2://...能正常连接并show tables;。阶段 7启用 HDFS 高可用强制执行目标从根本上消除 NameNode 单点故障风险。步骤 7.1在 CM 界面启用 HA进入HDFS服务。点击操作→启用 High Availability。按照向导完成以下步骤选择备用 NameNode 主机。配置 JournalNode至少 3 个节点。自动迁移元数据至共享存储。等待向导完成并启动所有服务。验证检查点CM 界面中 HDFS 实例页显示两个 NameNode一个为Active一个为Standby。执行手动 Failover 测试hdfs haadmin -failover nn1 nn2可成功切换。阶段 8配置自动备份策略目标确保未来可快速从类似灾难中恢复。8.1 MySQL 每日逻辑备份8.2 HDFS 元数据定期拉取在任一 NameNode 节点添加 crontab03* * *sudo-uhdfs hdfs dfsadmin-fetchImage/backup/nn_fsimage_$(date\%Y\%m\%d)验证检查点/backup/目录下生成fsimage文件且大小与 NameNode 当前fsimage相近。