我有一個現有的複制設置，其中包含執行 MySQL 5.0 的主伺服器和從伺服器。一個長期存在的腳本在晚上執行，它使用跳過網路在主伺服器上重新啟動 MySQL，執行備份，然後再次重新啟動而不使用跳過網路。從站失去連接，然後每 60 秒重試一次連接，直到幾分鐘後成功連接。以下是現有從站上的日誌：

150520  4:12:01 [Note] Slave: received end packet from server, apparent master shutdown:
150520  4:12:01 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.<binlognumber>' position <binlogpos>
150520  4:12:01 [ERROR] Slave I/O thread: error reconnecting to master '<user>@<host>:<port>': Error: 'Lost connection to MySQL server at 'reading initial communication packet', system error: 111'  errno: 2013  retry-time: 60  retries: 86400
150520  4:14:01 [Note] Slave: connected to master '<user>@<host>:<port>',replication resumed in log 'mysql-bin.<binlognumber>' at position <binlogpos>

我介紹了一些執行 MySQL 5.6 的新從站。他們能夠複製現有數據庫而不會出現任何問題或錯誤，並且數據是一致的。一切似乎都在工作，除了在晚上原來的主伺服器離線進行備份時，新伺服器無法自行重新連接。

這是早上新伺服器上日誌的樣子：

2015-05-20 04:12:01 32401 [Note] Slave: received end packet from server due to dump thread being killed on master. Dump threads are killed for example during master shutdown, explicitly by a user, or when the master receives a binlog send request from a duplicate server UUID <newslaveUUID> : Error
2015-05-20 04:12:01 32401 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.<binlognumber>' at position <binlogpos>
2015-05-20 04:12:01 32401 [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.
2015-05-20 04:12:01 32401 [ERROR] Slave I/O: error reconnecting to master '<user>@<host>:<port>' - retry-time: 60  retries: 1, Error_code: 2003
2015-05-20 04:13:01 32401 [ERROR] Slave I/O: error reconnecting to master '<user>@<host>:<port>' - retry-time: 60  retries: 2, Error_code: 2003
2015-05-20 04:14:01 32401 [ERROR] Slave I/O: error reconnecting to master '<user>@<host>:<port>' - retry-time: 60  retries: 3, Error_code: 2003
2015-05-20 04:15:01 32401 [ERROR] Slave I/O: error reconnecting to master '<user>@<host>:<port>' - retry-time: 60  retries: 4, Error_code: 0
2015-05-20 04:16:01 32401 [ERROR] Slave I/O: error reconnecting to master '<user>@<host>:<port>' - retry-time: 60  retries: 5, Error_code: 0
2015-05-20 04:17:01 32401 [ERROR] Slave I/O: error reconnecting to master '<user>@<host>:<port>' - retry-time: 60  retries: 6, Error_code: 0

我所要做的就是進入伺服器並發出一個STOP SLAVE;，START SLAVE;然後一切都重新開始，沒有任何麻煩。它只是不會自己做。

如果我在 5.6 伺服器之間進行複制並且其中一台離線，那麼 5.6 從伺服器可以重新連接到 5.6 主伺服器就好了。

複製使用者對所有內容只有複製客戶端和複製從屬權限。Connect_Retry新舊奴隸的值都是 60。

雖然允許從 MySQL 5.0 Master 複製到 MySQL 5.6 Slave，但無限期地保持這種情況並不好。為什麼 ？MySQL 5.6 重新連接到較舊的 Master 的方式對於較舊的 Master 可能會更加困難。

為了說明這種性質的問題，請考慮 MySQL 複製如何因 MySQL 版本之間的二進制日誌更改而在版本之間中斷。我之前在回答 2015 年 1 月 2 日問題mysql replication master 5.5 slave 5.1 error on create database時已經討論過這個問題。

在那個答案中，我提到瞭如何在 MySQL 的每個新主要版本中添加二進制日誌事件。這可能要求 MySQL 5.6 忽略或繞過它不理解的二進制日誌中的事件。在極少數情況下，SQL 會在嘗試解開可能已在版本之間更改的二進制日誌事件時中斷。在這種情況下，MySQL 複製的 SQL 執行緒將永遠不會啟動備份。

當我在我的場景中談論 SQL 執行緒時，您的情況涉及 I/O 執行緒。可能有一些問題（錯誤或未經測試的功能）導致重新連接不起作用。鑑於此，Slave 重新連接到 MySQL 以前版本的 Master 不再是一件小事。

自 2014 年 8 月以來已對 MySQL 5.6.20 進行了分類（Bug #73494：Slave can’t reconnect after 2003 error when sha256_password is used）。這與連接到較舊的 Master 沒有直接關係，但 MySQL 5.6 本身存在問題。

您應該考慮以下其中一項

• 將 Master 和所有 Slave 上的max_allowed_pa​​cket增加到1G
• 避免使用 MySQL 5.6 作為舊 Master 的 Slave
• 全面升級到 MySQL 5.6

更新 2015-05-21 18:06 EDT

如果 Master 和 Slave 的max_allowed_pa​​cket設置為 16M，則無需更改。

如果你可以不改變生活skip-networking，試試下面的

• 步驟 01：STOP SLAVE IO_THREAD;
• 步驟 02：執行mysqldump --single-transaction ...
• 步驟 03：START SLAVE IO_THREAD;

這樣，I/O 執行緒 24 / 7 保持連接，您永遠不必重新啟動 mysql。

試一試 ！！！

引用自：https://dba.stackexchange.com/questions/102159