看各种指标，异常sql，日志进行分析
找到对应cpu高的top sql，基本可以覆盖95%以上的场景。
看看积分，兑现下
一般都是dashboard，查看慢日志，流量可视化菜单以及集群资源的使用情况(cpu、磁盘等)
先分析grafana ，
再分析dashboard，
详细分析grafana，
继续分析数据库日志+系统日志，
社区，
官网，
专家大佬，
表妹！
1 个赞
先看dashboard，再看后台日志
定位热点问题 sql，使用 top sql功能
DM2.0 同步mysql5.6到Tidb4.0.2 升级DM到5.3版本，然后报错 提示主键冲突，根据提示的语句和主键值去Tidb检查，发现无异常，最后去官网搜索相关问题，发现是一个BUG，直接执行resume-task 就可以恢复。然后写了一个脚本，每分钟检查是否有PRI报错关键字，如果有自动执行resume
使用 ping 或 traceroute 工具检查网络延迟和丢包情况。
先看dashboard，是否有慢SQL引起，然后看监控通过网络，cpu、io等监控情况排查问题
其实我是进来学习的。我的话，一般都是dashboard+grafana，最后才看日志
performance面板 集群运行效应一目了然
1、看故障发生的组件，缩小排查范围
2、看日志，故障发生时各日志情况
3、看监控，qps cpu io 内存使用，当时机器状态、进程状态
4、看top sql 慢sql、异常SQL。
5、故障复现
总体来讲，就是监控、日志、SQL、现场
一般都是dashboard+grafana+日志，针对不通的故障查询不同的页面。
从监控和日志入手，逐步排查
sql性能变差
grafana+dashboard
grafana dashboard ，搞不定就继续日志
看Grafana的overview和dashboard
慢查询sql
日志expensive关键词
-
碰到过TIDB SERVER 停止响应的情况，时间紧急，最快的恢复方法是重启操作系统，再启 动TIDB SERVER
-
部署HAProxy 解决某台TIDB SERVER故障时，不可用的问题