这个方式可以参考一下，另外就是 TiDB 在 Dashboard 里面有相应的 TopN 和 Slow query，可以看看 21:30 到 21:35 之间的 SQL 有没有异常的。

TiFlash 日志完整一点的提供一下，需要往上翻一翻哈

在提供一下系统 CPU 信息是否正确，可以通过 lshw -C cpu 或者 cat /proc/cpuinfo 命令查看 CPU 相关信息。如楼上所说，可能存在系统的依赖包版本和 TiFlash 不兼容的问题，会进一步确认一下。

TiDB 用户有 sudo 权限吗？https://docs.pingcap.com/zh/tidb/v8.1/check-before-deployment [img_v3_02jd_c8e48b0a-e5ae-4036-ba0f-5606fa5f76ag]

./topology.yaml 的配置发一下看看

只有你的 topology.yaml 里面配置的用户是 root，才会这样生成的。

[image] 目录权限检查过吗？如果是 tidb 用户部署的，需要创建文档是 tidb 用户 770 权限。

K8s 对应版本发一下呢？

你可以通过配置一个空的 logBackupTemplate 对象来绕过这个类型检查。以下是一个示例的 BackupSchedule YAML 文件： # 日志备份模板，配置为空对象 logBackupTemplate: {}

收到，产品需求已关注哈，原始密码不修改会有安全风险的，这块咱们是如何考虑的？

尝试执行复现一下 v5.4.1 的内存消耗情况，可能是和内存溢出有关系。 [image]

帮忙整理以下信息： 当前操作系统版本以及服务器架构； 其他差异环境是否遇到类似问题； 是否只有该套集群遇到这个问题；

你可以提供一下具体的 TiKV 停掉以后，TiKV 里面的 region group 选举报错，是不是因为网络不稳定，导致选举失败导致的。

看问题不像是 TiDB 的产品缺陷问题，建议再排查一下 TiKV 和 PD 的网络环境是否有关？比如千兆共享网络带宽打满，导致请求发送排队超时。

确认一下 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 自带的。