一 簡介:今天來聊聊周期性從庫延遲的問題，是上一篇的基礎分析的一個場景

二 背景:近期每天的指定時間段,收到從庫延遲的報警,然后過一段時間恢復.由于從庫是提供讀服務的,所以需要解決

三 分析思路:

? ? ? ? ? ? 1 周期性延時,而且全部從庫都出現延遲，應該是由于主庫的DML操作引起的

? ? ? ? ? ? 2 查看主庫的慢日志記錄(我們的數據庫會每小時進行切割)，也并沒有發生DML慢語句,排除因為慢sql(DML操作)導致的問題，主庫的DML操作如果出現慢語句,同步到從庫會更慢,比如update,delete語句

? ? ? ? ? ? 3 查看從庫的慢日志記錄，是否出現DML慢語句，并沒有出現

? ? ? ? ? ? 4 查看天兔平臺記錄的DML語句曲線圖,發現這段時間內出現了大量的并發insert操作,定位到了問題

四 解決問題:

? ? ? ? ? ?1 采用mysqlbing進行指定時間段內的分析

? ? ? ? ? ? mysqlbinlog --no-defaults --start-datetime='2017-11-17 07:50:00' --stop-datetime='2017-11-17 08:20:00' --base64-output=decode-rows -vv binlogname > result.txt

? ? ? ? ? ?2 運用AWK工具進行這段時間內的增刪查改統計

? ? ? ? ? ?awk '/###/ {if($0~/UPDATE|INSERT|DELETE/)count[$2" "$NF]++}END{for(i in count) print i,"\t",count[i]}'? 文件名| column -t | sort -k3n

? ? ? ? ? ?會統計 庫+表 增刪查改次數 并進行排序

? ? ? ? ? 3 根據結果，發現了 insert最高的一張表，然后和運維確認業務IP，和研發進行溝通，得知業務一段時間進行集中處理，導致了上述情況。

? ? ? ? ? 4 可以先根據pt-iopfile進行定位,可以清晰的定位到表,具體為pt-iopfile -p pid,針對mysql文件具體IO進行分析,對于集中表的業務,能快速具體進行定位

五? 此次排查順利結束

六 解決方式:

? ? ? 1 研發進行業務優化,減少DML最高的表的處理

? ? ? 2 不同業務庫進行遷移,減少單臺DB的壓力

轉載于:https://www.cnblogs.com/danhuangpai/p/7851226.html

總結

以上是生活随笔為你收集整理的mysql 案例~mysql主从复制延迟处理(2)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。