目录大纲
- Part01-集群崩溃基础概念与理论知识
- 1.1 集群崩溃的定义与表现
- 1.2 集群崩溃的原因分析
- 1.3 集群崩溃的影响
- Part02-集群崩溃预防措施与规划
- 2.1 高可用架构设计
- 2.2 监控与预警机制
- 2.3 灾备方案规划
- Part03-集群崩溃恢复实施方案
- 3.1 NameNode崩溃恢复
- 3.2 DataNode崩溃恢复
- 3.3 ResourceManager崩溃恢复
- 3.4 全集群崩溃恢复
- Part04-集群崩溃恢复生产案例与实战讲解
- 4.1 案例一：NameNode单点故障恢复
- 4.2 案例二：DataNode大规模故障恢复
- 4.3 案例三：全集群断电恢复
- Part05-风哥经验总结与分享
- 5.1 集群崩溃排查方法论
- 5.2 最佳实践总结
- 5.3 常见问题与解决方案
Part01-集群崩溃基础概念与理论知识
1.1 集群崩溃的定义与表现
集群崩溃是指Hadoop集群中的一个或多个组件出现严重故障，导致集群无法正常运行的状态。
1. NameNode无法启动或响应
2. 多个DataNode同时故障
3. ResourceManager无法分配资源
4. 任务执行失败或卡住
5. 集群服务完全不可用
1.2 集群崩溃的原因分析
集群崩溃的主要原因包括：
1. 硬件故障：服务器、存储、网络设备故障
2. 软件故障：Hadoop组件bug、配置错误
3. 人为操作：误操作、配置变更错误
4. 环境问题：断电、网络中断、磁盘空间不足
5. 数据问题：元数据损坏、数据不一致
学习交流加群风哥微信: itpux-com
1.3 集群崩溃的影响
集群崩溃会对业务造成严重影响：
1. 业务中断：数据处理任务无法执行
2. 数据丢失：可能导致部分数据丢失
3. 服务不可用：依赖Hadoop的应用无法访问
4. 恢复时间长：复杂故障恢复时间可能数小时
5. 经济损失：业务中断带来的直接和间接损失
风哥提示：集群崩溃是生产环境中的严重事件，需要建立完善的应急响应机制
Part02-集群崩溃预防措施与规划
2.1 高可用架构设计
# 1. NameNode高可用
[root@fgedu.net.cn ~]# vi /bigdata/app/hadoop/etc/hadoop/hdfs-site.xml
# 2. ResourceManager高可用
[root@fgedu.net.cn ~]# vi /bigdata/app/hadoop/etc/hadoop/yarn-site.xml
2.2 监控与预警机制
# 1. 部署Prometheus + Grafana
[root@fgedu.net.cn ~]# wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
[root@fgedu.net.cn ~]# tar -zxvf prometheus-2.45.0.linux-amd64.tar.gz -C /bigdata/app/
[root@fgedu.net.cn ~]# mv /bigdata/app/prometheus-2.45.0.linux-amd64 /bigdata/app/prometheus
# 2. 配置Node Exporter
[root@fgedu.net.cn ~]# wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
[root@fgedu.net.cn ~]# tar -zxvf node_exporter-1.6.0.linux-amd64.tar.gz -C /bigdata/app/
[root@fgedu.net.cn ~]# mv /bigdata/app/node_exporter-1.6.0.linux-amd64 /bigdata/app/node_exporter
[root@fgedu.net.cn ~]# /bigdata/app/node_exporter/node_exporter &
# 3. 配置告警规则
[root@fgedu.net.cn ~]# vi /bigdata/app/prometheus/rules/hadoop_alerts.yml
groups:
– name: hadoop_alerts
rules:
– alert: NameNodeDown
expr: hadoop_namenode_is_active == 0
for: 5m
labels:
severity: critical
annotations:
summary: “NameNode Down”
description: “NameNode on {{ $labels.instance }} is down for more than 5 minutes”
更多学习教程公众号风哥教程itpux_com
2.3 灾备方案规划
# 1. 数据备份策略
[root@fgedu.net.cn ~]# vi /bigdata/scripts/backup_hdfs.sh
#!/bin/bash
# backup_hdfs.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 备份NameNode元数据
/bigdata/app/hadoop/bin/hdfs dfsadmin -safemode enter
/bigdata/app/hadoop/bin/hdfs dfsadmin -saveNamespace
cp -r /bigdata/fgdata/hdfs/namenode/current /bigdata/backup/namenode/$(date +%Y%m%d)
/bigdata/app/hadoop/bin/hdfs dfsadmin -safemode leave
# 2. 跨机房灾备
[root@fgedu.net.cn ~]# /bigdata/app/hadoop/bin/hadoop distcp hdfs://fgedu.net.cn:9000/ hdfs://dr.fgedu.net.cn:9000/
# 3. 定期演练
# 每季度进行一次全集群故障演练，验证恢复流程
from bigdata视频:www.itpux.com
Part03-集群崩溃恢复实施方案
3.1 NameNode崩溃恢复
# 1. 检查NameNode状态
[root@fgedu.net.cn ~]# jps
12345 ResourceManager
67890 NodeManager
# NameNode进程不存在
# 2. 检查NameNode日志
[root@fgedu.net.cn ~]# tail -n 100 /bigdata/app/hadoop/logs/hadoop-fgedu-namenode-fgedu.net.cn.log
2026-04-08 10:00:00,123 ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: Failed to start namenode.
java.io.IOException: NameNode metadata corruption
# 3. 从备份恢复NameNode
[root@fgedu.net.cn ~]# stop-dfs.sh
[root@fgedu.net.cn ~]# rm -rf /bigdata/fgdata/hdfs/namenode/current
[root@fgedu.net.cn ~]# cp -r /bigdata/backup/namenode/20260407 /bigdata/fgdata/hdfs/namenode/current
[root@fgedu.net.cn ~]# chown -R fgedu:fgedu /bigdata/fgdata/hdfs/namenode/current
[root@fgedu.net.cn ~]# start-dfs.sh
# 4. 验证NameNode状态
[root@fgedu.net.cn ~]# hdfs dfsadmin -report
Configured Capacity: 1099511627776 (1024.0 GB)
Present Capacity: 879609302016 (819.2 GB)
DFS Remaining: 879609302016 (819.2 GB)
DFS Used: 0 (0 B)
DFS Used%: 0.00%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
学习交流加群风哥QQ113257174
3.2 DataNode崩溃恢复
# 1. 检查DataNode状态
[root@fgedu.net.cn ~]# hdfs dfsadmin -report | grep -A 5 “DataNodes”
Live datanodes (3):
Name: 192.168.1.101:9866 (datanode1.fgedu.net.cn)
Hostname: datanode1.fgedu.net.cn
Decommission Status : Normal
Configured Capacity: 366503875925 (341.3 GB)
# 2. 启动故障DataNode
[root@datanode2 ~]# systemctl start hadoop-datanode
[root@datanode2 ~]# jps
12345 DataNode
67890 NodeManager
# 3. 检查DataNode注册情况
[root@fgedu.net.cn ~]# hdfs dfsadmin -report | grep -A 5 “datanode2”
Name: 192.168.1.102:9866 (datanode2.fgedu.net.cn)
Hostname: datanode2.fgedu.net.cn
Decommission Status : Normal
Configured Capacity: 366503875925 (341.3 GB)
Present Capacity: 293203099060 (273.0 GB)
# 4. 数据块恢复
[root@fgedu.net.cn ~]# hdfs fsck /
Status: HEALTHY
Total size: 107374182400 (100.0 GB)
Total dirs: 1000
Total files: 10000
Total symlinks: 0
Total blocks (validated): 10240 (avg. block size 10485760 B)
Minimally replicated blocks: 10240 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0
Missing replicas: 0 (0.0 %)
Number of data-nodes: 3
Number of racks: 1
Status: HEALTHY
风哥提示：DataNode崩溃后，HDFS会自动进行数据块复制，确保数据冗余
3.3 ResourceManager崩溃恢复
# 1. 检查ResourceManager状态
[root@fgedu.net.cn ~]# jps | grep ResourceManager
# 无输出，ResourceManager未运行
# 2. 启动ResourceManager
[root@fgedu.net.cn ~]# systemctl start hadoop-yarn-resourcemanager
[root@fgedu.net.cn ~]# jps | grep ResourceManager
12345 ResourceManager
# 3. 检查ResourceManager状态
[root@fgedu.net.cn ~]# yarn rmadmin -getServiceState rm1
active
# 4. 恢复任务
[root@fgedu.net.cn ~]# yarn application -list
Application-Id Application-Name Application-Type User Queue State Final-State Progress Tracking-URL
application_1712560000001_0001 WordCount MAPREDUCE fgedu default RUNNING UNDEFINED 50% http://fgedu.net.cn:8088/proxy/application_1712560000001_0001/
# 5. 重启失败任务
[root@fgedu.net.cn ~]# yarn application -kill application_1712560000001_0001
[root@fgedu.net.cn ~]# hadoop jar /bigdata/app/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar wordcount /user/fgedu/input /user/fgedu/output
3.4 全集群崩溃恢复
# 1. 检查集群状态
[root@fgedu.net.cn ~]# jps
# 无Hadoop进程运行
# 2. 按顺序启动集群
# 启动Zookeeper
[root@fgedu.net.cn ~]# /bigdata/app/zookeeper/bin/zkServer.sh start
[root@fgedu-backup.net.cn ~]# /bigdata/app/zookeeper/bin/zkServer.sh start
[root@fgedu-zk3.net.cn ~]# /bigdata/app/zookeeper/bin/zkServer.sh start
# 启动HDFS
[root@fgedu.net.cn ~]# start-dfs.sh
# 启动YARN
[root@fgedu.net.cn ~]# start-yarn.sh
# 3. 检查集群状态
[root@fgedu.net.cn ~]# jps
12345 NameNode
67890 ResourceManager
78901 JobHistoryServer
[root@datanode1 ~]# jps
12345 DataNode
67890 NodeManager
# 4. 验证HDFS状态
[root@fgedu.net.cn ~]# hdfs dfsadmin -report
Configured Capacity: 1099511627776 (1024.0 GB)
Present Capacity: 879609302016 (819.2 GB)
DFS Remaining: 879609302016 (819.2 GB)
DFS Used: 0 (0 B)
DFS Used%: 0.00%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
# 5. 验证YARN状态
[root@fgedu.net.cn ~]# yarn node -list
Total Nodes:3
Node-Id Node-State Node-Http-Address Number-of-Running-Containers
datanode1.fgedu.net.cn:45454 RUNNING datanode1.fgedu.net.cn:8042 0
datanode2.fgedu.net.cn:45454 RUNNING datanode2.fgedu.net.cn:8042 0
datanode3.fgedu.net.cn:45454 RUNNING datanode3.fgedu.net.cn:8042 0
Part04-集群崩溃恢复生产案例与实战讲解
4.1 案例一：NameNode单点故障恢复
案例背景
某生产环境Hadoop集群的NameNode服务器突然宕机，导致整个HDFS服务不可用，业务处理中断。
恢复过程
[root@fgedu.net.cn ~]# ping fgedu.net.cn
# 无响应，服务器宕机
# 2. 切换到备用NameNode
[root@fgedu-backup.net.cn ~]# hdfs haadmin -transitionToActive nn2
# 3. 验证备用NameNode状态
[root@fgedu-backup.net.cn ~]# hdfs haadmin -getServiceState nn2
active
# 4. 检查HDFS状态
[root@fgedu-backup.net.cn ~]# hdfs dfsadmin -report
Configured Capacity: 1099511627776 (1024.0 GB)
Present Capacity: 879609302016 (819.2 GB)
DFS Remaining: 879609302016 (819.2 GB)
DFS Used: 0 (0 B)
DFS Used%: 0.00%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
# 5. 恢复原NameNode
# 修复原NameNode服务器硬件故障后
[root@fgedu.net.cn ~]# start-dfs.sh
[root@fgedu-backup.net.cn ~]# hdfs haadmin -transitionToStandby nn2
[root@fgedu.net.cn ~]# hdfs haadmin -transitionToActive nn1
# 执行结果
# 集群在5分钟内恢复正常，业务中断时间最短
更多视频教程www.fgedu.net.cn
4.2 案例二：DataNode大规模故障恢复
案例背景
某数据中心发生网络故障，导致5个DataNode节点同时离线，集群数据冗余受到影响。
恢复过程
[root@fgedu.net.cn ~]# hdfs dfsadmin -report | grep -A 2 “DataNodes”
Live datanodes (5):
# 正常情况下应该有10个DataNode
# 2. 检查网络故障
[root@fgedu.net.cn ~]# ping datanode6.fgedu.net.cn
# 无响应
# 3. 修复网络故障
# 网络团队修复网络设备故障
# 4. 启动DataNode服务
[root@datanode6 ~]# systemctl start hadoop-datanode
[root@datanode7 ~]# systemctl start hadoop-datanode
[root@datanode8 ~]# systemctl start hadoop-datanode
[root@datanode9 ~]# systemctl start hadoop-datanode
[root@datanode10 ~]# systemctl start hadoop-datanode
# 5. 验证DataNode状态
[root@fgedu.net.cn ~]# hdfs dfsadmin -report | grep -A 2 “DataNodes”
Live datanodes (10):
# 6. 数据块恢复
[root@fgedu.net.cn ~]# hdfs fsck /
Status: HEALTHY
Total size: 536870912000 (500.0 GB)
Total dirs: 5000
Total files: 50000
Total symlinks: 0
Total blocks (validated): 51200 (avg. block size 10485760 B)
Minimally replicated blocks: 51200 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0
Missing replicas: 0 (0.0 %)
Number of data-nodes: 10
Number of racks: 2
Status: HEALTHY
# 执行结果
# 网络故障修复后，DataNode重新上线，HDFS自动恢复数据块冗余
学习交流加群风哥微信: itpux-com
4.3 案例三：全集群断电恢复
案例背景
数据中心发生大面积断电，导致整个Hadoop集群完全 shutdown，所有服务停止运行。
恢复过程
[root@fgedu.net.cn ~]# uptime
10:00:00 up 5 min, 1 user, load average: 0.10, 0.05, 0.01
# 服务器已重启
# 2. 按顺序启动服务
# 启动Zookeeper集群
[root@fgedu-zk1 ~]# /bigdata/app/zookeeper/bin/zkServer.sh start
[root@fgedu-zk2 ~]# /bigdata/app/zookeeper/bin/zkServer.sh start
[root@fgedu-zk3 ~]# /bigdata/app/zookeeper/bin/zkServer.sh start
# 启动HDFS集群
[root@fgedu.net.cn ~]# start-dfs.sh
# 启动YARN集群
[root@fgedu.net.cn ~]# start-yarn.sh
# 启动Hive服务
[root@fgedu.net.cn ~]# /bigdata/app/hive/bin/hive –service metastore &
[root@fgedu.net.cn ~]# /bigdata/app/hive/bin/hive –service hiveserver2 &
# 3. 检查集群状态
[root@fgedu.net.cn ~]# jps
12345 NameNode
67890 ResourceManager
78901 JobHistoryServer
89012 HiveMetastore
90123 HiveServer2
[root@datanode1 ~]# jps
12345 DataNode
67890 NodeManager
# 4. 验证HDFS状态
[root@fgedu.net.cn ~]# hdfs dfsadmin -report
Configured Capacity: 2199023255552 (2048.0 GB)
Present Capacity: 1759218604032 (1638.4 GB)
DFS Remaining: 1759218604032 (1638.4 GB)
DFS Used: 0 (0 B)
DFS Used%: 0.00%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
# 5. 恢复业务任务
[root@fgedu.net.cn ~]# hadoop jar /bigdata/app/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar wordcount /user/fgedu/input /user/fgedu/output
# 执行结果
# 全集群在30分钟内完全恢复，业务正常运行
更多学习教程公众号风哥教程itpux_com
Part05-风哥经验总结与分享
5.1 集群崩溃排查方法论
1. 确认故障范围：确定是单个节点还是整个集群故障
2. 收集故障信息：查看日志、监控数据、系统状态
3. 分析故障原因：根据收集的信息定位故障根因
4. 制定恢复方案：根据故障类型选择合适的恢复策略
5. 执行恢复操作：按照预定方案进行恢复
6. 验证恢复结果：确保集群完全恢复正常
7. 故障复盘：分析故障原因，提出改进措施
风哥提示：集群崩溃排查需要快速、准确，建立标准化的应急响应流程
5.2 最佳实践总结
1. 建立高可用架构：NameNode、ResourceManager高可用
2. 定期备份：定期备份NameNode元数据、Hive元数据等
3. 监控告警：部署完善的监控系统，及时发现异常
4. 应急演练：定期进行故障演练，熟悉恢复流程
5. 文档化：建立详细的运维文档，包括恢复流程
6. 团队培训：培训运维人员掌握故障处理技能
7. 持续改进：根据故障经验不断优化架构和流程
from bigdata视频:www.itpux.com
5.3 常见问题与解决方案
1. NameNode元数据损坏：从备份恢复或使用fsck工具修复
2. DataNode磁盘故障：更换磁盘，重启DataNode服务
3. 网络中断：检查网络设备，修复网络连接
4. 资源不足：增加服务器资源，优化配置
5. 配置错误：检查配置文件，修正错误配置
6. 软件bug：升级到稳定版本，应用补丁
7. 人为误操作：建立操作审批流程，加强权限管理
学习交流加群风哥QQ113257174
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
