确认一下 Store1 的延迟高原因，需要检查一下 Store1 的 TiKV 的监控，是否异常指标。

应该是已知 bug ，建议升级到 v6.5.10 的版本，强烈建议升级到 v7.1 版本。 https://docs.pingcap.com/zh/tidb/stable/release-6.5.4 [image]

登陆一下目标端 xx.xx.56.3 的目标端，手动执行 /tmp/tiup/bin/insight 看看。

不用计算，pd-ctl store 查询就可以看到 region 剩余数量； 看结果应该是 region 状态是安全的，没有小于 3 个副本的 region，可以先看一下 pd 自己调度情况，再看看 region group 里面 peer 不等于 3 的情况。

主要看看 region count ，offline 状态 tikv 的空间容量暂时不用看看的。 offline 是正在下线，pending offline 是挂起，需要看看 PD leader 日志为啥挂起这个。region count 统计依赖的 pd-ctl store id 查询当前 store 的 region count 结果，注意一下 offline 状态的 tikv 节点除非是物理机器无法恢复了，不然必须是一个 tikv 启动的状态进行。 需要安装 jq 的工具哈，不是 pd-ctl 自带的。

调整以后，region 的调度速度加快了吗？现在 offline 的 region count 还剩下多少？另外读写影响角度是什么样的 ？

@晓峰008 参考一下楼上的建议，另外如果是调度比较慢，可以通过调整 PD 的 scheduler region 和 leader 调度加速处理一下。 参考一下 pd-ctl 的 json 过滤一下 region 副本数量统计，看看是不是已经有 region 只剩下 1 个副本了。 https://docs.pingcap.com/zh/tidb/stable/pd-control#根据副本数过滤-region

Region 不过自己出问题的，除非环境发生异常变化和不合规操作导致。梳理一下问题，当前问题看起来 2 TiKV 手动下线过程中，可能有其他 region 故障导致无法下线问题？可以看一下 TiKV 日志中的报错 region id 并检查 region group 状态是否正常，有没有副本丢失情况。

看日志报错主要问题还是集中在 IO ERROR，应该不是数据库问题，IO 的 latency 可以排查一下，可以通过 iostat 或者 nodeexporter 的监控一下 diskperformance 监控确认一下。

确定两个问题： TiKV 节点突然挂掉了几个节点？因为看到 PD 记录 store 状态时 3 个 TiKV 同时在做 offline； 可以一下 Region is unavailable 得 Region id 所在得 store 是哪几个，通过 region id 在 PD 里面可以查到。

发一下对应 TiKV 宕机的完整日支看一下？ 不看判断是网卡打满还是 TiKV Panic 问题

看监控截图，感觉网络带宽最大可以到 100MB，是不是千兆网络？

TiDB 日志只是现象，说明 TiDB 从 PD 获取 schema version 失败。但是为啥子失败，还要看看 TiDB Sever 所在节点的服务器状态是否正常、CPU、内存、IO、网络 都要查一下如果没问题，混合部署且资源配置低情况很容易抢占资源的，再说别的。

[image] TiDB POD 扩容几个新的在不同物理机器上面，有同样的问题吗？

这个问题可能有其他原因，不确定是否已知 bug，可以看一下相关的 Release note。 https://docs.pingcap.com/zh/tidb/stable/release-6.5.2 建议升级到 v6.5.10，TiDB 数据库一般只会在最后的 10 这里修复 bug，不会引入新特性的问题。 [image]

https://docs.pingcap.com/zh/tidb/stable/performance-tuning-methods 这个看过吗？TiDB 官网上面有很多这样的材料，可以根据你的 load 场景优化优化参数的，或者分析一下线程池的瓶颈问题。

懂了～ 其实有几部分，prometheus 这边的历史数据会通过独立账号的进行访问提供监控数据库的，其他部分实时性数据会通过 tidb、pd、tikv 的 promtheus 的 api 及时 pull 过来。 [image]

展开描述一下？是 Prometheus 开启了什么基础验证？ 是 SSL 还是 Security verify 这个？

Seatunnel 配置管道任务从 TiDB 4.0 读取后，然后通过 JDBC 分别写入到 Doris 和 TiDB 8.1 吗？ JDBC 配置这块有没有按照这个优化优化？ https://docs.pingcap.com/zh/tidb/stable/dev-guide-sample-application-java-jdbc