mysql 故障分析需要抽取那些信息 -m6米乐安卓版下载

hulong cui 2020-12-03

2464

日常运维mysql数据库中会碰到一些莫名其妙的故障，虽然监控存在，但因为当时没有及时采集信息，导致后续不了了之的情况或等到下次故障发生的时，再采集信息，进行分析问题。

那些故障下，会出现信息少，无法进行分析：

tps突然下降到 0
连接数直接爆满
error日志无记录
突然hang住
数据库服务不停的重启
内存曲线是上升，最后oom

如生产环境中，碰见类似现象，应该采集那些数据，后续分析。

1.基础信息

基础信息包含os信息，mysql版本，高可用，参数设置

mysql -uroot -p -s /opt/data/mysql.sock  -e "\s;show global variables;" > /tmp/msyql_baseinfo.txt

2.查看连接信息

show processlist;

特别是需要关注state里的状态值。
链接太多的是使用以下语句：

select user ,host,db ,command, time,state , info from information_schema.processlist where command<>'sleep' limit 10;

3.error日志抽取

mysql 所有时间都会基本都会写到日志文件里,但问题出现的时候需要确认error 日志。
error日志查看

mysql> show variables like '%log_error%';
 ---------------------------- ---------------------------------------- 
| variable_name              | value                                  |
 ---------------------------- ---------------------------------------- 
| binlog_error_action        | abort_server                           |
| log_error                  | /opt/data8.0/logs/mysql_err.log        |

除了error日志之外，需要系统日志/var/log/messages

4.慢日志抽取

慢日志也会导致mysql 反应慢,所以也需要抽取慢日志
配置文件my.cnf会配置，mysql信息里也可以看到慢日志信息

mysql> show variables like '%slow%';
 --------------------------- ---------------------------- 
| variable_name             | value                      |
 --------------------------- ---------------------------- 
| log_slow_admin_statements | on                         |
| log_slow_extra            | off                        |
| log_slow_slave_statements | off                        |
| slow_launch_time          | 2                          |
| slow_query_log            | on                         |
| slow_query_log_file       | /opt/data8.0/logs/slow.log |
 --------------------------- ----------------------------

对于慢日志分析提供2种方式：

mysqldumpslow 方式：

1.得到返回记录最多的20个sql

mysqldumpslow -s r -t 20 sqlslow.log  > /tmp/mysql-slow.20180725.log

2.得到平均访问次数最多的20条sql

mysqldumpslow -s ar -t 20 sqlslow.log > /tmp/mysql-slow.20180725.log

pt-query-digest方式：

pt-query-digest --limit=100  --since "2016-06-08 00:00:00"  --until "2016-06-08 23:59:59" mysql-slow.log  > /tmp/slow_report.log

备注：建议使用 pt-query-digest

5.锁信息

查看锁等待相关的阻塞线程、被阻塞线程信息及相关用户、ip、port

select locked_table,
       locked_index,
       locked_type,
       blocking_pid,
       concat(t2.user,'@',t2.host) as "blocking(user@ip:port)",
       blocking_lock_mode,
       blocking_trx_rows_modified,
       waiting_pid,
       concat(t3.user,'@',t3.host) as "waiting(user@ip:port)",
       waiting_lock_mode,
       waiting_trx_rows_modified,
       wait_age_secs,
       waiting_query
from sys.x$innodb_lock_waits t1
left join information_schema.processlist t2 on t1.blocking_pid=t2.id
left join information_schema.processlist t3 on t3.id=t1.waiting_pid;

6.innodb状态

show engine innodb status\g;
show engine innodb mutex;

mysql中latch 与lock都被称为锁，在innodb中lock针对的是事务，latch针对的是线程，latch又可以分为mutex和rw_lock，latch的目的是保证并发的线程操作临界资源的正确性.
mutex量指的是一种用于保护一些临界资源的使用的信号量。当有线程需要使用这些临界资源时，会请求获得mutex量，请求成功的线程进入临界区，而请求失败的线程只能等待它释放这个mutex。

7.binlog统计ddl&dml

##统计dml:

mysqlbinlog --no-defaults --start-datetime='2020-05-02 22:36:46' --stop-datetime='2020-05-02 23:25:46' --base64-output=decode-rows -v -v mysql-bin.000007 | awk '/###/{if($0~/update|insert|delete/)count[$2" "$nf]  }end{for(i in count)print i,"\t",count[i]}'|column -t|sort -k3nr

##统计ddl：

mysqlbinlog  --start-datetime='2020-05-02 22:36:46' --stop-datetime='2020-05-02 23:25:46' mysql-bin.000007 | awk 'begin{ignorecase=1} {if($0~/alter/)count[$1" " $2" " $3" "$nf]  }end{for(i in count)print i,"\t",count[i]}'|column -t|sort -k3nr

binlog并行复制统计

mysqlbinlog mysql-bin.000004 --start-position=20087624 | grep -o 'last_committed.*'  | sed 's/=/ /g' | awk '{print $2"\t"$4}' | awk '{count  ;print $0;} end{print "total count is ",count}'

8.监控信息

os信息：查看cpu top ,io iostat状态，网络流量
mysql信息：连接数，active线程数，锁等待，临时表使用情况，tps，qps，网络 input&out信息信息

9.mgr状态

mgr状态查询

show master status\g;
select * from performance_schema.replication_group_member_stats\g;

mgr成员间的角色和状态信息

select a.member_id, a.member_host, a.member_state, a.member_role, b.channel_name, b.count_transactions_in_queue, b.count_transactions_remote_in_applier_queue from performance_schema.replication_group_members a, performance_schema.replication_group_member_stats b where a.member_id=b.member_id order by a.member_role;