登陆一下目标端 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 还剩下多少?另外读写影响角度是什么样的 ?
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 扩容几个新的在不同物理机器上面,有同样的问题吗?
懂了~ 其实有几部分,prometheus 这边的历史数据会通过独立账号的进行访问提供监控数据库的,其他部分实时性数据会通过 tidb、pd、tikv 的 promtheus 的 api 及时 pull 过来。
[image]展开描述一下?是 Prometheus 开启了什么基础验证? 是 SSL 还是 Security verify 这个?