MySQL 5.7並發復制和mysqldump相互阻塞引起的復制延遲
本來MySQL BINLOG和SHOW PROCESSLIST命令屬於八竿子打不著的兩個事務，但在最近故障排查中，發現主庫和從庫已經存在很嚴重的復制延遲，但從庫上顯示slave_behind_master值為0，復制SQL線程與備份線程之間相互阻塞，但未報死鎖。
在從庫上執行SHOW PROCESSLIST發現復制的SQL線程等待鎖，而等待SQL的WHERE條件竟然是類似於WHERE C1=‘ABC‘ AND C2>‘2018-03-01‘ AND C2<‘2018-03-26‘ 這種個範圍查詢，第一時間想到就是怎麽是個基於STATEMENT的復制，不科學啊，我們生產環境統一使用基於ROW格式的復制，難道研發私自修改回話級別的復制格式？
使用MySQL Binlog導出日誌一看：
發現真錯怪研發同事啦，rbr_only=yes說明基於ROW格式進行復制，“SET TRANSACTION ISOLATION LEVEL READ COMMITTED”也是基於行格式復制的典型特征之一，last_committed和sequence_number用於MySQL 5.7版本中的並發復制，row_query後跟的是在主庫上執行的原始SQL，也就是我們在從庫SHOW PROCESSLIST中看到的SQL，但實際上從庫執行的還是BINLOG部分，該BINLOG可以直接可以直接直接在從庫上執行，也可以解析成一行行的數據DML操作，BINLOG部分如下：
==========================================================================================================
另外一個很有意思的問題，如果在從庫上運行mysqldump進行備份，且從庫上使用並行復制，會導致備份和復制相互阻塞：
在上面的阻塞中，多個SQL線程與備份線程相互之間阻塞，且MySQL無法有效檢測出死鎖環路而觸發死鎖的回滾機制，導致復制線程和備份作業相互hang住，需要DBA進行幹預（取消備份或停止復制），在復制SQL線程被hang住期間，復制的IO線程仍可以正常工作接受到主庫的Binlog信息，但slave_behind_master並不會隨之增大，如果僅通過監控slave_behind_master值來判斷主從復制延遲，則會導致延遲監控存在嚴重漏洞，因此在監控復制延遲時，除監控slave_behind_master值外，還需要監控主庫binlog位置點和從庫執行的binlog位置點。
==========================================================================================================
打完收工，妹子鎮貼：
MySQL 5.7並發復制和mysqldump相互阻塞引起的復制延遲