Day 22｜高可用与生命周期运维：副本、FE 角色、扩缩容、升级、备份、恢复与容灾

Day 21 完成了 CPU、内存、磁盘、网络、节点和副本的容量规划。容量规划回答“生产集群需要准备多少资源”，今天继续回答“资源投入生产以后，怎样面对节点故障、业务增长、版本变更、误操作和站点级事故”。

生产环境中的稳定性很少来自某一项开关。FE 选举让控制面能够在 Leader 故障后恢复元数据写入，BE 多副本让单节点和单盘故障保持数据可读，Tablet 调度器持续修复异常副本，在线扩缩容帮助集群跨越容量边界，滚动升级控制版本变更风险，回收站和远端快照提供历史恢复点。每一层都有自己的适用范围，也都有无法覆盖的故障。

完成今天的学习后，你应当能够：

解释 FE Follower、Observer 与当前 Master 的关系，以及多数派写入的基本要求；
判断 1 Follower + Observer 与 3 Follower 两种部署方式在元数据写高可用上的差异；
读取 Tablet 和 Replica 健康状态，理解自动修复、均衡与 Colocate 约束；
设计 FE、BE 的在线扩容与安全缩容流程；
编制包含版本路径、元数据兼容测试、金丝雀节点和回退条件的滚动升级计划；
建立 Repository，执行数据库、表或分区级 Backup / Restore；
在误删、逻辑污染、节点损坏和整集群故障下选择合适的恢复路径；
用 RPO、RTO、监控证据和定期演练把“具备能力”转化为“可以恢复”。

零、先校准当前 4.x 的运维口径

你提供的培训材料第 230–244 页已经覆盖生产拓扑、Follower 与 Observer、高可用、节点标签、Rebalance、回收站、扩容、滚动升级和 S3 备份。这套框架仍然适合教学，Day 22 按 2026 年 8 月的官方文档更新了几个容易影响生产决策的细节。

0.1 FE 只有 Follower 与 Observer 两种配置角色

当前 Master 是 Follower 组中被选出的节点。所有 Follower 组成可选举组，元数据日志需要得到多数派确认才算成功；Observer 同步已经提交的元数据日志并提供读取服务，不参与投票，也不会被选为 Master。[1]

因此，两种常见拓扑有不同目标：

1 Follower + 2 Observers
    控制面结构简单
    Master 宕机后没有其他 Follower 可以接替
    元数据写入存在单点

3 Followers + N Observers
    Follower 多数派保障元数据写高可用
    Observer 按查询入口和元数据读取压力增加

生产系统需要元数据写高可用时，推荐 3 个或 5 个 Follower。扩展 FE 读取能力时增加 Observer。把“3 个 FE”写进采购单仍然不够，还要明确三台 FE 的角色。

0.2 副本修复由后台调度完成

当前官方副本管理以 TabletChecker 和 TabletScheduler 为核心：前者持续扫描 Tablet 健康状态，后者按照优先级、节点负载、Tag、介质和 Colocate 约束生成 Clone、Repair 与 Balance 任务。[2]

这意味着副本故障排查需要观察后台调度链路。单条查询成功只能说明当前查询找到了可用副本，无法证明缺失副本已经恢复。

0.3 升级路径需要逐级推进

当前官方升级规则是：同一 Feature 版本内的 Patch 可以直接滚动升级；跨 Feature 版本按相邻版本逐级升级；跨 Major 版本先升级到当前 Major 的最新 Feature 版本，再进入下一 Major。官方建议每次升级前都执行 FE 元数据兼容性测试。[3]

升级顺序保持清晰：关闭副本修复与均衡，先升级 BE，再升级 FE；FE 中先升级 Observer 和非 Master Follower，当前 Master 最后升级；完成后重新开启调度。

0.4 Backup / Restore 的当前边界

当前 4.x 的 Backup / Restore 支持数据库、表和分区级全量快照，Repository 可以放在 S3 兼容对象存储、HDFS 等远端存储。该能力目前只支持存算一体模式，只支持 OLAP 表，不包含异步物化视图，也不支持带 Storage Policy 的表；同一数据库同时只能运行一个 Backup 或 Restore 任务。[4]

分区级快照可以形成接近增量备份的效果，底层仍然属于全量快照能力。恢复方案必须把异步物化视图重建、动态分区重新启用、Colocate 属性检查和权限恢复纳入步骤。

0.5 回收站保留时间应以配置为准

旧培训材料使用“默认保留 1 天”的简化口径。当前官方文档强调回收站保留时间可配置，误删后应先执行 SHOW CATALOG RECYCLE BIN 判断对象是否仍可恢复；DROP ... FORCE 会跳过回收站，需要从备份恢复。[5]

0.6 当前自动均衡以节点为主要维度

旧材料把节点间均衡和同一 BE 内盘间均衡都写成自动能力。当前官方 FAQ 说明，Doris 的常规 Balance 以节点整体负载为主要判断维度，给所有节点同时增加磁盘不会自动触发数据迁移，同一节点内部也没有通用的自动盘间均衡。新增数据会优先使用可用空间，已有数据需要通过重建表、Decommission 迁移或受控 API 调整。[1]

这项边界会直接影响扩盘方案。生产评审需要先明确目标是扩大单机容量、降低节点水位，还是增加集群总吞吐；只给每台 BE 增加一块盘，无法保证历史 Tablet 自动均匀铺到新盘。

截至 2026 年 8 月 17 日，官方下载页将 4.1.3 标记为 Latest、4.0.8 标记为 Stable。文中的默认值、限制和命令以当前 4.x 文档为准，上线前仍需在目标 Patch 版本重新核验。[6]

一、高可用需要四层防线

“高可用”经常被简化成三副本，三副本只能覆盖其中一部分。生产平台可以把保护能力分成四层：

层级	主要能力	典型故障	恢复特点
L1 进程与入口	Systemd、Supervisor、LB、客户端重试	进程退出、单 FE 入口故障	秒到分钟
L2 集群高可用	FE Quorum、BE Replica、自动修复	节点宕机、单盘故障	在线自愈为主
L3 数据可恢复	Recycle Bin、Backup / Restore	误删、逻辑污染、历史回退	依赖恢复点
L4 站点级容灾	远端 Repository、备用集群、跨集群复制	机房故障、整集群不可用	需要切换与回切流程

这四层保护的是不同对象：

L1 保护服务进程和连接入口；
L2 保护当前可用的数据与元数据；
L3 保存过去某个时刻的可恢复状态；
L4 处理源集群整体无法继续服务的情况。

一张表拥有三副本时，误写的错误数据会同时进入三份副本。副本能够抵抗介质损坏，无法提供历史回退点。备份保存了历史恢复点，备份文件仍可能因为凭证过期、远端存储权限变化或长期未验证而失去可恢复性。可用性设计需要把两类能力组合起来。

1.1 用故障域表达拓扑

生产拓扑要明确节点分布在哪些故障域：主机、机架、交换机、可用区、机房。一个 Tablet 的多个 Replica 应分散到不同 BE 主机；FE Follower 也应尽量分散部署。多个进程放在同一物理机上，只能形成进程级冗余，主机故障会同时带走多个“节点”。

节点 Tag 和 replication_allocation 可以约束副本放置。使用 Tag 前需要确认：

每个目标 Tag 中有足够的 BE 主机；
Quorum 写入在任一计划故障场景下仍能满足；
缩容、扩容和磁盘故障不会让某个 Tag 无法补副本；
Resource Group 的物理隔离没有破坏副本容错目标。

二、FE 高可用：角色、Quorum 与入口

2.1 元数据写入为什么需要多数派

FE 管理数据库、表、分区、Tablet、用户、权限、任务和节点等元数据。Master 接收元数据变更后，需要把日志同步到 Follower 组，多数派确认后才能完成提交。3 个 Follower 的多数派为 2，5 个 Follower 的多数派为 3。

这个机制带来两个直接结论：

Follower 总数保持奇数通常更合理；
失去多数派后，元数据写入无法继续，查询可用性也会受到具体元数据和连接路径影响。

Observer 不参与多数派。增加 Observer 可以分担连接和读取压力，无法修复 Follower 不足的问题。

2.2 Master 故障后的恢复链路

Master 进程或主机故障后，剩余 Follower 发现连接中断并发起选举，获得多数票的 Follower 成为新的 Master。业务入口需要通过域名、VIP 或负载均衡器重新连接可用 FE。客户端连接池和任务重试决定了业务感知的中断时间。

需要演练以下细节：

关闭当前 Master 后，新 Master 的产生时间；
MySQL、JDBC、Stream Load 和 Web UI 的重连行为；
负载均衡器是否把流量继续发送到故障节点；
正在执行的查询和导入怎样失败、重试或恢复；
旧 Master 恢复后是否以 Follower 身份追上日志。

2.3 入口负载均衡的注意点

业务代码不应长期写死某个 FE IP。MySQL 协议入口可以使用 VIP、LVS、HAProxy、Nginx Stream 或具备健康检查的连接层。Web UI 存在 Session 粘性需求，使用 Nginx 时应配置稳定的会话路由。

负载均衡健康检查需要区分“端口可连接”和“节点可正常提供服务”。推荐同时检查：

进程端口；
FE Alive 状态；
Master / Follower / Observer 角色；
查询端口是否可以完成轻量 SQL；
元数据写路径是否拥有 Quorum。

2.4 自动拉起与元数据目录保护

FE 选举依赖进程能够被及时拉起，也依赖本地 meta_dir 完整可读。生产节点应使用 Systemd、Supervisor 或 Kubernetes 控制器管理 FE 进程，并设置启动限速，避免配置错误导致无限快速重启。元数据目录建议使用独立 SSD，纳入磁盘水位、I/O 延迟和文件系统错误监控。

自动拉起策略需要区分三类退出：

正常维护退出：按变更窗口人工启动；
瞬时异常退出：控制器自动重启并告警；
连续 Crash：达到次数门限后停止自动重启，保留日志、堆栈和元数据现场。

最后一类场景持续重启可能覆盖关键日志、扩大 BDB JE 恢复压力。Runbook 应明确 fe.log、fe.out、JVM Dump、元数据目录和进程启动参数的采集顺序。

三、BE 多副本：健康检查、修复与均衡

每个 Tablet 通常拥有多个 Replica，默认经验值是 3。健康副本需要同时满足：所在 BE 存活、版本完整、状态正常。TabletChecker 定期扫描全体 Tablet，TabletScheduler 处理异常与均衡任务。[2]

3.1 常见异常状态

状态	含义	常见原因
REPLICA_MISSING	实际副本数低于期望值	BE 宕机、节点下线、调度未完成
VERSION_INCOMPLETE	副本缺少某些版本	写入失败、网络问题、长时间离线
BAD / CORRUPT	副本损坏或被标记异常	磁盘、文件、校验问题
REPLICA_RELOCATING	副本需要迁移	Decommission、磁盘水位、Tag 变化
COLOCATE_MISMATCH	副本分布与 Colocate Group 不一致	扩缩容、节点变化、修复未完成

3.2 修复任务从哪里复制数据

调度器会从完整的健康副本中选择源，结合目标 BE 的磁盘水位、负载、Tag、介质和主机分布创建 Clone 任务。任务完成后，新副本汇报版本，FE 更新元数据，冗余或异常副本再被清理。

运维人员应避免在自动修复进行时连续执行大量 DROP、ADD、Tag 变更和缩容操作。过多拓扑变化会扩大调度搜索空间，也会争抢网络与磁盘 I/O。

3.3 基础检查命令

SHOW FRONTENDS;
SHOW BACKENDS;
SHOW REPLICA STATUS FROM db_name.table_name;
SHOW PROC '/cluster_health/tablet_health';
SHOW PROC '/cluster_balance';

指定表需要优先修复时，可以使用：

ADMIN REPAIR TABLE db_name.table_name;

命令提交后仍需持续观察副本状态和调度队列。ADMIN REPAIR 提高修复优先级，没有替代健康源副本、目标容量和网络条件。

3.4 副本数与写入可用性的关系

副本数会同时改变容错能力、写入成本和修复时长。三副本能够容忍单副本故障，并在多数副本可用时继续完成写入；两副本的多数派仍然要求两份都成功，单节点故障会明显影响写入可用性；单副本没有数据冗余。

调整副本数前应评估：

当前 BE 主机数量能否把副本分散到不同主机；
跨可用区副本是否带来更高写入网络延迟；
大表增加副本会产生多少 Clone 流量和临时磁盘水位；
降低副本数后，备份频率和源端重放能力是否需要增强；
恢复过程中是否可以先用 1 副本快速恢复，再补齐生产副本。

副本策略应按数据等级制定。核心事实表、可重建汇总表、临时中间表可以采用不同保护等级，前提是恢复责任和重建步骤已经写入运维手册。

四、从故障现象选择恢复路径

4.1 单个 BE 宕机

三副本表通常可以继续从其余副本读取。先确认业务错误率、健康副本数和 Quorum 写入，再检查 be.out、系统 OOM、磁盘与网络。节点能够安全恢复时优先恢复原节点；节点长期不可用时让调度器补齐副本，随后决定 Decommission 或 DROP。

4.2 单个 Master FE 宕机

剩余 Follower 拥有多数派时会重新选主。核心检查项包括：

SHOW FRONTENDS 中新的 IsMaster；
Follower 日志是否追平；
Load Balancer 是否摘除故障端点；
元数据写操作是否恢复；
失败任务的重试与幂等是否正常。

4.3 单磁盘故障

Doris 会把磁盘上的 Replica 视为异常或不可达。主机仍然在线时，需要结合 BE 日志、磁盘挂载和 SHOW BACKENDS 判断是否下线路径或整台 BE。更换磁盘后，确认目录权限、容量、介质标记与 storage_root_path，再观察副本重建。

4.4 误删对象

先查询回收站。对象仍在保留期时，RECOVER 通常是最快路径。对象被 DROP FORCE 删除、已被清理，或同名对象冲突时，进入快照恢复流程。

4.5 逻辑污染

错误 SQL、错误同步任务和错误业务规则可能写入大量合法格式的数据，三副本会完整保存这些错误结果。稳妥做法是：

停止错误写入源；
记录受影响的时间、分区和版本；
从快照恢复到新表或隔离库；
对比行数、关键聚合和黄金样本；
通过 Rename、View 或应用配置切换；
保留旧表和回退窗口。

4.6 整集群或机房不可用

需要依赖远端 Repository、备用集群和业务入口切换。恢复范围还包括用户权限、Catalog、Workload Group、外部连接凭证、同步任务、调度任务和监控告警。只恢复业务表无法自动恢复整个数据平台的运行状态。

五、在线扩容：先扩能力，再等待数据稳定

5.1 FE 扩容

扩展元数据读取与查询入口时添加 Observer：

fe/bin/start_fe.sh --helper <leader_fe_host>:<edit_log_port> --daemon

ALTER SYSTEM ADD OBSERVER '<observer_host>:<edit_log_port>';
SHOW FRONTENDS;

增加元数据写高可用票数时添加 Follower，并保持 Master + Follower 总数为奇数：

ALTER SYSTEM ADD FOLLOWER '<follower_host>:<edit_log_port>';

新增 FE 的 http_port 需要与现有 FE 一致。节点加入后，要等待元数据日志追平，再把它加入业务负载均衡。[7]

5.2 BE 扩容

be/bin/start_be.sh --daemon

ALTER SYSTEM ADD BACKEND '<be_host>:<heartbeat_service_port>';
SHOW BACKENDS;

新 BE 注册后，Doris 会逐步把现有数据均衡到新节点。扩容窗口需要观察：

Balance 任务数量与失败原因；
新旧节点磁盘水位；
网络吞吐和 Compaction I/O；
热数据缓存命中率；
查询 p95/p99 与写入延迟；
Colocate Group 是否恢复稳定。

一次性加入过多 BE 会产生较大的迁移并发和缓存冷启动。常见做法是分批扩容，每批完成健康验收后继续下一批。

5.3 扩容完成的验收标准

扩容命令执行成功只说明节点注册成功。完整验收至少包括：

所有节点 Alive=true；
Tablet 分布和磁盘水位进入预期区间；
无持续增长的 Missing / Incomplete Replica；
Balance 队列回落；
关键 SQL 冷缓存与热缓存性能达标；
峰值写入与复杂查询混合运行稳定；
监控、日志采集和自动拉起已经覆盖新节点。

六、安全缩容：DECOMMISSION 优先

BE 缩容有两条路径：

ALTER SYSTEM DECOMMISSION BACKEND '<be_host>:<heartbeat_port>';

ALTER SYSTEM DROP BACKEND '<be_host>:<heartbeat_port>';

官方明确推荐生产环境使用 DECOMMISSION。该操作先迁移数据，迁移完成后再移除节点；DROP 立即移除节点，单副本或副本不足时可能造成数据损失。[7]

6.1 缩容前置条件

剩余 BE 有足够磁盘接收待迁移副本；
目标 Tag 和介质中有足够主机；
集群没有大量副本异常；
网络和磁盘能够承受迁移流量；
Colocate Group 可以在剩余节点上满足分布要求；
核心业务在 N-1 或 N-2 条件下仍有足够计算能力。

6.2 Decommission 长时间不结束

观察 SHOW BACKENDS 中目标节点的 TabletNum 是否持续下降。长期停在某个数量时，常见原因包括：

Tablet 属于刚删除、仍在回收站中的对象；
迁移任务失败；
目标节点容量、Tag 或介质不足；
Colocate 约束阻止迁移；
副本健康状态不满足安全迁移条件。

可以使用：

SHOW PROC '/cluster_health/tablet_health';
SHOW PROC '/cluster_balance';

在确认所有 Tablet 安全、目标节点无法恢复且业务接受风险时，才进入紧急 DROP 路径。