MySQL案例之——生產slave庫無法應用日誌

wxjzqym發表於2015-09-12
MySql應用日誌
環境：percona-server 5.6.21-70.1-log 

問題描述：
    透過show slave status監控到從庫io thread執行緒能夠正常接收binlog,但是Relay_Log_File和Relay_Log_Pos這兩個指標一直處於停頓狀態，從現象上看sql thread一直沒有正常應用日誌。

診斷過程：
mysql> show processlist;
+----+-------------+-----------------+-----------+---------+--------+----------------------------------+------------------+-----------+---------------+
| Id | User        | Host            | db        | Command | Time   | State                            | Info             | Rows_sent | Rows_examined |
+----+-------------+-----------------+-----------+---------+--------+----------------------------------+------------------+-----------+---------------+
| 26 | system user |                 | NULL      | Connect |    534 | Waiting for master to send event | NULL             |         0 |             0 |
| 27 | system user |                 | NULL      | Connect | 111738 | System lock                      | NULL             |         0 |             0 |
+----+-------------+-----------------+-----------+---------+--------+----------------------------------+------------------+-----------+---------------+
從show processlist資訊可以看出sql thread一直在遭遇system lock。

mysql err日誌資訊：
2015-09-09 17:46:44 23701 [Note] Slave I/O thread: connected to master 'xxxx@yyyyy:zzzzz',replication started in log 'mysql-bin.008454' at position 93488738
2015-09-09 17:48:06 23701 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2015-09-09 17:48:06 23701No [te] Slave SQL thread initialized, starting replication in log 'mysql-bin.008454' at position 93488738, relay log './-relay-bin.000001' position: 4
err日誌中的警告資訊對複製功能沒有任何影響，這條資訊主要是因為mysql5.6開始支援slave crash-safe repliaction功能，可以將master.info和relay-log.info的資訊
寫入到資料庫表中。

show slave status\G
.....
               Relay_Log_File:relay-bin.000002
                Relay_Log_Pos: 90773529

.....
透過show slave status確定relay-log hang住的位置。

透過mysqlbinlog分析relay-log hang住的position所在的內容：
mysqlbinlog  --base64-output=decode-rows --start-position=90773529 relay-bin.000002
透過分析日誌內容發現hang住的位置正在對一個test.xxx表進行delete操作，該表有300多萬行的資料，和開發溝通後發現此為測試表，可以忽略這個事務。


解決方案：
1.首先停止slave
2.設定全域性引數sql_slave_skip_counter=N來跳過N個event
3.最後啟動slave
關於對sql_slave_skip_count引數的正確理解可以參考下面的連結，寫的不錯：
http://dinglin.iteye.com/blog/1236330

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/20801486/viewspace-1798122/，如需轉載，請註明出處，否則將追究法律責任。

相關文章