企业官网建设流程全解析

1. 什么是Hadoop HA，它到底解决了什么问题？

Hadoop HA（High Availability，高可用）不是某个新装的插件，也不是一个独立软件包，而是对Hadoop核心组件——特别是NameNode——进行架构级重构后形成的一套容灾保障机制。简单说，它让Hadoop集群告别了那个“单点故障即全盘瘫痪”的脆弱时代。我第一次在某高校大数据实验室部署HDFS时，就吃过这个亏：NameNode进程意外退出，整个集群写入中断近40分钟，下游所有ETL任务全部卡死，日志里全是Connection refused to namenode:8020。那时候还没上HA，只能手动重启、等待元数据加载、再逐个检查DataNode心跳——整个过程像在修一台没有说明书的老式收音机。

HA的核心目标非常务实：确保NameNode服务在任意单节点宕机、磁盘损坏、网络隔离甚至误操作删除fsimage的情况下，仍能持续对外提供读写能力，RTO（恢复时间目标）控制在秒级，RPO（恢复点目标）趋近于零。它不追求“永远不坏”，而是追求“坏了也不影响业务”。这背后依赖三个关键支撑：一是双NameNode热备架构（Active/Standby），二是共享编辑日志（EditLog）的可靠存储（通常用QJM或NFS），三是自动故障转移机制（ZKFC + ZooKeeper）。这三个模块缺一不可，任何一个环节设计不当，HA就会变成“纸面高可用”——看着配置全绿，真出事却切不过去。

很多人误以为配完dfs.ha.automatic-failover.enabled=true就万事大吉，其实这只是打开了自动切换的开关，真正的“肌肉”藏在底层：QJM如何保证JournalNode间日志同步的一致性？ZKFC怎么判断Active节点是否真的失联而非只是网络抖动？ZooKeeper的奇数节点部署为何必须避开同一机架？这些细节直接决定HA是真保险，还是假把式。接下来我会从设计逻辑、配置实操、参数调优到排障现场，一层层剥开，不讲虚的，只说我在多个生产环境踩坑后验证过的硬核要点。

2. HA架构选型与设计逻辑：为什么选QJM而不是NFS？

2.1 QJM vs NFS：不只是“用哪个”的选择题

在Hadoop 2.0之后，官方明确将Quorum Journal Manager（QJM）作为HA的首选共享存储方案，而NFS仅作为兼容性选项保留。这不是版本迭代的偶然，而是由分布式系统的基本原理决定的。我们来拆解两者的本质差异：

• NFS方案：依赖一台外部NFS服务器挂载为共享目录，所有NameNode将EditLog写入该目录。问题在于：NFS本身是单点——一旦NFS服务宕机或网络中断，两个NameNode同时失去日志写入能力，Active会立即报错退出，Standby也无法接管，集群直接进入只读或不可用状态。更致命的是，NFS的文件锁机制在高并发写入下容易出现脑裂（Split-Brain），即两个NameNode都认为自己是Active，各自接受客户端请求，导致元数据不一致，fsimage彻底损坏。

• QJM方案：由3个或5个独立的JournalNode进程组成法定人数（Quorum）集群。每个EditLog写入请求必须被超过半数节点（majority）成功响应才视为提交成功。例如3节点集群，需至少2个JournalNode写入成功；5节点则需3个。这种设计天然具备容错性：即使1个JournalNode宕机，剩余2个仍能组成法定人数，服务不受影响；即使网络分区，只要任一分区拥有法定节点数，就能继续提供服务，避免脑裂。它的共识模型本质上是简化的Paxos变种，比NFS的强一致性模型更适合分布式场景。

提示：QJM的节点数必须为奇数（3/5/7），这是为了在节点故障时能明确划分“多数派”。偶数节点（如4个）在2-2分区时无法判定哪边是多数，系统将拒绝服务以保安全。

2.2 为什么推荐3节点QJM？5节点何时必须上？

生产环境中，3节点QJM是绝大多数场景的黄金配置。它在成本、复杂度和可靠性之间取得最佳平衡：

• 容忍1个节点故障（RTO≈5秒内完成故障转移）
• 部署简单：3台普通服务器即可，无需专用存储设备
• 资源开销低：每个JournalNode内存占用仅256MB左右，CPU负载极轻

但当你遇到以下情况时，必须升级到5节点：

1. 集群规模超2000节点：海量DataNode的心跳和块汇报会显著增加EditLog写入频率，3节点QJM在峰值期可能出现写入延迟，导致ZKFC误判Active失联；
2. 跨机房部署：例如JournalNode分布在A机房（2台）、B机房（3台），当A机房整体断网时，B机房3台仍能组成法定人数，保障服务连续；
3. SLA要求99.99%以上：5节点可容忍2节点故障，RTO进一步压缩至2秒内，满足金融级可用性需求。

我曾在一个电商实时风控项目中坚持用3节点QJM，结果在一次机房空调故障导致2台JournalNode温度过高自动降频，写入延迟飙升至8秒，ZKFC连续触发3次误切换，造成上游Flink作业重复消费。事后复盘，根本原因就是低估了硬件老化对QJM响应时间的影响——5节点在此场景下是刚需，不是“可选”。

2.3 ZooKeeper：不是配个IP就行，它的部署本身就是HA的第一道防线

ZooKeeper在HA中承担两个不可替代的角色：

• 状态协调器：记录当前Active NameNode的身份，供ZKFC查询；
• 故障探测器：ZKFC通过在ZK中创建临时节点（ephemeral znode）来宣告自身存活，一旦ZK检测到该节点消失，立即通知其他ZKFC发起选举。

因此，ZooKeeper集群自身的高可用，是整个Hadoop HA的基石。常见错误配置包括：

• 混部在同一物理机：把3个ZooKeeper Server全装在一台服务器上，等于把鸡蛋放在一个篮子里；
• 未配置myid文件：ZK启动时依赖/var/lib/zookeeper/myid中的数字标识身份，漏配会导致集群无法初始化；
• tickTime设置过大：默认2000ms，但在高负载服务器上建议调小至1000ms，加快故障感知速度（需同步调整initLimit/syncLimit）。

实测经验：ZooKeeper节点应严格遵循“三隔离”原则——物理隔离（不同服务器）、网络隔离（不同交换机）、电源隔离（不同UPS）。某次某公司因ZK集群3台机器共用同一台接入交换机，该交换机光模块突发故障，导致ZK集群脑裂，Hadoop HA自动切换失败，集群离线17分钟。教训很痛：基础设施的可靠性，永远是上层应用高可用的前提。

3. 核心配置详解与实操步骤：从零开始搭建可落地的HA集群

3.1 环境准备与基础约定

在动手前，请确认以下前提条件已满足（这是后续所有配置生效的基础）：

• 所有节点（NameNode、DataNode、JournalNode、ZooKeeper）已配置免密SSH互通，且用户为同一非root账户（如hdfs），这是Hadoop脚本执行的前提；
• 所有节点时间已通过NTP同步，误差<500ms（ntpq -p验证），时间不同步会导致ZKFC选举失败；
• DNS解析正常：/etc/hosts中需正反向解析所有节点主机名（如nn1.hadoop→192.168.1.10，且ping nn1.hadoop能通）；
• Java版本统一为JDK 8u191+（Hadoop 3.x要求JDK 8u161+），java -version输出一致。

注意：不要试图用localhost或127.0.0.1代替真实主机名，Hadoop内部大量使用主机名做服务发现，localhost会导致RPC连接失败。

我们以一个典型生产环境为例，规划如下节点角色：

此规划将JournalNode分散在NameNode和独立节点上，既节省资源又避免单点依赖。ZooKeeper独立部署，确保其稳定性不受Hadoop组件影响。

3.2 ZooKeeper集群部署（3节点）

步骤1：下载并解压ZooKeeper
在zk1.hadoop、zk2.hadoop、zk3.hadoop上执行：

wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz tar -xzf zookeeper-3.4.14.tar.gz -C /opt/ ln -s /opt/zookeeper-3.4.14 /opt/zookeeper

步骤2：创建数据目录与myid文件

mkdir -p /var/lib/zookeeper # 在zk1.hadoop上执行： echo "1" > /var/lib/zookeeper/myid # 在zk2.hadoop上执行： echo "2" > /var/lib/zookeeper/myid # 在zk3.hadoop上执行： echo "3" > /var/lib/zookeeper/myid

步骤3：配置zoo.cfg
编辑/opt/zookeeper/conf/zoo.cfg：

tickTime=2000 initLimit=10 syncLimit=5 dataDir=/var/lib/zookeeper clientPort=2181 autopurge.snapRetainCount=3 autopurge.purgeInterval=1 # 三台ZK Server的集群配置（务必按实际IP修改） server.1=zk1.hadoop:2888:3888 server.2=zk2.hadoop:2888:3888 server.3=zk3.hadoop:2888:3888

关键参数说明：

• 2888是Follower连接Leader的端口，3888是Leader选举通信端口；
• initLimit表示Follower在启动时与Leader完成数据同步的最大tick数（此处10×2000ms=20秒），过小会导致启动失败；
• syncLimit表示Follower与Leader心跳超时的最大tick数（5×2000ms=10秒），过小易引发误踢出集群。

步骤4：启动并验证
每台ZK节点执行：

/opt/zookeeper/bin/zkServer.sh start # 检查状态（应显示Mode: follower 或 Mode: leader） /opt/zookeeper/bin/zkServer.sh status # 测试连通性（在任意节点执行） echo stat | nc zk1.hadoop 2181 | grep Mode

3.3 Hadoop核心配置（hdfs-site.xml与core-site.xml）

hdfs-site.xml配置要点（所有节点相同）

<configuration> <!-- 1. 启用HA模式 --> <property> <name>dfs.nameservices</name> <value>mycluster</value> <description>逻辑集群名，所有HA配置以此为基础</description> </property> <!-- 2. 定义两个NameNode的ID --> <property> <name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2</value> <description>nn1和nn2是NameNode的逻辑ID，非主机名</description> </property> <!-- 3. 配置每个NameNode的RPC地址 --> <property> <name>dfs.namenode.rpc-address.mycluster.nn1</name> <value>nn1.hadoop:8020</value> </property> <property> <name>dfs.namenode.rpc-address.mycluster.nn2</name> <value>nn2.hadoop:8020</value> </property> <!-- 4. 配置Web UI地址（用于监控） --> <property> <name>dfs.namenode.http-address.mycluster.nn1</name> <value>nn1.hadoop:9870</value> </property> <property> <name>dfs.namenode.http-address.mycluster.nn2</name> <value>nn2.hadoop:9870</value> </property> <!-- 5. QJM共享编辑日志配置 --> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://jn1.hadoop:8485;jn2.hadoop:8485;jn3.hadoop:8485/mycluster</value> <description>注意：此处jn1/jn2/jn3需替换为你的JournalNode主机名，端口固定8485</description> </property> <!-- 6. JournalNode本地数据目录 --> <property> <name>dfs.journalnode.edits.dir</name> <value>/var/lib/hadoop/journal</value> </property> <!-- 7. 启用自动故障转移 --> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property> <!-- 8. 指定ZooKeeper集群地址 --> <property> <name>ha.zookeeper.quorum</name> <value>zk1.hadoop:2181,zk2.hadoop:2181,zk3.hadoop:2181</value> </property> <!-- 9. SSH故障转移实现类（需确保hdfs用户有sudo权限） --> <property> <name>dfs.ha.fencing.methods</name> <value>sshfence</value> </property> <property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/home/hdfs/.ssh/id_rsa</value> </property> <!-- 10. DataNode向所有NameNode注册 --> <property> <name>dfs.client.failover.proxy.provider.mycluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> </configuration>

core-site.xml配置（所有节点）

<configuration> <!-- 指向逻辑集群名，客户端通过此访问HA集群 --> <property> <name>fs.defaultFS</name> <value>hdfs://mycluster</value> </property> <!-- ZooKeeper地址，供客户端获取Active NN信息 --> <property> <name>ha.zookeeper.quorum</name> <value>zk1.hadoop:2181,zk2.hadoop:2181,zk3.hadoop:2181</value> </property> </configuration>

关键细节：dfs.namenode.rpc-address.mycluster.nn1中的mycluster和nn1必须与dfs.nameservices及dfs.ha.namenodes.mycluster的值严格匹配，大小写敏感。一个字符错误会导致NameNode not formatted等诡异错误。

3.4 JournalNode部署与格式化

步骤1：在所有JournalNode节点（nn1.hadoop, nn2.hadoop, jn1.hadoop）启动JournalNode

# 创建数据目录 mkdir -p /var/lib/hadoop/journal # 启动JournalNode（后台运行） hdfs --daemon start journalnode # 验证进程 jps | grep JournalNode

步骤2：格式化Active NameNode的元数据（仅在nn1.hadoop执行）

# 此命令会生成fsimage和VERSION文件 hdfs namenode -format # 启动nn1为NameNode（此时是standalone模式） hdfs --daemon start namenode

步骤3：同步元数据到Standby NameNode（在nn2.hadoop执行）

# 从nn1拉取最新fsimage和edits hdfs namenode -bootstrapStandby # 启动nn2 hdfs --daemon start namenode

此时nn1和nn2都处于standalone模式，可通过http://nn1.hadoop:9870和http://nn2.hadoop:9870分别查看UI，状态均为"Standby"。

步骤4：初始化ZooKeeper中的HA状态（在任意NameNode节点执行）

hdfs zkfc -formatZK

此命令会在ZooKeeper中创建/hadoop-ha/mycluster路径，并写入初始状态。执行后，用ZK客户端验证：

/opt/zookeeper/bin/zkCli.sh -server zk1.hadoop:2181 ls /hadoop-ha/mycluster # 应返回空列表，表示初始化成功

3.5 启动HA集群与首次手动切换测试

启动顺序至关重要（必须严格遵守）：

1. 先启JournalNode（所有节点）：hdfs --daemon start journalnode
2. 再启ZooKeeper（所有节点）：/opt/zookeeper/bin/zkServer.sh start
3. 最后启NameNode和ZKFC（所有NameNode节点）：

   hdfs --daemon start namenode hdfs --daemon start zkfc

启动后，观察各节点进程：

• jps应看到JournalNode、NameNode、DFSZKFailoverController（即ZKFC）；
• 访问http://nn1.hadoop:9870和http://nn2.hadoop:9870，其中一个显示"Active"，另一个显示"Standby"；
• 查看ZKFC日志：tail -f $HADOOP_LOG_DIR/hadoop-hdfs-zkfc-nn1.hadoop.log，应有Successfully transitioned to Active state字样。

首次手动切换测试（验证HA基础功能）：

# 在nn1.hadoop上执行（假设nn1当前是Active） hdfs haadmin -failover --forcefence --forceactive nn1 nn2 # 检查结果 hdfs haadmin -getServiceState nn1 # 应返回 standby hdfs haadmin -getServiceState nn2 # 应返回 active

--forcefence参数强制执行隔离（杀死旧Active的namenode进程），--forceactive跳过健康检查直接切换。这是故障演练的必备命令。

4. 参数调优与避坑指南：那些文档里不会写的实战经验

4.1 ZKFC故障转移超时参数深度解析

ZKFC默认的故障检测和切换耗时较长，生产环境必须调优。关键参数位于hdfs-site.xml中：

调优逻辑：将health-monitor.rpc-timeout.ms从45秒降至10秒，意味着ZKFC在10秒内未收到NameNode响应即判定其失联。但需同步降低connect-timeout.ms至500ms，否则网络抖动时可能因连接建立慢而误判。我在线上集群实测：将这组参数优化后，平均故障转移时间从32秒降至6.3秒，完全满足实时计算场景的SLA。

注意：rpc-timeout.ms不能低于connect-timeout.ms的2倍，否则连接未建立就超时，ZKFC会频繁报ConnectException。

4.2 QJM写入性能瓶颈排查与修复

当集群写入吞吐量突降，或ZKFC日志频繁出现JournalOutOfSyncException时，大概率是QJM成为瓶颈。排查步骤：

第一步：检查JournalNode磁盘IO

# 在每个JournalNode上执行 iostat -x 1 3 | grep -E "(Device|journal)" # 关注%util（利用率）和await（平均等待时间） # 若%util > 80% 或 await > 20ms，说明磁盘饱和

第二步：调整JournalNode JVM参数
默认JournalNode使用很小的堆内存（约1GB），在高负载下GC频繁。编辑hadoop-env.sh：

export HADOOP_JOURNALNODE_OPTS="-Xmx4g -Xms4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

将堆内存提升至4GB，并启用G1垃圾收集器，可使QJM写入吞吐量提升3倍以上。

第三步：优化Linux内核参数
JournalNode大量使用小文件写入，需调整：

# 编辑/etc/sysctl.conf vm.swappiness=1 vm.dirty_ratio=60 vm.dirty_background_ratio=20 # 生效 sysctl -p

swappiness=1减少内存交换，dirty_ratio提高脏页刷新阈值，避免频繁刷盘阻塞写入。

4.3 最容易被忽略的3个配置陷阱

陷阱1：dfs.client.failover.max.attempts设为-1
该参数控制客户端重试次数，默认为-1（无限重试）。在Active NameNode宕机后，客户端会不断重试已失效的地址，直到超时（默认21秒），期间所有请求失败。正确做法是设为3-5次：

<property> <name>dfs.client.failover.max.attempts</name> <value>3</value> </property>

配合dfs.client.failover.sleep.base.millis（基础休眠时间，建议200ms）和dfs.client.failover.sleep.max.millis（最大休眠时间，建议1000ms），可实现快速失败、快速重试。

陷阱2：未配置dfs.ha.fencing.ssh.check.interval.ms
SSH隔离（sshfence）是防止脑裂的关键，但默认检查间隔为1000ms。若网络抖动导致SSH连接慢，ZKFC可能在隔离完成前就切换了Standby，引发脑裂。必须显式配置：

<property> <name>dfs.ha.fencing.ssh.check.interval.ms</name> <value>300</value> </property>

将检查间隔缩短至300ms，确保隔离动作及时生效。

陷阱3：dfs.namenode.handler.count未随CPU核数扩展
NameNode处理客户端RPC请求的Handler线程数，默认为10。在24核服务器上，这会导致大量请求排队。公式为：handler_count = CPU_cores × 2，24核服务器应设为48：

<property> <name>dfs.namenode.handler.count</name> <value>48</value> </property>

实测：将handler数从10提升至48后，NameNode RPC队列长度（NumOpsQueued指标）从平均120降至5以下，99分位延迟下降76%。

5. 常见故障与排查技巧实录：从日志定位到根因解决

5.1 故障速查表：高频问题与一键诊断命令

5.2 典型案例：一次真实的“假Active”故障复盘

故障现象：
某天凌晨，监控告警NameNode Active状态异常，登录发现nn1.hadoop UI显示"Active"，但hdfs dfs -ls /返回Connection refused，而nn2.hadoop UI显示"Standby"却能正常执行命令。

排查过程：

1. 检查ZKFC状态：jps显示nn1.hadoop有ZKFC进程，但日志中反复出现Could not find any valid local addresses；
2. 深挖网络配置：ip addr show发现nn1.hadoop的eth0接口IP为192.168.1.10，但/etc/hosts中nn1.hadoop解析到10.0.0.10（旧配置残留）；
3. 验证RPC绑定：netstat -tuln | grep 8020显示NameNode监听在10.0.0.10:8020，而非192.168.1.10:8020；
4. 根因定位：Hadoop启动时读取/etc/hosts确定本机地址，导致NameNode绑定到错误IP，客户端通过mycluster解析到192.168.1.10，但该地址无服务监听。

解决方案：

• 立即修正/etc/hosts，确保nn1.hadoop解析到192.168.1.10；
• 重启nn1.hadoop的NameNode：hdfs --daemon stop namenode && hdfs --daemon start namenode；
• 强制切换回nn1：hdfs haadmin -failover --forcefence --forceactive nn2 nn1。

教训总结：Hadoop对主机名解析极度敏感，任何/etc/hosts的微小错误都会导致服务绑定异常。上线前必须执行hostname -f与ping $(hostname -f)双向验证。

5.3 日志分析黄金法则：3分钟定位90%的HA问题

面对海量日志，我总结出一套高效分析法：

第一步：锁定主日志文件

• NameNode问题：$HADOOP_LOG_DIR/hadoop-hdfs-namenode-*.log
• ZKFC问题：$HADOOP_LOG_DIR/hadoop-hdfs-zkfc-*.log
• JournalNode问题：$HADOOP_LOG_DIR/hadoop-hdfs-journalnode-*.log

第二步：用grep聚焦关键线索（按优先级）

# 1. 查找ERROR和FATAL（最高优先级） grep -i "error\|fatal" hadoop-hdfs-zkfc-nn1.hadoop.log | head -20 # 2. 查找Exception堆栈（定位具体异常类） grep -A 10 "Exception" hadoop-hdfs-namenode-nn1.hadoop.log | head -30 # 3. 查找状态变更记录（了解切换过程） grep -i "transition\|failover\|become" hadoop-hdfs-zkfc-nn1.hadoop.log

第三步：关联时间戳交叉验证
当ZKFC日志显示Transitioning to Active时，立即检查同一时间点的NameNode日志：

# 获取ZKFC切换时间戳（如2023-10-05 02:15:23,456） # 在NameNode日志中搜索该时间附近 sed -n '/2023-10-05 02:15:2[3-4]/p' hadoop-hdfs-namenode-nn1.hadoop.log

若NameNode日志在此时间无Starting services记录，说明切换未真正完成，需检查RPC端口是否被占用或防火墙拦截。

实操心得：我习惯在~/.bashrc中添加别名：alias hlog='grep -i "error\|exception\|failover"'，输入hlog $HADOOP_LOG_DIR/hadoop-hdfs-zkfc-*.log即可一键扫描所有ZKFC日志，效率提升数倍。

6. 运维加固与长期稳定性保障：让HA真正“扛得住”

6.1 自动化健康检查脚本（附完整代码）

人工巡检效率低且易遗漏，我编写了一个Python脚本，每5分钟执行一次，覆盖所有关键维度：

#!/usr/bin/env python3 # save as hdfs_ha_health.py import subprocess, sys, time, logging from datetime import datetime logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') logger = logging.getLogger(__name__) def run_cmd(cmd): try: result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=10) return result.returncode == 0, result.stdout.strip() except Exception as e: return False, str(e) def check_zk_status(): # 检查ZK集群是否健康 cmd = "echo ruok | nc zk1.hadoop 2181" success, out = run_cmd(cmd) if not success or "imok" not in out: logger.error("ZooKeeper cluster unhealthy!") return False return True def check_nn_state(): # 获取两个NN状态 cmd1 = "hdfs haadmin -getServiceState nn1 2>/dev/null | grep active" cmd2 = "hdfs haadmin -getServiceState nn2 2>/dev/null | grep active" s1, _ = run_cmd(cmd1) s2, _ = run_cmd(cmd2) if not (s1 ^ s2): # 必须有且仅有一个active logger.error("NameNode state invalid: both active or both standby") return False return True def check_qjm_write(): # 模拟写入测试 test_file = f"/tmp/health_check_{int(time.time())}" cmd = f"hdfs dfs -touchz {test_file} && hdfs dfs -ls {test_file} && hdfs dfs -rm {test_file}" success, _ = run_cmd(cmd) if not success: logger.error("QJM write test failed!") return False return True if __name__ == "__main__": checks = [ ("ZooKeeper Health", check_zk_status), ("NameNode State", check_nn_state), ("QJM Write", check_qjm_write), ] all_ok = True for name, func in checks: logger.info(f"Running {name} check...") if not func(): all_ok = False if all_ok: logger.info("All health checks passed.") else: logger.error("Health check failed! Alert admin.") # 此处可集成企业微信/钉钉机器人发送告警

赋予执行权限并加入crontab：

chmod +x hdfs_ha_health.py # 每5分钟执行一次 echo "*/5 * * * * /path/to/hdfs_ha_health.py >> /var/log/hdfs_ha_health.log 2>&1" | crontab -

6.2 元数据备份策略：防患于未然的终极保险

HA解决的是服务可用性，但无法防止人为误删或病毒攻击导致的元数据毁灭。必须建立独立于HA的元数据备份体系：

备份内容：

• $HADOOP_HOME/dfs/name/current/下的fsimage_*和edits_*文件；
• $HADOOP_HOME/dfs/journal/mycluster/current/下的所有edits_*文件（QJM日志）；

备份策略（3-2-1原则）：

• **3