天天看點

MySQL 5.7slave_compressed_protocol參數導緻複制bug

使用MySQL5.7的半同步複制時,發現主庫一個簡單的寫操作會執行1s,通過show profile分析是半同步導緻。

檢視主從日志,發現報錯如下:

主庫報錯:

2018-05-21T05:34:06.955592Z 0 [ERROR] /usr/local/mysql-5.7.21-linux-glibc2.12-x86_64/bin/mysqld: Got an error reading communication packets

2018-05-21T05:34:06.967776Z 21 [Note] While initializing dump thread for slave with UUID <26b1280d-2125-11e8-b5a8-005056ac3676>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(20).

2018-05-21T05:34:06.967864Z 20 [Note] Stop semi-sync binlog_dump to slave (server_id: 12233306)

2018-05-21T05:34:06.967954Z 21 [Note] Start binlog_dump to master_thread_id(21) slave_server(12233306), pos(mysql-bin.000004, 484)

2018-05-21T05:34:07.957450Z 21 [Note] Start semi-sync binlog_dump to slave (server_id: 12233306), pos(mysql-bin.000004, 484)

從庫報錯

2018-05-21T05:54:29.787788Z 4 [ERROR] Error reading packet from server for channel '': Lost connection to MySQL server during query (server_errno=2013)

2018-05-21T05:54:29.787880Z 4 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000004' at position 484 for channel ''

2018-05-21T05:54:29.787908Z 4 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

經過初步分析,隻有半同步才會觸發該問題,那麼應該是從庫傳回的ACK包出現bug,主庫無法解析,最後經過調整參數,确認半同步下,隻有從庫開啟參數slave_compressed_protocol才會出現該問題,官方預設參數為OFF。

即出問題的條件,a.5.7 b.從庫slave_compressed_protocol=1 c.主從半同步

該問題确認為5.7bug,已經有人提了,不過網上的案例還是很少。

https://bugs.mysql.com/bug.php?id=85382

繼續閱讀