1.检查集群整体状态
2.查看慢查询情况
3.查看集群io流量
4.查日志
故障现象不一样，调查问题的角度也会不一样。
1.检查集群整体状态
2.检查集群服务器资源使用情况
3.通过dashboard和granafa查看各种对应指标
4.查日志
看看Grafana的overview和dashboard，如果某个有问题再具体看对应的日志
看dashboard，是否有慢SQL引起，然后看监控通过网络，cpu、io等监控情况排查问题
我们集群是用k8s部署的，日志什么的都有采集很齐全，其它手段就是结合grafana面板进行查看了，日志+指标 基本能定位到问题
先看dashboard，再看grafana，最后在具体分析
最近遇到比较多的问题是：
业务方问：我的ｓｑｌ怎么突然那么慢了？
查看ｇｒａｆａｎａ，ｔｉｋｖ的扫描多一些，就是ｇｒｐｃ那个面板，看过去同一时间的对比，发现扫描多一些，那就慢了。扫描主要是：coprocessor请求。
这种情况就和业务方确认，是不是有上线，有ｓｑｌ变化？
如果没有的话，看看慢的ｓｑｌ的执行计划是不是选错了，比如说表的健康度变低导致的。
然后绑定执行计划，完成！
主要就看grafana和dashboard
1、现在操作系统和硬件方面的日志
2、接着看各个组件的日志
3、dashboard
茶话会专业性越来越强了
我一般看zabbix告警，内存高了重启tidb节点，SQL执行时间长了保存SQL并kill掉，然后分析
- 查询缓慢
- 分析慢查询日志：TiDB 提供了慢查询日志，可以通过查看慢查询日志来确定哪些查询执行时间较长。分析这些查询，看是否可以通过优化 SQL 语句、添加索引等方式提高查询性能。
- 检查资源使用情况：观察 TiDB 服务器的 CPU、内存、磁盘 I/O 等资源使用情况。如果某个资源使用率过高，可能会导致性能下降。可以使用系统监控工具（如 top、iostat 等）来检查资源使用情况。
- 检查 TiDB 配置参数：一些 TiDB 的配置参数可能会影响性能，如内存限制、并发连接数等。根据实际情况调整这些参数，以提高性能。
- 写入缓慢
- 检查事务大小：如果事务过大，可能会导致写入缓慢。尝试减小事务大小，以提高写入性能。
- 检查磁盘 I/O：写入操作通常会涉及磁盘 I/O，如果磁盘 I/O 性能低下，可能会影响写入速度。可以检查磁盘的读写速度、磁盘空间使用情况等。
- 检查 TiDB 集群状态：如果 TiDB 集群中的某个节点出现故障或负载过高，可能会影响写入性能。检查集群的状态，确保所有节点都正常运行。
1 个赞
我精通DM故障恢复
我精通TICDC故障恢复
TiDB慢查询， 执行计划错误
目前处理的核心的思想第一步是缩小故障排查范围，确定导致问题的第一责任组件。第二是查看责任组件的日志，分析故障时刻的日志。一般到这里就差不多了。对于分析日志无法定位的问题，优先 ASKTUG、其实尝试理解代码。实际中大不数问题都是重复的，例如SQL 执行oom、应用到数据库链接断开等等
跟着表象，深入分析。
查看日志 和监控。
硬件故障算不算
第一步：排除系统问题引发的数据库问题 第二步：通过可视化监控平台和面板检查集群是否存在性能瓶颈和慢sql 第三步：查看tidb 三大组件的运行日志，检查是否有其他警告和错误异常 ，最后：求助社区和tidb 相关人员
dashboard监控