TiDB 自动故障恢复

故障检测机制

1. PD 心跳检测

PD 通过定期心跳检测来监控集群中所有组件的状态：

TiDB 心跳：TiDB 服务器定期向 PD 发送心跳，汇报自身状态
TiKV 心跳：TiKV 服务器定期向 PD 发送心跳，汇报自身状态和 Region 分布
PD 内部心跳：PD 集群内部通过 Raft 协议保持通信和状态同步

2. 心跳超时机制

当 PD 超过一定时间未收到某个节点的心跳时，会将该节点标记为异常：

组件	心跳间隔	超时时间
TiDB	10s	30s
TiKV	10s	30s
PD	1s	3s

3. Raft 故障检测

TiKV 内部通过 Raft 协议实现故障检测：

当 Leader 超过选举超时时间未收到 Follower 的心跳，会认为该 Follower 故障
当 Follower 超过选举超时时间未收到 Leader 的心跳，会发起新的 Leader 选举
Raft 组会自动处理成员故障和 Leader 切换

自动故障恢复流程

1. TiKV 节点故障恢复

当 TiKV 节点故障时，自动恢复流程如下：

故障检测：PD 检测到 TiKV 节点心跳超时，将其标记为 Down 状态
Region 状态更新：PD 更新受影响 Region 的状态，将故障节点上的副本标记为 Unavailable
调度决策：PD 调度器触发，生成以下调度任务：
- ReplicaChecker：检查 Region 副本数量，确保满足副本数要求
- HighSpaceRatio：平衡集群存储空间
- HighStoreReadRatio：平衡集群读取负载
副本修复：PD 选择合适的 TiKV 节点，为受影响的 Region 创建新的副本
数据同步：通过 Raft 协议将数据同步到新副本
副本验证：新副本同步完成后，PD 更新 Region 元数据
节点恢复：如果故障节点恢复，PD 会将其重新加入集群，并平衡其负载

2. PD 节点故障恢复

当 PD 节点故障时，自动恢复流程如下：

Leader 选举：PD 集群通过 Raft 协议自动选举新的 Leader
成员更新：新 Leader 更新 PD 成员列表，将故障节点标记为 Tombstone
服务恢复：新 Leader 接管所有调度和管理职能，集群继续正常运行
节点恢复：如果故障节点恢复，需要手动将其重新加入集群

3. TiDB 节点故障恢复

TiDB 是无状态组件，其故障恢复非常简单：

故障检测：PD 检测到 TiDB 节点心跳超时，将其标记为 Down 状态
连接重定向：客户端连接自动重定向到其他可用的 TiDB 节点
负载均衡：新的连接请求会被分发到其他健康的 TiDB 节点
节点恢复：如果故障节点恢复，会自动重新加入集群，参与请求处理

调度器与恢复策略

1. 核心调度器

PD 包含多个调度器，负责不同场景下的自动恢复：

ReplicaChecker：确保每个 Region 有足够的副本数
HighSpaceRatio：处理磁盘空间不足的情况
HighStoreReadRatio：处理读取负载过高的情况
HighStoreWriteRatio：处理写入负载过高的情况
HotRegion：处理热点 Region 问题
LabelScheduler：根据标签约束进行调度

2. 恢复策略配置

可以通过 PD 配置调整自动恢复策略：

toml

# PD 配置文件
[scheduler]
# 启用或禁用特定调度器
enable-cross-table-merge = true
enable-location-replacement = true

# 调整调度速度
max-snapshot-count = 3 # 每个 TiKV 节点同时进行的快照发送数量
max-pending-peer-count = 16 # 每个 TiKV 节点同时处理的 pending peer 数量

# 调整心跳超时时间
[pd-server]
heartbeat-interval = "10s" # 心跳间隔
leader-lease = "3s" # Leader 租约时间

3. 优先级调度

PD 调度器会根据任务优先级进行处理：

副本修复：最高优先级，确保数据可用性
负载均衡：中等优先级，优化集群性能
数据分布优化：低优先级，改善长期性能

监控与调优

1. 关键监控指标

监控自动故障恢复过程中的关键指标：

PD 指标：
- pd_scheduler_operator_create_total：创建的调度操作总数
- pd_scheduler_operator_finish_total：完成的调度操作总数
- pd_tikv_store_down_total：TiKV 节点宕机次数
TiKV 指标：
- tikv_raftstore_leader_count：Leader 数量
- tikv_raftstore_region_count：Region 数量
- tikv_snapshot_sent_count：发送的快照数量
TiDB 指标：
- tidb_server_uptime：TiDB 服务器运行时间
- tidb_connection_count：当前连接数

2. 性能调优

根据实际情况调整自动恢复性能：

调整调度速度：根据集群规模和网络带宽，调整 max-snapshot-count 和 max-pending-peer-count
优化 Raft 配置：调整 TiKV 的 Raft 相关参数，如 raft-store.raft-base-tick-interval
调整心跳超时：根据网络环境，调整心跳间隔和超时时间

3. 常见性能问题

调度速度过慢：导致故障恢复时间过长
- 解决方案：增加 max-snapshot-count 和 max-pending-peer-count
网络带宽瓶颈：快照传输占用大量带宽，影响正常业务
- 解决方案：限制单个节点的快照数量，或使用更高带宽的网络
磁盘 I/O 瓶颈：快照创建和应用占用大量磁盘 I/O
- 解决方案：使用高性能磁盘，或调整快照创建策略

手动干预与自动恢复的结合

虽然 TiDB 具备强大的自动恢复能力，但在某些情况下仍需要手动干预：

1. 何时需要手动干预

大规模故障导致自动恢复无法正常工作
网络分区导致脑裂
数据损坏需要从备份恢复
集群配置错误需要手动调整

2. 手动干预步骤

暂停自动调度：

bash

tiup ctl pd --host pd-host:2379 config set scheduler.max-pending-peer-count 0

手动修复故障：
- 修复硬件故障
- 恢复网络连接
- 从备份恢复数据

恢复自动调度：

bash

tiup ctl pd --host pd-host:2379 config set scheduler.max-pending-peer-count 16

3. 监控手动干预效果

检查集群状态：tiup cluster display cluster-name
检查调度状态：tiup ctl pd --host pd-host:2379 operator show
检查 Region 状态：tiup ctl pd --host pd-host:2379 store

自动故障恢复最佳实践

1. 集群部署最佳实践

部署足够数量的节点：
- PD 节点：至少 3 个，推荐奇数个
- TiKV 节点：至少 3 个，推荐 5 个或更多
- TiDB 节点：至少 2 个，根据业务需求扩容
跨可用区部署：
- 将节点分布在不同的可用区或机架
- 配置合理的位置标签（location labels）
- 确保副本分布在不同的物理位置
硬件配置：
- 使用高性能磁盘（SSD/NVMe）
- 配置足够的内存和 CPU
- 确保良好的网络连接

2. 配置优化

调整心跳参数：

toml

[pd-server]
heartbeat-interval = "10s"
leader-lease = "3s"

调整调度参数：

toml

[scheduler]
max-snapshot-count = 3
max-pending-peer-count = 16

配置位置标签：

toml

[replication]
location-labels = ["zone", "rack", "host"]

3. 监控与告警

建立完善的监控体系：
- 监控 PD 调度状态
- 监控 TiKV Raft 状态
- 监控 TiDB 连接状态
设置合理的告警阈值：
- 节点状态异常告警
- 心跳超时告警
- Region 副本数量不足告警
- 调度操作积压告警

4. 故障演练

定期进行故障演练：
- 模拟节点宕机
- 模拟网络分区
- 模拟磁盘故障
评估恢复效果：
- 记录故障恢复时间
- 验证数据一致性
- 评估业务影响
优化恢复流程：
- 根据演练结果调整配置
- 完善故障处理流程
- 提高团队应急响应能力

自动故障恢复案例分析

案例 1：TiKV 节点故障自动恢复

故障场景

集群包含 5 个 TiKV 节点
其中 1 个 TiKV 节点因硬件故障宕机
该节点上存储了约 2000 个 Region 的副本

恢复过程

PD 在 30s 后检测到节点心跳超时，将其标记为 Down 状态
PD 调度器生成 2000 个副本修复任务
TiKV 节点开始创建和同步快照
约 15 分钟后，所有 Region 副本数量恢复正常
集群恢复到完全可用状态

业务影响

故障期间，受影响的 Region 仍可通过其他副本提供服务
业务请求延迟略有增加，但无请求失败
故障恢复过程对业务完全透明

案例 2：PD 节点故障自动恢复

故障场景

PD 集群包含 3 个节点
其中 1 个 PD 节点因网络故障与其他节点隔离
该节点是当前的 PD Leader

恢复过程

其他 PD 节点在 3s 后检测到 Leader 心跳超时
PD 集群自动选举新的 Leader
新 Leader 接管所有调度职能
集群继续正常运行，无明显中断

业务影响

故障恢复过程仅持续约 5s
期间集群调度暂时暂停
业务请求无明显影响

常见问题（FAQ）

Q1: TiDB 自动故障恢复的 RTO（恢复时间目标）是多少？

A1: TiDB 自动故障恢复的 RTO 取决于多种因素：

故障类型：TiDB 节点故障恢复最快，PD 节点次之，TiKV 节点恢复时间较长
集群规模：集群越大，恢复时间可能越长
网络带宽：影响快照传输速度
配置参数：调度速度等参数会影响恢复时间

一般情况下：

TiDB 节点故障：秒级恢复
PD 节点故障：秒级恢复
TiKV 节点故障：分钟级恢复（取决于 Region 数量和数据量）

Q2: TiDB 自动故障恢复的 RPO（恢复点目标）是多少？

A2: TiDB 基于 Raft 共识算法，默认配置 3 副本。在故障发生时，只有已提交的数据才会被持久化到多数副本，因此 RPO 为 0，即不会丢失已提交的数据。

Q3: 如何调整 TiDB 自动故障恢复的速度？

A3: 可以通过调整 PD 配置来控制自动恢复速度：

max-snapshot-count：控制每个 TiKV 节点同时发送的快照数量
max-pending-peer-count：控制每个 TiKV 节点同时处理的 pending peer 数量
增加这些参数的值可以加快恢复速度，但会增加网络和磁盘负载

Q4: 自动故障恢复过程中会影响业务性能吗？

A4: 自动故障恢复过程中可能会对业务性能产生一定影响：

快照传输会占用网络带宽
数据同步会增加磁盘 I/O 负载
调度操作会消耗 CPU 资源

可以通过调整调度参数来平衡恢复速度和业务性能影响。

Q5: 如何禁用 TiDB 的自动故障恢复？

A5: 不建议完全禁用自动故障恢复，但可以根据需要调整调度策略：

暂停特定调度器：tiup ctl pd --host pd-host:2379 scheduler pause scheduler-name
调整调度参数：降低 max-snapshot-count 和 max-pending-peer-count
禁用所有调度器：tiup ctl pd --host pd-host:2379 scheduler pause all

Q6: TiDB 如何处理网络分区？

A6: TiDB 处理网络分区的方式：

PD 集群通过 Raft 协议处理网络分区，确保只有一个有效的 Leader
TiKV 集群通过 Raft 协议维护数据一致性，在网络分区情况下，只有多数派的分区可以继续提供服务
当网络分区恢复后，PD 会自动调度，恢复集群的正常状态

Q7: 如何验证 TiDB 自动故障恢复是否正常工作？

A7: 可以通过以下方式验证：

检查 PD 调度日志，确认调度操作正常执行
监控 Region 副本数量，确保始终满足要求
进行故障演练，验证自动恢复效果
检查集群状态，确保所有节点正常运行

Q8: TiDB 自动故障恢复与手动故障恢复的区别是什么？

A8: 自动故障恢复与手动故障恢复的主要区别：

特性	自动故障恢复	手动故障恢复
恢复速度	快（秒级/分钟级）	慢（取决于人工响应时间）
业务影响	最小	可能较大
人为错误风险	低	高
适用场景	常见故障（节点宕机、网络故障等）	复杂故障（数据损坏、配置错误等）
运维成本	低	高

TiDB 自动故障恢复 ​

故障检测机制 ​

1. PD 心跳检测 ​

2. 心跳超时机制 ​

3. Raft 故障检测 ​

自动故障恢复流程 ​

1. TiKV 节点故障恢复 ​

2. PD 节点故障恢复 ​

3. TiDB 节点故障恢复 ​

调度器与恢复策略 ​

1. 核心调度器 ​

2. 恢复策略配置 ​

3. 优先级调度 ​

监控与调优 ​

1. 关键监控指标 ​

2. 性能调优 ​

3. 常见性能问题 ​

手动干预与自动恢复的结合 ​

1. 何时需要手动干预 ​

2. 手动干预步骤 ​

3. 监控手动干预效果 ​

自动故障恢复最佳实践 ​

1. 集群部署最佳实践 ​

2. 配置优化 ​

3. 监控与告警 ​

4. 故障演练 ​

自动故障恢复案例分析 ​

案例 1：TiKV 节点故障自动恢复 ​

故障场景 ​

恢复过程 ​

业务影响 ​

案例 2：PD 节点故障自动恢复 ​

故障场景 ​

恢复过程 ​

业务影响 ​

常见问题（FAQ） ​

Q1: TiDB 自动故障恢复的 RTO（恢复时间目标）是多少？ ​

Q2: TiDB 自动故障恢复的 RPO（恢复点目标）是多少？ ​

Q3: 如何调整 TiDB 自动故障恢复的速度？ ​

Q4: 自动故障恢复过程中会影响业务性能吗？ ​

Q5: 如何禁用 TiDB 的自动故障恢复？ ​

Q6: TiDB 如何处理网络分区？ ​

Q7: 如何验证 TiDB 自动故障恢复是否正常工作？ ​

Q8: TiDB 自动故障恢复与手动故障恢复的区别是什么？ ​

TiDB 自动故障恢复

故障检测机制

1. PD 心跳检测

2. 心跳超时机制

3. Raft 故障检测

自动故障恢复流程

1. TiKV 节点故障恢复

2. PD 节点故障恢复

3. TiDB 节点故障恢复

调度器与恢复策略

1. 核心调度器

2. 恢复策略配置

3. 优先级调度

监控与调优

1. 关键监控指标

2. 性能调优

3. 常见性能问题

手动干预与自动恢复的结合

1. 何时需要手动干预

2. 手动干预步骤

3. 监控手动干预效果

自动故障恢复最佳实践

1. 集群部署最佳实践

2. 配置优化

3. 监控与告警

4. 故障演练

自动故障恢复案例分析

案例 1：TiKV 节点故障自动恢复

故障场景

恢复过程

业务影响

案例 2：PD 节点故障自动恢复

故障场景

恢复过程

业务影响

常见问题（FAQ）

Q1: TiDB 自动故障恢复的 RTO（恢复时间目标）是多少？

Q2: TiDB 自动故障恢复的 RPO（恢复点目标）是多少？

Q3: 如何调整 TiDB 自动故障恢复的速度？

Q4: 自动故障恢复过程中会影响业务性能吗？

Q5: 如何禁用 TiDB 的自动故障恢复？

Q6: TiDB 如何处理网络分区？

Q7: 如何验证 TiDB 自动故障恢复是否正常工作？

Q8: TiDB 自动故障恢复与手动故障恢复的区别是什么？