恢復複製後主節點上的MySql複製性能

Question

當前配置是基本Master-> Slave複製。每晚在主服務器上運行各種數據導入作業。在此期間，從屬複製關閉，流量指向從屬（以免導致數據加載作業的性能瓶頸/懲罰影響）。

當作業完成時，複製被重新打開（在從屬設備上），意圖在不久之後將流量指向從設備（一旦從設備同步備份）。但問題是，在這一點上，主人存在顯着的性能問題。可能是因爲從屬I/O線程正在努力獲取從主設備複製的所有數據。

作爲一種替代解決方案，關閉從站上的「SQL線程」（保持IO線程始終運行），以免轟炸主站（稍後......一次），一次複製被恢復。然而，這種方法（顯然）的問題在於，當主服務器正在運行繁重的數據加載作業（由於IO線程始終處於運行狀態並將數據移動）時，從服務器正在引發持續的性能問題。

所以問題是，我怎樣才能啓動/停止從站上的複製（根據我的數據加載計劃/要求），而不會對主站或從站造成性能影響？似乎你應該能夠完全關閉複製，然後在不影響主人的情況下再打開它。

在此先感謝！

Answer 1

你能描述負載問題嗎？你掛在愛荷華州，還是主從站之間的網絡連接飽和？你的服務器有多少內存？

您可以通過在主從設備之間放置交叉電纜並將所有複製流量路由到主設備和從設備以改善後者，從而使其脫離LAN。

如果前者是問題，我會說你最好的選擇是讓自己更多和/或更快的磁盤，甚至SSD！您還可以執行二進制日誌記錄來分隔磁盤，以便它不會減慢查詢活動的速度。

總的來說，這聽起來像是你剛剛有一個容量問題，並且你需要提供足夠的資源來處理你指向它的負載 - 沒有任何的雜耍可以讓你解決這個問題。我沒有遇到過配置，二進制日誌記錄是限制因素。任何基本的RAID配置都應該至少處理300M /秒，因此，您需要每秒鐘處理超過30秒的事情，這意味着您需要每晚移動超過9Gb的二進制日誌 - 你真的會生成那麼多的數據嗎？

另一種選擇是使用DRBD for replication - 這樣，從服務器根本不必運行復制查詢或處理binlog，儘管它還有其他複雜性。