MySQL複製從屬非常慢

我正在研究一個讓我完全困惑的複制問題！這個客戶端在巨大的裸機硬體上有兩個 MySQL 複製集群。請參閱下面的環境。

從站的 IO_Tread 遠遠落後，幾個小時或更長時間。是的，是 IO_tread，而不是 SQL_tread。為什麼下載不那麼大的二進制日誌記錄並將它們寫入磁碟如此困難。我試圖找到一個資源瓶頸，但鑑於大量的硬體無法找到。

唯一奇怪的觀察是，slave的 IO OPS 是 master 的**8 倍。**但即使這樣也不會真正使 SSD 磁碟過載。數據包跟踪顯示 SLAVE 經常將 TCP 視窗設置為零。怎麼，資源這麼多？

任何有想法的人可能會導致這種奇怪的行為？為什麼我在 slave 上有更多的 IO？什麼會導致 IO_tread 變慢？

環境： 兩台機器：裸機 DELL，MySQL 5.6.30，12CPU，128GB mem，SSD 上的 datadir，Net I/F：Emulex 10Gb，基於 ROW 的 binlog FMT

症狀：

MASTER: CPU: 67% 1 個處理器輕度使用, MEM: 70% 使用, 30% free, IO OPS: ~2500 tps, 30% util on SSD, slave 客戶端執行緒:發送 binlog 到 slave。

奴隸：

CPU：40% 1 個處理器輕度使用，MEM：70% 已使用，30% 空閒，IO OPS：~16000 tps，SSD 上 70% util，網路 I/F 上的錯誤計數器為 0（零），經常設置 TCP 視窗在 IO_tread 上為 0，從屬 IO_tread 非常慢。延遲一個多小時！

SAME master上的另一個slave一點問題都沒有！這個奴隸的硬體規格要低得多！

無法下載主 binlog。為什麼如此高的 IO 率？

停止從站也會停止 IO OPS。（正如所料，OPS 來自 MySQL）

通過網路（使用 ncat）將大量數據從主伺服器複製到從伺服器顯示出預期的性能。

其他觀察：

顛倒角色時，問題保持不變。

另一個具有相同硬體的複制集群沒有問題。這個集群在slave上的IO OPS略低於master。該集群使用基於 STATEMENT 的 binlog

抱歉，我需要 50 位代表發表評論，所以…這裡有幾件事要開始。

1. 您是否偶然將 ZFS 用於您的文件系統（它可能會意外限制磁碟）？
2. 您的配置文件（幾乎）是否相同（複製主/從設置除外）​​？配置應該與其他從屬設備相同，除了記憶體緩衝區（聽起來像伺服器硬體不同）。 https://www.percona.com/doc/percona-toolkit/2.2/pt-config-diff.html
3. （在從機上執行，然後發布）SHOW SLAVE STATUS\G
4. （在主伺服器上執行，然後發布）SHOW MASTER STATUS\G
5. 檢查從屬狀態幾次（可能相隔一分鐘）。Exec_Master_Log_Pos 和 Read_Master_Log_Pos（或 Retrieved_Gtid_Set 和 Executed_Gtid_Set）是否都在移動（理想情況是它們正在追趕）？
6. 中繼日誌是儲存為表還是文件？

編輯 在閱讀了 Rick 的文章後，我回過頭來注意到（起初認為兩者都是 SBR）您執行得更快的集群正在執行 SBR（基於語句的複制），而慢速的是 RBR（基於行）。Rick 關於查詢類型以及在一小時內生成多少二進制日誌的問題很重要。

有時 RBR 更快，有時 SBR 勝出。對所有場景進行測試和基準測試始終很重要。

如果 I/O 執行緒落後，則網路很慢。

如果 SQL 執行緒落後，那麼它可能是複制的串列性質（除非您有新版本）或來自 的爭用SELECTs，或磁碟 I/O，或硬體差異（通常，從站至少應該與大師）等。

如果你正在做巨大的UPDATEsor DELETEs，那麼基於行的複制會在複製流（binlog）中放置很多東西。這可能是相關的嗎？

“MASTER：CPU：67% 1 個處理器輕度使用”——即使一個核心的 67% 也相當高。也許缺少一些需要的複合索引？

從站是否做了很多SELECTs可能會干擾複製的事情？

SHOW VARIABLES LIKE 'query_cache%';兩台機器上的值是多少？不要將 `query_cache_size 設置為大於 50M，不管 RAM 的大小。

每小時創建多少 GB 的 binlog？

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