可以参考下官方文档，描述得很详细了，因为内容过多，建议先做检查。
比如 Region 的健康度…
https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices#region-健康度
https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices
1 天前
日志看起来是 backoff了，而且是 regionMiss
检查下 region 的状态吧，看看有哪些是需要的，哪些是不需要的，需要排查一下在进行修复
region 状态异常会导致 tikv 频繁向 PD 发起请求，对齐 region 的状态和信息… 这个可能是导致异常的原因
2 天前
keepalived，这么重要的参数都不要么？
没有这个参数，超时后连接可能还在，在引用的时候，就会出现这个错误了，因为没探测是否存活，是否可用。
这个问题找你公司的架构师帮你看看…
4 天前
哦，可以试下binlog 的组件，5.x 部分兼容，binlog 的数据capture 是 tidb，会给tidb 节点带来一些压力。
如果不升级，这个是可以参考的方案
7 天前
ticdc 在 6.x 才有很多修复， 5.x bug也比较多
要解决问题，可以考虑采用 ticdc 把数据分发到 kafka，在通过 flink 对接 kafka 即可，稍微麻烦点
看你对是否有帮助了
7 天前
https://docs.pingcap.com/zh/tidb/stable/tiproxy-load-balance#负载均衡策略配置
改下策略在试试，或许是配置的参数不够
7 天前
2025-01-14 10:22:48,462 WARN org.tikv.common.PDClient - failed to get member from pd server.
org.tikv.shade.io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after 0.199976517s. [remote_addr=/10.xxx.xx.113:2370]
PD 是集群哦，这感觉是 BUG了，参考你的配置：
‘pd-addresses’ = ‘10.xxx.xx.111:2370,10…
7 天前
这个提示，是告知这两个参数要一起使用。
在 TiDB 的备份与恢复工具 BR 中，--ratelimit 和 --concurrency 是两个重要的选项，用于控制备份任务的性能和对集群的影响。
--ratelimit 选项
--ratelimit 用于限制每个 TiKV 节点执行备份任务的最大速度，单位是 MiB/s。通过设置这个参数，可以控制备份文件保存到外部存储的速度，从而减少备份任务对集群性能的影响。使用 --ratelimit 时，BR 工具会自动将 concurrency 参数调整为 1，以确保速度限制的有效性。这意味着在限制速度的情况下，备份任务的并发度会被降低，以避免过多…
7 天前
有两点供你参考：
查询返回的结果大概多少行记录？
client → server 请求后，需要server(tidb) 返回给 Client，数据量较大的情况下，client性能不好，资源不足只能慢慢处理？需要排查client 端的日志
client → server 网络带宽 是否有瓶颈？
client 是否能支持流式处理？解决性能瓶颈的问题. （JDBC 的协议是支持的）
9 天前
数据太重要了，目前自动化的程度暂时没办法满足这个适应性，还需要等待和成长
唯一可以期待的就是监控指标的智能分级，不过这需要将现在的经验和运维流程在进一步提炼，难度不小
10 天前
数据的迁移尚未完成，会出现这种情况。
两种解法：
等待迁移完成
取消原来设定的 数据同步的配置信息，确认配置变更完成之后，在缩容后，重新扩容。
待扩容完成之后，节点状态正常，在重新开启数据同步的配置
观察数据同步是否正常
10 天前
没有更多内容了