生产运维与灾备——容量、扩缩容、备份、升级和事故处理 | Doris 实战与架构

预计阅读时间: 60 分钟 前置阅读: doc-11, doc-12, doc-14, doc-16 下一次阅读: doc-24(权限治理与多租户)

1. 运维专家关注什么

Doris 上生产后, 你要从"会用"转成"能保证服务稳定":

容量什么时候会打满。
Tablet 和副本是否健康。
FE 选主是否稳定。
BE 下线、扩容、磁盘坏了怎么处理。
慢查询和大查询如何隔离。
备份是否真的可恢复。
升级是否能回滚。

专家的基本原则:

先保护元数据
  → 再保护副本和数据文件
    → 再保护查询 SLA
      → 最后追求资源利用率

参考:

2. 容量规划

容量不是只算原始数据量:

原始数据
  × 压缩比
  × 副本数
  + 索引
  + Compaction 临时空间
  + 导入临时空间
  + 备份/恢复缓冲

估算模板:

项	示例
日增原始数据	2 TB
压缩后比例	30%
副本数	3
索引开销	20%
保留周期	30 天
安全水位	磁盘使用不超过 70%

2TB * 0.3 * 3 * 1.2 * 30 / 0.7 ≈ 92.6TB 可用磁盘

还要评估:

FE 元数据内存是否能承受 Tablet 数。
BE CPU 是否匹配并发和 Scan。
网络是否能承受 Shuffle 和副本修复。
SSD/HDD 是否匹配延迟要求。

3. Tablet 数治理

Tablet 太多会拖垮 FE 调度和 BE 管理; Tablet 太少会影响并行度。

检查:

SHOW PROC '/statistic';
SHOW TABLETS FROM table_name;
SHOW PARTITIONS FROM table_name;

关注:

单表 Tablet 总数。
单 BE Tablet 数。
小 Tablet 比例。
Version Count。
副本分布是否均匀。

治理:

合理控制分区粒度。
Bucket 数不要过大。
冷历史表降低副本或归档。
高频小批导入合并。
大表拆分时考虑查询路径, 不要盲目拆。

4. 扩容与缩容

BE 扩容

扩容后不会立刻让历史数据均匀。你需要关注:

新 BE 心跳是否正常。
Tablet 调度和迁移是否开始。
新旧 BE 磁盘使用是否逐步趋近。
查询是否因为迁移产生抖动。

常见流程:

准备机器和磁盘
  → 安装 BE
    → 添加到集群
      → 观察心跳
        → 等待均衡
          → 验证查询和导入

BE 下线

下线要先 Decommission, 让副本迁移完成, 不要直接杀机器。

Decommission BE
  → Tablet 迁移
    → 副本数恢复
      → 确认无不健康 Tablet
        → 停止 BE

5. FE 高可用

FE 角色:

Master: 元数据写入和协调。
Follower: 参与选举, 复制 Journal。
Observer: 只读扩展, 不参与选举。

生产建议:

至少 3 个 Follower 形成多数派。
Observer 用于读扩展, 不替代 Follower 多数派。
FE 节点磁盘和时钟要稳定。
定期备份元数据。

事故判断:

现象	可能原因
无法执行 DDL	Master 不可用或选主异常
查询可以, DDL 不行	Observer 可读但 Master 写不可用
FE 启动慢	Journal 或 Image 恢复耗时
元数据不一致	Journal 复制或版本问题

6. 备份与恢复

备份不是"已经执行 BACKUP", 而是"验证过 RESTORE"。

备份策略:

核心库表: 每日备份 + 重要变更前备份
元数据: FE image/journal 保护
冷数据: 对象存储生命周期
配置: fe.conf / be.conf / 用户权限 / Workload Group

演练:

在隔离环境恢复。
校验表结构。
校验行数和核心指标。
跑核心查询。
记录恢复耗时 RTO。
记录可接受数据丢失 RPO。

如果从未恢复过, 就不能算有备份。

7. 升级与回滚

升级前:

1. 阅读目标版本 release note
2. 检查不兼容变更
3. 备份元数据和核心表
4. 在测试集群跑核心 SQL
5. 验证导入、查询、权限、物化视图
6. 准备回滚窗口

升级中:

先非核心节点。
控制同时重启数量。
观察 FE 选主和 BE 心跳。
观察查询错误率和导入延迟。

升级后:

对比 P95/P99 查询。
检查 Profile 是否出现计划变化。
检查 Routine Load、MV 刷新和 Compaction。
保留旧版本包和配置直到观察期结束。

8. 查询保护

生产集群必须防止单个 SQL 拖垮所有人。

能力:

Workload Group: CPU、内存、并发隔离。
Spill: 大查询内存不足时落盘。
SQL Block Rule: 规划期拦截危险 SQL。
Workload Policy: 运行时熔断超限查询。
Kill Query: 手工止血。

示例策略:

用户	策略
BI 看板	高优先级, 并发受控
Adhoc 分析	中低优先级, 内存限制
ETL/MV 刷新	独立资源组, 夜间窗口
新用户/测试	严格超时和扫描量限制

9. 事故处理手册

查询大面积变慢

1. 看是否有大查询占资源
2. 看 Workload Group 队列
3. 看 BE CPU/IO/内存
4. 看是否有 Compaction 或 Clone 高峰
5. 看是否冷缓存或外部存储异常
6. Kill 明确异常查询
7. 降级非核心任务

导入延迟上升

1. 看 Routine Load / Load Job 状态
2. 看 Kafka lag 或源端延迟
3. 看 BE 写入错误
4. 看版本堆积和 Compaction
5. 看磁盘空间
6. 调整批量或暂停低优先级导入

Tablet 不健康

1. 定位表、分区、Tablet
2. 看副本缺失还是版本落后
3. 看 Clone/Repair 任务
4. 看源 BE 和目标 BE 状态
5. 防止继续下线更多节点

一句话总结:

Doris 运维专家的标准不是"知道每个命令", 而是能在容量、健康、资源、备份和事故之间建立可演练的稳定性体系。