TiDB 分布式数据库生产运维、备份恢复与故障排查
TiDB 提供兼容 MySQL 协议的分布式 SQL 能力，由无状态 TiDB Server、调度与时间戳服务 PD、分布式存储 TiKV 等组件组成。它通过 Raft 提供副本，但生产稳定性还依赖 Region 调度、热点、GC、备份、PITR、容量与 SQL 治理。本文建立完整运维路线。
Raft 副本解决部分节点故障，不保护误删除、逻辑损坏和全站灾难。生产必须保留独立备份、日志备份和真实恢复演练。
一、核心架构
应用 / MySQL Driver
↓
TiDB Server（SQL 解析、优化、执行）
↓
PD（元数据、TSO、调度）
↓
TiKV（Region、Raft、副本、MVCC）
TiDB Server 无状态，可水平扩展；PD 需要多数派；TiKV 保存数据。TiFlash 可提供列式分析副本，但会增加存储与复制成本。
二、规划 RPO/RTO
上线前明确：
- 峰值 QPS/TPS、连接与事务大小；
- 数据量、增长、热点和保留；
- OLTP 与 HTAP 比例；
- 可容忍节点、机架或机房故障；
- 备份窗口、PITR 与恢复时间；
- MySQL 兼容差异；
- 跨地域延迟与一致性目标。
三、生产拓扑
PD 和 TiKV 应跨故障域部署，Label 正确反映机房、机架和主机。调度器依赖 Label 分散副本。
风险：
- 多个副本落在同一宿主机；
- PD 全在同一故障域；
- 备份存储与集群共用单一阵列；
- TiDB Server 无负载均衡健康检查；
- 时钟、DNS 或网络不稳定。
四、TiUP 生命周期管理
TiUP 可部署、扩缩容、升级和修改配置。
tiup cluster list
tiup cluster display prod
tiup cluster check topology.yaml --apply
tiup cluster audit
生产变更前保存拓扑和配置，检查 SSH、端口、目录、时间同步和资源。不要手工修改部分节点后再让 TiUP 接管，避免配置漂移。
五、PD 与 TSO
PD 保存集群元数据、分配时间戳并调度 Region。多数派丢失会影响集群服务。
监控：Leader 变化、请求延迟、TSO、etcd 大小、调度 Operator、Region 健康和存储容量。不要同时重启多数 PD 节点。
六、Region 与 Raft
TiKV 将 Key Space 划分为 Region，每个 Region 有 Leader 和多个 Peer。写入由 Leader 复制到多数派。
观察：
- Region 数量和分布；
- Leader 分布；
- Pending/Down Peer；
- Empty Region；
- Split/Merge；
- 调度速度与 Operator 积压。
大量小表、热点 Key 或突发写入可能造成 Region 和 Leader 不均衡。
七、热点排查
热点可能是单调递增主键、集中租户、索引前缀、时间序列或单行频繁更新。
使用 TiDB Dashboard/PD 查看 Hot Read/Write Region，结合 SQL 与 Key 范围定位。优化方式：随机/散列前缀、分区、批量、业务拆分、合理主键和写入分散。
不要仅扩容 TiKV；热点集中在少量 Region 时，新节点未必分担流量。
八、SQL 性能
EXPLAIN ANALYZE SELECT ...;
SHOW SLOW;
SELECT * FROM information_schema.cluster_slow_query
ORDER BY Query_time DESC LIMIT 20;
关注执行计划、估算偏差、扫描行数、Cop Task、网络、内存、落盘、事务冲突和 Region 请求。统计信息陈旧会导致错误计划。
九、统计信息
分析表和索引统计，设置合理自动分析窗口。大表全量 Analyze 可能消耗大量资源，可使用增量或分区策略（按版本能力）。
观察 Healthy、Pseudo、Last Analyze 和计划变化。重大数据分布改变后应验证统计，而不是盲目绑定计划。
十、事务与锁
TiDB 支持乐观/悲观事务等机制。长事务会增加锁、GC 和冲突风险。
排查：
- Lock Wait；
- Deadlock；
- 大事务与提交重试；
- 单行热点；
- 客户端超时后事务仍执行；
- Autocommit 与连接池。
应用需要幂等和合理事务边界，避免一次修改海量行。
十一、GC 与历史版本
MVCC 历史版本由 GC 清理。长事务、备份和 CDC 可能要求保留旧版本。GC Safe Point 停滞会让存储持续增长。
监控 GC 进度、Safe Point、长事务和备份任务。不要随意修改 GC Lifetime 作为永久方案。
十二、TiKV 存储与磁盘
TiKV 对延迟和吞吐敏感。应使用稳定 SSD/NVMe，数据与日志规划按官方建议，并监控：
- 磁盘空间和写放大；
- RocksDB/RAFT DB；
- Compaction；
- Block Cache；
- I/O 延迟与 Stall；
- Snapshot 发送与接收。
磁盘逼近满会影响 Compaction、快照和恢复，需提前扩容。
十三、扩容与缩容
扩容后需要时间搬迁 Region。业务高峰快速加节点不会立即消除热点。
缩容必须使用 TiUP/PD 正确 Evict 和 Tombstone 流程，等待数据迁出。直接关机并删除目录会造成 Down Peer 和恢复压力。
十四、升级
- 核对版本路径、兼容和弃用；
- 备份与恢复验证；
- 检查集群健康和容量；
- 在预生产升级；
- 按官方顺序滚动；
- 观察 PD、TiKV、TiDB、SQL 和业务；
- 验证工具链与客户端。
版本升级可能包含不可逆元数据变化，应明确回滚边界。
十五、全量备份
BR 可执行快照备份到 S3 兼容、云对象存储或 NFS。备份会消耗 TiKV、网络和目标存储资源。
tiup br backup full \
--pd "pd1:2379" \
--storage "s3://tidb-backup/prod/full-20261104"
凭证应通过安全身份提供，示例需按环境调整。备份前确认目标容量、带宽、权限和加密。
十六、日志备份与 PITR
日志备份持续保存增量 KV 变化，与定期快照组合实现时间点恢复。
需要监控任务状态、Checkpoint Gap、存储、Safe Point 和错误。长时间 Error 可能导致恢复窗口断裂。
PITR 通常恢复到空集群，不能把生产当前集群当作试验目标。恢复前核对快照、日志连续性、目标时间与时区。
十七、恢复演练
- 创建隔离目标集群；
- 恢复最近快照；
- 回放日志到目标时间；
- 验证 Schema、行数、索引和业务聚合；
- 检查账号、权限和系统表限制；
- 压测关键查询；
- 记录真实 RTO。
备份文件存在不等于可恢复。
十八、TiFlash 与 HTAP
TiFlash 使用列式副本服务分析查询。规划副本数、同步延迟、存储和隔离资源。分析负载不应挤占 OLTP 核心组件。
观察副本可用、同步进度、MPP 执行和查询回退。删除/重建 TiFlash 副本前评估网络和存储重建压力。
十九、常见故障
PD 无 Leader
检查多数派、网络、磁盘、时间、端口和节点身份。不要在分区两侧分别强制形成集群。
TiKV 节点异常
检查磁盘、I/O、RocksDB、OOM、网络和 Down Peer。替换前确认剩余副本健康。
SQL 延迟突增
分解 TiDB 执行、PD TSO、TiKV RPC、锁、热点、统计与下游依赖。结合 Dashboard 和慢查询，而不是只看 CPU。
备份慢
检查 TiKV CPU/IO、备份线程、网络、对象存储 IOPS、限流和热点；在业务低峰执行并监控影响。
二十、监控告警
监控 TiDB QPS/延迟/连接/内存、PD Leader/TSO/Operator、TiKV Region/Peer/RocksDB/磁盘、热点、事务冲突、GC、TiFlash、备份 Checkpoint 和恢复演练。
二十一、上线清单
- PD/TiKV 跨真实故障域；
- Label 与副本策略正确；
- SQL、热点、统计和事务完成压测；
- 容量包含 Compaction、快照和恢复余量；
- TiUP 拓扑和配置纳入版本控制；
- 全量与日志备份连续可观测；
- PITR 在空集群完成演练；
- 节点、PD 多数派、热点和磁盘故障有手册；
- Raft 副本之外保留独立灾备。
参考资料
- TiDB Self-Managed：
https://docs.pingcap.com/tidb/stable/ - TiDB Backup and Restore：
https://docs.pingcap.com/tidb/stable/backup-and-restore-overview/ - TiDB Tools：
https://docs.pingcap.com/tidb/stable/ecosystem-tool-user-guide/