淺談mysql主從復制延遲
1 概念解讀
需要知道以下幾點
1 mysql的主從同步上是異步復制，從庫是串行化執行
2 mysql 5.7的並行復制能加速從庫重做的速度，進一步緩解 主從同步的延遲問題
3 mysql的Seconds_Behind_Master代表延遲的狀態 0為無延遲
4 mysql的Slave_SQL_Running_State:狀態在異常時會有所表現，延遲出現的時候要尤為注意
5 Master_Log_File = Relay_Master_Log_File，Read_Master_Log_Pos = Exec_Master_Log_Pos 同樣可認為 主從 0 延遲
2 場景分析
1 sql和io 線程正常 延遲一會就恢復，這樣大多是由於短暫的事務引起的，
1 短暫小事務 不用關心
2 定期出現，需要具體分析
2 sql和io線程正常 磁盤 IO 過高 iowait很高，達到10%以上Exec_Master_Log_Pos 一直在變 證明 從庫一直在追趕主庫 分為幾種情況
1 從庫的機器硬件性能很差
2 主庫執行的DML沒有應用索引或者應用不當導致耗時很久，在從庫回放時候很慢
3 HP機器RAID卡充放電不正常 會導致這種問題
4 主庫業務過於集中,例如一台機器多個DB,導致DML非常頻繁
5 從庫采用ext4文件系統,jdb2占用IO太高
3 sql和io線程正常 延時瞬時很高,然后又恢復正常
4 sql和io線程正常 Slave_SQL_Running_State：Reading event from relay log，Exec_Master_Log_Pos 一直不變 分為幾種情況
1 操作的表是myisam表或者沒有索引
2 執行了大事務(包含DDL） 可能導致這種情況，經常見於刪除大量數據場景
5 Slave_SQL_Running_State：waiting for table flush ,延遲 一直增加
1 在從庫，當xtarbackup備份的時候,會flush table with read lock，這時候如果從庫有慢查詢在進行，會導致一直等待，waiting for table flush，延遲不斷增加
6 一台從庫無延遲,另一台從庫出現延遲
1 在同等硬件配置情況下,主要出現在一台數據庫需要寫中繼日志,以提供canal解析binlog服務。
7 外鍵檢測延遲問題
1 這種情況比較少見，是我在網上搜到的案例
8 並行復制導致延遲
1 常見於大表的DDL操作
3 解決方法
前提 進行 binlog分析
1 讀取Exec_Master_Log_Pos mysqlbinlog進行卡主點的解析 mysqlbinlog -vvv --base64-output=decode-rows -j 位置 mysql-bin文件 | more 確定 操作的table和DML語句 還可以根據生成的sql文本大小估算下數據量
2 針對問題2的解決方案
1 更換硬件
2 優化主庫的慢日志語句，確保從庫能更快的運行
3 更換RAID卡電池
3 針對問題3的解決方案
對於毛刺現象的從庫延時問題 最大的可能來自於時間跨度較大的執行事務(常見於長時間才提交的事務)
4 針對問題4 的解決方案
1 將myisam表轉換為innodb表
2 添加主鍵
3 將大事務進行拆分，尤其是大量的delele操作，很容易導致這種問題
4 將業務進行優化
1 研發進行業務優化
2 業務庫進行拆分
5 針對問題4的解決方案
1 優化在從庫的查詢 並且調整備份數據庫時間
6 針對問題6的解決方案
1 升級硬件 2 減少主庫事務
7 針對問題7 8的解決方案
1 去掉外鍵檢測 2 對於DDL沒太好辦法
8 通用解決方案
1 如果在數據量不是很大的情況下，重做從庫是最快的方式
2 可以嘗試下 提交方式設為 2 禁止寫binlog等方式嘗試加速復制（感覺效果並不是太好）經朋友補充 添加 innodb_flush_log_at_trx_commit=2 sync_binlog=500 效果不錯，可以提升速度
3 mysql 5.7的並行復制可以加速復制，非常建議使用