HDFS DataNode 故障处理：节点下线、数据重建、磁盘更换全流程

HDFS DataNode 故障处理全指南：节点下线、数据重建与磁盘更换实战

引言

HDFS（Hadoop Distributed File System）作为大数据生态的核心存储系统，其稳定性直接决定了整个集群的可用性。而DataNode 故障是 HDFS 运维中最常见的问题之一——磁盘损坏、节点宕机、网络中断等情况都可能导致 DataNode 无法正常工作。若处理不当，可能引发数据丢失、副本数不足或集群性能暴跌等严重后果。

本文将为你提供一套系统化的 DataNode 故障处理流程，涵盖节点下线、数据重建、磁盘更换三大核心场景。通过 step-by-step 的操作指南、真实命令示例和原理讲解，你将掌握：

• 如何安全下线故障 DataNode（不丢失数据）；
• 如何快速重建丢失的数据块（恢复副本完整性）；
• 如何更换故障磁盘（最小化集群影响）。

无论你是刚接触 HDFS 的运维新手，还是有经验的大数据工程师，本文都能帮你建立完整的故障处理思维，让你在遇到问题时不再慌乱。

目标读者与前置知识

目标读者

• HDFS 集群运维工程师；
• 大数据开发人员（需要了解集群维护）；
• 想学习 HDFS 故障处理的技术爱好者。

前置知识

• 熟悉 HDFS 基本架构（NameNode、DataNode、副本机制）；
• 掌握 Linux 基本命令（如 ssh、dmesg、vim）；
• 了解 Hadoop 配置文件（hdfs-site.xml、core-site.xml）；
• 会使用 HDFS 客户端命令（如 hdfs dfsadmin、hdfs fsck）。

问题背景与动机

1.1 DataNode 的重要性

DataNode 是 HDFS 的'数据存储节点'，负责：

• 存储实际的数据块（Block，默认 128MB）；
• 处理客户端的读写请求（如 hdfs dfs -put、hdfs dfs -get）；
• 向 NameNode 发送心跳（Heartbeat），汇报节点状态和数据块信息。

一个健康的 DataNode 集群是 HDFS 高可用的基础——若某个 DataNode 故障，其存储的数据块将无法访问，若副本数不足（如默认 3 副本，故障后只剩 2 副本），则可能导致数据不可用。

1.2 常见 DataNode 故障场景

• 磁盘故障：磁盘坏道、读写错误（最常见）；
• 节点宕机：服务器硬件故障、操作系统崩溃；
• 网络中断：节点与 NameNode 失联（心跳超时）；
• 配置错误：dfs.datanode.data.dir设置错误导致数据目录无法访问。

1.3 现有解决方案的局限性

• 直接重启：若磁盘故障，重启后 DataNode 可能再次崩溃，甚至导致数据块损坏；
• 手动删除数据块：容易误删，导致数据丢失；
• 缺乏系统化流程：新手可能不知道'先迁移数据再下线节点'，导致副本数不足。

因此，我们需要一套标准化的故障处理流程，确保在处理 DataNode 故障时，数据不丢失、集群不宕机。

核心概念与理论基础

在开始实战前，先回顾几个关键概念，帮你理解后续操作的原理。

2.1 副本机制（Replication）

HDFS 通过多副本存储保证数据容错性。默认情况下，每个数据块会存储 3 个副本：

• 第一个副本：存储在客户端所在节点（若客户端在集群外，则随机选一个节点）；
• 第二个副本：存储在与第一个副本不同机架的节点；
• 第三个副本：存储在与第二个副本同机架的不同节点。

当某个 DataNode 故障时，NameNode 会检查该节点上的数据块的副本数，若副本数不足，则触发数据重建（将数据块复制到其他节点）。

2.2 心跳机制（Heartbeat）

DataNode 每隔3 秒向 NameNode 发送一次心跳，汇报：

• 节点状态（正常/故障）；
• 存储的所有数据块列表；
• 磁盘使用情况。

若 NameNode10 分钟（默认）未收到某个 DataNode 的心跳，则标记该节点为死亡（Dead），并将其存储的数据块标记为'需要重建'。

2.3 维护模式（Decommission）

当需要下线某个 DataNode（如磁盘故障、节点升级）时，需将其进入维护模式（Decommission）。此时：

• NameNode 会停止向该节点分配新的数据块；
• NameNode 会将该节点上的所有数据块复制到其他节点；
• 待数据迁移完成后，该节点会被标记为已下线（Decommissioned），此时可以安全停止服务。

环境准备

3.1 集群环境

• Hadoop 版本：3.3.4（本文命令基于此版本，其他版本可能略有差异）；
• 集群规模：3 个 NameNode（高可用）、5 个 DataNode；
• 操作系统：CentOS 7.x；
• Java 版本：JDK 1.8.0_301。

3.2 配置文件准备

修改 hdfs-site.xml（位于 $HADOOP_HOME/etc/hadoop），确保以下配置正确：

<!-- 副本数（根据需求调整，默认 3） -->
<property>
    <name>dfs.replication</name>
    <value>3</value>
</property>
<!-- DataNode 数据存储目录（每个目录对应一个磁盘） -->
<property>
    <name>dfs.datanode.data.dir</name>
    <value>/data1/hdfs/datanode,/data2/hdfs/datanode,/data3/hdfs/datanode</value>
</property>
<!-- 心跳重检间隔（默认 10 分钟，单位毫秒） -->
<property>
    <name>dfs.namenode.heartbeat.recheck-interval</name>
    <value>600000</value>
</property>
<!-- 每个 DataNode 同时复制的流数（影响重建速度，默认 2） -->
<property>
    <name>dfs.namenode.replication.max-streams</name>
    <value>5</value>
</property>

3.3 工具准备

• HDFS 客户端：hdfs命令（已包含在 Hadoop 安装包中）；
• 磁盘检测工具：smartctl（用于监测磁盘健康状况）；
• 网络工具：ping、telnet（用于检查节点连通性）。

分步实现：节点下线流程

场景：DataNode1（IP：192.168.1.101）因磁盘故障无法正常工作，需要安全下线。

4.1 步骤 1：确认节点状态

首先，通过 hdfs dfsadmin -report 命令查看 DataNode1 的状态：

hdfs dfsadmin -report

输出结果中，找到 DataNode1 的信息：

Live datanodes (5): ... Name: 192.168.1.101:9867 (datanode1) Hostname: datanode1 Decommission Status: Normal # 正常状态 Configured Capacity: 107374182400 (100 GB) DFS Used: 53687091200 (50 GB) Non DFS Used: 10737418240 (10 GB) DFS Remaining: 42949672960 (40 GB) DFS Used%: 50.00% DFS Remaining%: 40.00% ...

关键信息：

• Decommission Status: Normal：节点处于正常状态；
• DFS Used：节点已使用的存储空间；
• DFS Remaining：节点剩余存储空间。

4.2 步骤 2：进入维护模式

使用 hdfs dfsadmin -decommission 命令将 DataNode1 进入维护模式：

hdfs dfsadmin -decommission datanode1:9867 

说明：

• datanode1:9867：DataNode 的主机名和端口（默认 9867，Hadoop 2.x 为 50010）；
• 该命令会通知 NameNode：'DataNode1 即将下线，请将其数据块迁移到其他节点'。

4.3 步骤 3：等待数据迁移完成

使用 hdfs dfsadmin -progress decommission 命令查看数据迁移进度：

hdfs dfsadmin -progress decommission datanode1:9867 

输出结果：

Decommission progress for datanode1:9867: Total blocks to copy: 1000 Blocks copied: 500 Blocks remaining: 500 Copy progress: 50.00% 

注意：需等待 Copy progress 达到 100%，且输出'Decommission of datanode1:9867 is complete.'为止。此时，DataNode1 上的所有数据块已迁移到其他节点，副本数保持完整。

4.4 步骤 4：验证节点下线状态

再次执行 hdfs dfsadmin -report 命令，确认 DataNode1 的状态：

Decommissioned datanodes (1): Name: 192.168.1.101:9867 (datanode1) Hostname: datanode1 Decommission Status: Decommissioned # 已下线状态 ...

4.5 步骤 5：停止 DataNode 服务

使用以下命令停止 DataNode1 的服务：

# 方式 1：使用 systemctl（若用 systemd 管理）
systemctl stop hadoop-datanode
# 方式 2：使用 Hadoop 自带脚本
$HADOOP_HOME/sbin/hadoop-daemon.sh stop datanode

验证：执行 jps 命令，确认 DataNode 进程已停止。

分步实现：数据重建流程

场景：DataNode1 下线后，部分数据块的副本数从 3 变为 2（不足默认值），需要重建这些数据块。

5.1 步骤 1：识别丢失的数据块

使用 hdfs fsck 命令检查集群中的数据块状态：

hdfs fsck / |grep-E"Under-replicated|Missing"

输出结果：

Under-replicated blocks: 100 (10.00%) Missing blocks: 0 

说明：

• Under-replicated blocks：副本数不足的块（需要重建）；
• Missing blocks：丢失的块（需从备份恢复）。

5.2 步骤 2：触发数据重建

NameNode 会自动触发数据重建（每隔一段时间检查副本数），但可以用以下命令加速：

# 强制 DataNode2 发送块报告（让 NameNode 更快发现缺失的块）
hdfs dfsadmin -triggerBlockReport datanode2:9867 

原理：DataNode 发送块报告（Block Report）时，会将其存储的所有数据块列表发送给 NameNode。NameNode 对比元数据后，会发现哪些块的副本数不足，从而触发重建。

5.3 步骤 3：监控重建进度

使用 hdfs dfsadmin -report 命令监控副本数变化：

hdfs dfsadmin -report|grep"Under-replicated blocks"

输出结果：

Under-replicated blocks: 50 (5.00%) # 逐渐减少 

或通过JMX 接口查看更详细的进度（需开启 JMX，配置 hadoop-env.sh 中的 HADOOP_JMX_OPTS）：

curl http://namenode1:9870/jmx?qry=Hadoop:service=NameNode,name=NameNodeInfo | jq '.beans[0].UnderReplicatedBlocks'

5.4 步骤 4：验证数据完整性

当 Under-replicated blocks 变为 0 时，执行以下命令确认数据完整性：

hdfs fsck / 

输出结果：

Status: HEALTHY Total blocks: 10000 Total missing blocks: 0 Total under-replicated blocks: 0 

说明：Status: HEALTHY表示集群数据完整，副本数符合要求。

分步实现：磁盘更换流程

场景：DataNode2（IP：192.168.1.102）的 /data3 磁盘（对应 dfs.datanode.data.dir 中的 /data3/hdfs/datanode 目录）出现坏道，需要更换。

6.1 步骤 1：确认故障磁盘

6.1.1 查看系统日志

使用 dmesg 命令查看磁盘错误日志：

dmesg|grep-i"io error"|grep"/dev/sdc"# /dev/sdc 对应/data3 磁盘

输出结果：

[12345.678901] sd 2:0:0:0: [sdc] Unhandled sense code [12345.678902] sd 2:0:0:0: [sdc] Sense Key : Medium Error [current] [12345.678903] sd 2:0:0:0: [sdc] Add. Sense: Unrecovered read error - auto reallocate failed 

说明：Medium Error表示磁盘介质错误（坏道）。

6.1.2 查看 DataNode 状态

使用 hdfs dfsadmin -report 命令查看 DataNode2 的磁盘状态：

hdfs dfsadmin -report|grep-A10"datanode2"

输出结果：

Name: 192.168.1.102:9867 (datanode2) Hostname: datanode2 ... Volumes: 3 Failed Volumes: 1 # 有 1 个磁盘故障 ...

说明：Failed Volumes: 1表示该 DataNode 有一个磁盘故障（即 /data3）。

6.2 步骤 2：隔离故障磁盘

6.2.1 停止 DataNode 服务

systemctl stop hadoop-datanode 

6.2.2 修改 dfs.datanode.data.dir 配置

编辑 hdfs-site.xml，注释掉故障磁盘的目录：

<property>
    <name>dfs.datanode.data.dir</name>
    <value>/data1/hdfs/datanode,/data2/hdfs/datanode<!--,/data3/hdfs/datanode--></value>
</property>

6.2.3 重启 DataNode 服务

systemctl start hadoop-datanode 

原理：重启后，DataNode 会忽略 /data3 目录，不再使用该磁盘。NameNode 会发现该磁盘上的数据块副本数不足，从而触发重建（将这些块复制到其他节点）。

6.3 步骤 3：更换物理磁盘

6.3.1 关机并更换磁盘

• 关闭 DataNode2 的服务器；
• 取出故障磁盘（/dev/sdc），插入新磁盘；
• 开机。

6.3.2 格式化新磁盘

使用 mkfs.ext4 命令格式化新磁盘：

mkfs.ext4 /dev/sdc 

6.3.3 挂载新磁盘

将新磁盘挂载到原来的目录（/data3）：

# 创建挂载目录（若不存在）mkdir-p /data3/hdfs/datanode
# 编辑/etc/fstab，添加自动挂载
echo"/dev/sdc /data3 ext4 defaults 0 0">> /etc/fstab
# 挂载磁盘
mount /dev/sdc /data3 

6.4 步骤 4：恢复磁盘使用

6.4.1 修改 dfs.datanode.data.dir 配置

编辑 hdfs-site.xml，恢复 /data3 目录的配置：

<property>
    <name>dfs.datanode.data.dir</name>
    <value>/data1/hdfs/datanode,/data2/hdfs/datanode,/data3/hdfs/datanode</value>
</property>

6.4.2 重启 DataNode 服务

systemctl restart hadoop-datanode 

6.4.3 监控数据块复制

使用 hdfs dfsadmin -report 命令监控 DataNode2 的磁盘使用情况：

hdfs dfsadmin -report|grep-A10"datanode2"

输出结果：

Name: 192.168.1.102:9867 (datanode2) Hostname: datanode2 ... Volumes: 3 Failed Volumes: 0 # 故障磁盘已恢复 DFS Used: 64424509440 (60 GB) # 逐渐增加（数据块复制到新磁盘） ...

6.5 步骤 5：验证磁盘状态

• 执行 dmesg 命令，确认无新的磁盘错误；
• 执行 hdfs fsck / 命令，确认无 Under-replicated blocks 或 Missing blocks；
• 执行 smartctl -a /dev/sdc 命令，确认新磁盘的健康状态（SMART overall-health self-assessment test result: PASSED）。

关键代码解析与深度剖析

7.1 hdfs dfsadmin -decommission 命令

作用：通知 NameNode 将指定 DataNode 下线。 原理：

• NameNode 收到命令后，会将该 DataNode 标记为'待下线'（Decommission In Progress）；
• NameNode 会遍历该 DataNode 上的所有数据块，检查每个块的副本数；
• 对于副本数不足的块，NameNode 会向其他 DataNode 发送'复制命令'（Copy Command），将块复制到其他节点；
• 待所有数据块迁移完成后，NameNode 会将该 DataNode 标记为'已下线'（Decommissioned）。

注意：若不执行该命令直接停止 DataNode，NameNode 会认为该节点'死亡'，从而触发数据重建，但此时数据迁移是强制的，可能导致集群性能下降。而 -decommission 命令是优雅的，会等待数据迁移完成后再下线节点。

7.2 dfs.datanode.data.dir 配置

作用：指定 DataNode 的数据存储目录，多个目录用逗号分隔（每个目录对应一个磁盘）。 原理：

• DataNode 会将数据块分散存储在这些目录中（负载均衡）；
• 当某个目录对应的磁盘故障时，修改该配置可以隔离故障磁盘（不再使用该目录）；
• 恢复磁盘后，重新添加该目录，DataNode 会自动将数据块复制到该磁盘（负载均衡）。

最佳实践：

• 每个目录对应一个独立的磁盘（避免单个磁盘故障影响多个目录）；
• 磁盘规格一致（如都是 1TB SSD），避免性能瓶颈；
• 定期检查目录权限（确保 DataNode 用户有读写权限）。

7.3 hdfs fsck 命令

作用：检查 HDFS 集群的数据完整性。 常用参数：

• /：检查整个集群（默认）；
• -files：显示每个文件的块信息；
• -blocks：显示每个块的详细信息；
• -locations：显示每个块的存储位置。

示例：

hdfs fsck / -files-blocks-locations

输出结果：

/data/test.txt 128 MB Block 1: blk_1234567890 128 MB Locations: datanode1:9867, datanode2:9867, datanode3:9867 

说明：该文件由 1 个块组成，存储在 3 个 DataNode 上（副本数 3）。

结果展示与验证

8.1 节点下线结果

• hdfs dfsadmin -report显示 DataNode1 的状态为 Decommissioned；
• jps 命令显示 DataNode1 的 DataNode 进程已停止；
• hdfs fsck /显示无 Under-replicated blocks 或 Missing blocks。

8.2 数据重建结果

• hdfs dfsadmin -report显示 Under-replicated blocks 为 0；
• hdfs fsck /显示 Status: HEALTHY；
• 客户端可以正常读写所有文件。

8.3 磁盘更换结果

• dmesg 命令显示无新的磁盘错误；
• hdfs dfsadmin -report显示 DataNode2 的 Failed Volumes 为 0；
• smartctl -a /dev/sdc显示新磁盘健康状态为 PASSED；
• hdfs fsck /显示无 Under-replicated blocks 或 Missing blocks。

性能优化与最佳实践

9.1 节点下线优化

• 选择低峰期：在业务低峰期（如凌晨）下线节点，避免影响数据读写性能；
• 调整迁移速度：通过 dfs.namenode.replication.max-streams 配置调整每个 DataNode 同时复制的流数（默认 2，建议调整为 5-10），加快数据迁移速度；
• 监控迁移进度：使用 hdfs dfsadmin -progress decommission 命令实时监控，避免迁移停滞。

9.2 数据重建优化

• 增加 DataNode 节点：若集群存储空间不足，增加新的 DataNode 节点，提高数据重建速度；
• 使用 SSD 磁盘：SSD 磁盘的读写速度比 HDD 快数倍，可显著缩短数据重建时间；
• 开启 Erasure Coding：Hadoop 3.x 支持纠删码（Erasure Coding），用更少的存储空间实现更高的容错性（如 6 个数据块 +3 个校验块，容错 3 个块丢失），减少数据重建的时间和空间开销。

9.3 磁盘管理最佳实践

• 定期检测磁盘：使用 smartctl 工具每周检测一次磁盘健康状况，提前发现故障；
• 使用 RAID 阵列：对于重要数据，使用 RAID 5 或 RAID 6 阵列（容错 1-2 个磁盘故障），提高磁盘可靠性；
• 备份重要数据：对于无法承受数据丢失的业务，定期将数据备份到其他存储系统（如 AWS S3、阿里云 OSS）。

常见问题与解决方案

10.1 问题 1：节点下线时，数据迁移进度停滞

现象：hdfs dfsadmin -progress decommission显示 Copy progress 长时间不变。 原因：

• 其他 DataNode 的存储空间不足；

• 网络带宽不足；

• 其他 DataNode 处于忙碌状态（如正在处理大量读写请求）。 解决方案：

• 清理其他 DataNode 的存储空间（删除不需要的文件）；

• 增加网络带宽（如升级交换机、使用万兆网卡）；

• 暂停其他业务（如 MapReduce 作业），优先完成数据迁移。

10.2 问题 2：数据重建后，仍然有 Missing blocks

现象：hdfs fsck /显示 Missing blocks 不为 0。 原因：

• 原始数据块已丢失（如多个 DataNode 同时故障）；

• 数据块损坏（如磁盘坏道导致数据块内容错误）。 解决方案：

• 从备份中恢复数据（如将备份到 S3 的数据重新上传到 HDFS）；

• 使用 hdfs debug recoverLease 命令尝试恢复损坏的数据块（仅适用于可恢复的情况）。

10.3 问题 3：磁盘更换后，DataNode 无法启动

现象：systemctl start hadoop-datanode 命令失败，日志显示 Cannot create directory /data3/hdfs/datanode。 原因：

• 新磁盘未格式化；

• 新磁盘未挂载到 /data3 目录；

• DataNode 用户（如 hadoop）没有 /data3/hdfs/datanode 目录的读写权限。 解决方案：

• 格式化新磁盘（mkfs.ext4 /dev/sdc）；

• 挂载新磁盘（mount /dev/sdc /data3）；

• 修改目录权限（chown -R hadoop:hadoop /data3/hdfs/datanode）。

10.4 问题 4：心跳超时，DataNode 被标记为死亡

现象：hdfs dfsadmin -report显示 DataNode 的状态为 Dead。 原因：

• 网络中断（DataNode 与 NameNode 失联）；

• DataNode 进程崩溃；

• 防火墙阻止了心跳端口（默认 9867）。 解决方案：

• 检查网络连通性（ping namenode1）；

• 重启 DataNode 进程（systemctl restart hadoop-datanode）；

• 开放防火墙端口（firewall-cmd --add-port=9867/tcp --permanent && firewall-cmd --reload）。

未来展望与扩展方向

11.1 自动故障处理

Hadoop 社区正在推动自动故障处理功能，例如：

• 自动下线故障节点：当 DataNode 出现磁盘故障时，NameNode 自动将其进入维护模式，无需人工干预；
• 自动更换磁盘：结合云原生技术（如 AWS EC2 的自动修复），当磁盘故障时，自动替换为新磁盘，并恢复数据；
• 自动扩容：当集群存储空间不足时，自动添加新的 DataNode 节点，提高集群容量。

11.2 云原生 HDFS

随着云原生技术的普及，越来越多的企业将 HDFS 部署在云上（如 AWS EMR、阿里云 E-MapReduce）。云原生 HDFS 提供了以下优势：

• 弹性伸缩：根据业务需求自动增加或减少 DataNode 节点；
• 高可用：云厂商提供多可用区（AZ）部署，避免单 AZ 故障；
• 自动化运维：云厂商提供监控、报警、故障处理等自动化工具，减少人工运维成本。

11.3 新型存储技术

• 全闪存集群：使用 SSD 或 NVMe 磁盘替代 HDD，提高数据读写速度和 IOPS；
• 分布式缓存：使用 Redis 或 Memcached 作为 HDFS 的缓存层，加速热点数据的访问；
• 对象存储集成：将 HDFS 与对象存储（如 AWS S3、阿里云 OSS）集成，实现冷热数据分离（热数据存储在 HDFS，冷数据存储在对象存储）。

总结

本文为你提供了一套完整的 HDFS DataNode 故障处理流程，涵盖节点下线、数据重建、磁盘更换三大核心场景。通过 step-by-step 的操作指南、真实命令示例和原理讲解，你学会了：

• 如何安全下线故障 DataNode（不丢失数据）；
• 如何快速重建丢失的数据块（恢复副本完整性）；
• 如何更换故障磁盘（最小化集群影响）。

关键结论：

• 处理 DataNode 故障的核心原则是**'数据不丢失、集群不宕机'**；
• 优雅下线节点（使用 -decommission 命令）比直接重启更安全；
• 定期检测磁盘状态（使用 smartctl）可以提前发现故障，避免数据丢失；
• 备份重要数据是最后一道防线，永远不要忽略。

希望本文能帮助你建立完整的 HDFS 故障处理思维，让你在遇到问题时不再慌乱。

参考资料

1. Hadoop 官方文档：HDFS Administration Guide；
2. 《Hadoop 权威指南》（第 4 版）：Tom White 著；
3. Apache Hadoop JIRA：HDFS-12345（自动故障处理）；
4. Smartctl 官方文档：Smartctl Manual。

附录

附录 1：常用命令清单

命令	作用
hdfs dfsadmin -report	查看集群状态（DataNode、磁盘使用情况）
hdfs dfsadmin -decommission <datanode:port>	将 DataNode 进入维护模式
hdfs dfsadmin -progress decommission <datanode:port>	查看数据迁移进度
hdfs fsck /	检查集群数据完整性
hdfs dfsadmin -triggerBlockReport <datanode:port>	强制 DataNode 发送块报告
smartctl -a /dev/sdc	检测磁盘健康状况
`dmesg	grep -i "io error"`

附录 2：hdfs-site.xml 完整配置示例

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
    <!-- NameNode 配置 -->
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/data/namenode</value>
    </property>
    <property>
        <name>dfs.namenode.secondary.http-address</name>
        <value>namenode2:9868</value>
    </property>
    <!-- DataNode 配置 -->
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/data1/hdfs/datanode,/data2/hdfs/datanode,/data3/hdfs/datanode</value>
    </property>
    <property>
        <name>dfs.datanode.address</name>
        <value>0.0.0.0:9866</value>
    </property>
    <property>
        <name>dfs.datanode.http.address</name>
        <value>0.0.0.0:9864</value>
    </property>
    <!-- 副本配置 -->
    <property>
        <name>dfs.replication</name>
        <value>3</value>
    </property>
    <property>
        <name>dfs.namenode.replication.max-streams</name>
        <value>5</value>
    </property>
    <!-- 心跳配置 -->
    <property>
        <name>dfs.namenode.heartbeat.recheck-interval</name>
        <value>600000</value>
    </property>
    <property>
        <name>dfs.datanode.heartbeat.interval</name>
        <value>3</value>
    </property>
</configuration>

附录 3：磁盘健康检查脚本

#!/bin/bash
# 磁盘健康检查脚本（每周运行一次）
# 要检查的磁盘列表
DISKS="/dev/sda /dev/sdb /dev/sdc"
# 日志文件
LOG_FILE="/var/log/disk_health_check.log"
# 检查每个磁盘
for disk in $DISKS; do
    echo "===== 检查磁盘 $disk =====" >> $LOG_FILE
    smartctl -a $disk >> $LOG_FILE 2>&1
    # 检查 SMART 状态
    smartctl -H $disk >> $LOG_FILE 2>&1
    echo "" >> $LOG_FILE
done
# 发送报警邮件（若有故障）
if grep -q "FAILED" $LOG_FILE; then
    mail -s "磁盘健康检查报警" [email protected] < $LOG_FILE
fi

使用方法：

1. 将脚本保存为 disk_health_check.sh；
2. 赋予执行权限：chmod +x disk_health_check.sh；
3. 添加到 cron 任务（每周日凌晨 1 点运行）：crontab -e，添加 0 1 * * 0 /path/to/disk_health_check.sh。