mysql復制超時排查

2024-07-24 12:36:03

字體：大中小

來源：轉載

供稿：網友

　　主從延時如果排查？

　　1. show slave status/G，看一下relay_master_log_file & exec_master_log_pos數值有沒有變化（如果是GTID復制也可以看executed_gtid_set的事物號有沒有增長），如果一直不變化，說明有大事物，導致sql_thread線程hang住，這個時候需要查看主庫的binlog，看一下是什么事物：

　　 mysqlbinlog -v --base64-output=decode-rows --start-position= exec_master_log_pos relay_master_log_file | less

　　然后等大事物結束或者回滾；

　　這次事物結束后，如果下次從庫不能接受這樣延時，怎么辦，有什么根本的解決方法？

　　（1）把從庫對讀要求比較高的業務切換到主庫上；

　　（2）以后更新大事物拆分成多個小事物，比如說一次更新20萬條改為一次更新10萬條；

　　2. 如果relay_master_log_file & exec_master_log_pos數值增長很慢，怎么辦？

　　（1）解析對應的binlog： mysqlbinlog -v --base64-output=decode-rows --start-position= exec_master_log_pos relay_master_log_file | less

　　查看對應的表，看看表有沒有主鍵，索引等結構

　　（2）檢查系統是不是過載cpu,memory,io，

　　io可以通過工具iotop和pt-ioprofile查看

　　如果發現是mysql庫下的slave_relay_log_info.ibd文件占用IO很高，可以考慮調大sync_relay_log_info，讓這個文件同步不要太頻繁。

　　cpu可以通過top命令查看:

　　如果user比較高，可以show processlist查看，慢日志，有沒有大量的排序，主要是sql語句

　　如果sys很高的話，一般來說，因為：

　　1、發生swap

　　2、數據庫內發生嚴重的鎖等待

　　3、用了ssd等設備，產生大量中斷，或者網卡中斷（cpu中斷不均衡）

　　4、MySQL里頻繁創建連接及關閉

　　5、頻繁用到timestamp列，且time_zone=SYSTEM

　　memory：

　　free -gt

　　vmstat

　　看看mysql的errorlog，主從的server-id是否不一樣

　　如何查看網卡是否連接：

　　ifconfig |grep up

　　dmesg|grep eth

　　以上方法都不行的話，可以嘗試其他方法：

　　使用工具perf top

　　pstack `pidof mysqld`

　　ipmitool

　　硬件方面raid卡等

（編輯：武林網）

上一篇：記錄一次Mysql主從不同步事故問題于事故處理辦法

下一篇：Mysql索引概論