一般来说,先看监控,看日志,看慢查询,看资源使用情况,并发情况,然后对症下药
altermanager告警–>TOP sql/Grafana查看异常–>慢查询 优化
一般都是dashboard+grafana+日志，针对不同的故障查询不同的页面。
再就是来论坛找类似的经验
深有感触
【排查问题】从操作系统到中间件到应用到数据库，一步步定位，当然有一定经验后，一看就大概能猜到是哪儿的问题，然后深一步查
【解决问题】找到问题点之后，就是怎么解决了，这需要具体问题具体分析
【记录及完善】需要一下预防措施，防止再次出现，或出现后能更快都解决
问题现象；监控；db日志@OS日志。
监控多而杂，希望TiDB融入AI后的错误定位及对应的解决方案自动弹出。
dashboard界面加上日志
日志+面板+现场
监控和日志
1 个赞
遇到过某台TIDB SERVER停止响应的情况，最快恢复方法： 重启了服务器后，重新启动TIDB SERVER
就是看看
一般我们又较全方位的全局监控，一般情况就能分别出是否事 TiDB 数据库自身的故障，如果需要进一步的话，就分析 Dashboard 和 TiDB 的 Grafana 监控大盘。
使用的云环境比较多
大部分时间是在优化慢SQL
第一步肯定是看监控
第二步查看实时SQL，看事务时间较久的是否需要查杀，是否需要手动限流
第三步查看是否有锁，有些锁等待会隐藏，在PROCESS LIST里看不到的，如果有等待查看等待原因，产生锁等待的表及执行实际的SQL
优化慢SQL，首先加缺失索引，适当增加；其次看是否需要修改SQL写法，这个就灵活了，半链接、子查询、增加Hints等等；最后再看表结构是否需要调整，字段冗余，表适当合并、拆分。
数据库负载高先监控看那个节点高,然后去那个节点看具体的sql,优化慢sql
dashboard+grafana+日志+sql脚本大全
dashboard+慢查询
首先是发现，检查dashboard+grafana+日志等发现问题；
其次是对问题的认知，将相关错误内容发到论坛或者咨询专业人士获取支持，分析问题可能的原因；
第三是明确处置目标，形成解决方案；
最后保留事件记录，完善故障处理手册。
挨个节点检查状态，相互ping
2 个赞
- dashborad查看监控
- 网络延迟，我们好几次都是由于网络延迟导致的
1.先看Dashboard是不是由于啥慢SQL导致的
2.没有明显的看Grafana，看IO、网络、线程池等