Leonard
(Hacker Byb Hr4 Nu)
1
【TiDB 使用环境】测试环境
【TiDB 版本】v7.5.5
【部署方式】物理机器
【操作系统/CPU 架构/芯片详情】
【机器部署详情】128C 1T 内存
【集群数据量】70T
【集群节点数】36 tikv
【问题复现路径】
【遇到的问题：问题现象及影响】
3az 3副本，每台机器两个tikv节点且数据盘独立。模拟一台机器down掉（两个tikv）。30分钟后两个tikv状态为down，副本开始往其他节点调度（符合预期）。但是这个调度速度太慢了。调整了参数还需要5个小时才能补全副本。假设补全副本期间其他az的一台机器也挂了，那这时集群岂不是崩了（虽然只是部分region不可用）。想了解下这种情况应该如何处理？难道只能用br恢复 或者 如何能够让调度速度大幅提高从而减少这个补副本的gap
https://docs.pingcap.com/zh/tidb/stable/configure-store-limit/
【资源配置】
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
可以检查一下机器间的网络带宽是否成为瓶颈. 可以逐步提高 调整 store-limit 、max-pending-peer-count 、snapshot-concurrency 等参数，逐步压测极限速度
1 调整 PD replica 调度并发
默认很小：
replica-schedule-limit = 4
可以调大：
pd-ctl config set replica-schedule-limit 64
作用：
同时补副本任务数量
文档说明：
该参数直接影响节点故障后的副本恢复速度
乾坤大挪移
(Ti D Ber A8r Uup Mr)
4
整 snapshot 数量限制（最关键）
默认：
max-snapshot-count = 3
建议：
pd-ctl config set max-snapshot-count 64
作用：
每个 TiKV 同时收发 snapshot 数量
独善其身
(Ti D Ber Bi Rqfz5 K)
5
max-snapshot-count,么有充分发挥你主机的处理能力.
纯白镇的小智
(Ti D Ber Qm Qja01 M)
6
TiDB 副本调度的核心由 PD 控制，默认参数偏保守（避免冲击集群），故障场景下可临时调大调度并发和速度限制，优先保障副本补全。
