适用范围与恢复目标
本文以 Apache Hadoop 3.4.1 的 HDFS QJM 高可用架构为基线，用于计划切换和灾难恢复演练前的设计核对，不提供直接切换生产节点的执行脚本。NFS HA、Observer NameNode、联邦与厂商托管形态需要按对应文档增加边界。示例没有在真实环境执行，状态为 PENDING。
先区分两个目标：高可用关注故障后服务多久恢复，灾难恢复关注哪些数据能够找回。分别定义可接受恢复时间、数据恢复点、涉及路径以及业务写入的归属。不能只用“有两台 NameNode”代替恢复目标，也不能用最近一次快照时间直接声称满足所有业务的恢复点要求。
QJM、Standby 与自动切换的关系
Active NameNode 把元数据变更写入 JournalNode 多数派，Standby 持续读取 edits。QJM 必须有可用多数派；例如三节点部署失去其中两个后不能继续满足多数写入，节点应分布在实际独立的故障域。自动切换通过 ZooKeeper 和 ZKFC 协调，JournalNode 的日志职责与 ZooKeeper 的协调职责不同。
QJM 约束共享日志单写，但旧 Active 在失去写入资格后仍可能短暂服务陈旧读取，因此 fencing 仍有意义。不能把返回成功却未隔离旧节点的脚本当作已经证明隔离有效。机制与配置边界依据 Hadoop 3.4.1 QJM HA 指南。
绘制故障域与依赖清单
拓扑应标明所有 NameNode、JournalNode、ZooKeeper、ZKFC、客户端逻辑 nameservice，以及承载配置与认证的依赖。补充机架、可用区、共享磁盘、DNS 和网络路径，找出看起来多副本却共用单点的组件。以维护一个机架为例，逐项说明剩余 JournalNode 和 ZooKeeper 是否仍有多数派、客户端能否到达接管节点。
再列出 HDFS 路径与业务系统关系：Hive 等目录注册、Spark checkpoint、下游数据消费和调度器均可能依赖相同 nameservice。切换前先找到固定连接到物理 NameNode 地址的客户端；服务端成功接管并不保证这些客户端会自动恢复。
切换前做有限角色与健康核对
以下仅适用于已确认的单个 nameservice，读取角色与健康，不触发切换。-ns 显式选择命名服务，其格式可对照 Hadoop 3.4.1 通用 haadmin 用法：
hdfs getconf -confKey fs.defaultFS
hdfs haadmin -ns REPLACE_WITH_NAMESERVICE -getServiceState REPLACE_WITH_NN_A
hdfs haadmin -ns REPLACE_WITH_NAMESERVICE -getServiceState REPLACE_WITH_NN_B
hdfs haadmin -ns REPLACE_WITH_NAMESERVICE -checkHealth REPLACE_WITH_NN_B角色输出 active、standby 等说明当前查询对象报告的服务状态，不能单独证明业务连通、共享日志新鲜度和隔离有效。checkHealth 要保留退出状态与错误输出，不能仅按“终端没有文字”判为健康。另行查看同窗口的 edits 跟踪进度、JournalNode 错误、ZKFC 选举记录和已知客户端错误。命令语义见 HDFS Commands Guide。
计划演练按故障类型分别组织
第一轮验证客户端经逻辑入口访问和长连接重连，第二轮验证单个 NameNode 故障，第三轮在隔离环境验证网络分区与 fencing。每轮只引入一个故障，记录触发、检测、角色变化、客户端恢复与数据核验的时间点，再撤销本轮故障条件。不要同时停止多个仲裁组件后用一次“启动成功”宣告方案可靠。
演练使用专用目录与可追踪序号，不直接借用生产数据作为试写目标。验证窗口同时覆盖读请求、文件创建与关闭、作业重试和重连后的错误比例。只在维护窗口的明确范围内实施故障注入；本文提供的是演练设计，具体执行命令应从实际部署生成并评审。
备份必须同时覆盖元数据和数据
NameNode 的 fsimage 与 edits 用于恢复命名空间，但它们不包含所有业务文件内容；只有元数据备份而没有可用 DataNode 块或独立数据副本，不能完成文件恢复。配置、认证引用、加密相关依赖和目录权限也要纳入恢复清单，秘密材料只保存受控引用，避免放入公开演练报告。
HDFS snapshot 为受支持目录保留时间点视图，适合提供误变更前的文件入口，但它仍依赖原集群和相关数据块，不能替代独立故障域的灾备副本。保留快照会影响实际可释放空间，清理评估要计算这一点。快照语义见 HDFS Snapshots。
隔离恢复的验收样本如何选
按业务关键性挑选已知目录与文件，保存相同生成窗口的文件清单、大小、业务记录数或业务摘要；仅检查路径存在不足以证明内容正确。恢复环境应与生产写入入口隔离，并明确集群标识、存储位置、认证来源及计算任务的输出目标，防止恢复的作业向生产继续写数据。
用一份完整输入清单解释“能恢复到哪一刻”：元数据检查点、连续 edits、数据副本窗口和外部目录信息缺一项就记录缺口。恢复演练实际耗时应从可用备份定位开始计，到业务验收通过结束，而不是只测 NameNode 启动时间。
常见误区与事故分流
把 SecondaryNameNode 视为自动接管节点，会忽略 HA 配置与同步机制；把“只有一个 Active”视为全部健康，会忽略陈旧读取与客户端入口；把手工 transitionToActive 当作常规故障恢复，会绕开它本身不提供的 fencing。上述操作边界在官方命令指南中有明确区分，本文不以强制参数处理不确定角色。
如果只是一组 DataNode 失联，应先核查块健康与故障域，不能因为 HDFS 告警就进行 NameNode 切换。如果同窗出现多组件失联、日志多数派不可达或旧主无法隔离，停止计划演练，保留角色和日志证据并进入事故流程。日常基线可参考 HDFS 健康巡检。
验收与回退边界
一次 HA 演练的完成标准应包括角色收敛、日志多数派可用、隔离结果、客户端恢复和专用样本一致性。一次灾难恢复则要另外提交恢复输入完整性、实际恢复点、业务数据检查与耗时，二者不能互相替代。未覆盖的机架故障、凭据失效等情况要明确列出，不能推断已验证。
新 Active 已承接写入后，回退必须保持 edits 连续性并走受控切换流程，不能恢复旧目录镜像后直接重新上线。灾备实例已经接收新写入时，原集群回切涉及数据重新同步和业务写入归属，不能简单更改 DNS。初学者可先阅读 Hadoop 架构基础，确认每项恢复动作影响的组件。