MySQL主從複製原理

MySQL主從複製是構建高可用MySQL的基礎，複製就是讓一臺服務器的數據和其它服務器保持同步，一臺主庫能夠同步到多臺備庫上面，備庫也能夠做爲另外一臺服務器的主庫。主庫和備庫之間能夠有多種不一樣的組合方式。

主從複製

1)、主庫記錄二進制日誌，每次準備提交事物完成數據庫更新前，先記錄二進制日誌，記錄二進制日誌後，主庫會告訴存儲引擎能夠提交事物了

2)、備庫將主庫的二進制日誌複製到本地的中繼日誌中，首先，備庫會先啓動一個工做進程，稱爲IO工做線程，負責和主庫創建一個普通的客戶端鏈接。若是該進程追遇上了主庫，它將進入睡眠狀態，直到主庫有新的事件產生通知它，他纔會被喚醒，將接收到的事件記錄到中繼日誌中。

3)、備庫的SQL線程執行最後一步，該線程從中繼日誌中讀取事件而且在備庫執行，當SQL線程遇上IO線程的時候，中繼日誌一般記錄在系統緩存中，因此中繼日誌的開銷很低。SQL線程也能夠根據配置選項來決定是否寫入其本身的二進制日誌中。

半同步複製

如何解決MySQL主庫宕機致使的數據丟失狀況？

使用半同步複製。在主庫commit以前，須要先將binlog同步到從庫，主庫能夠設置同步binlog的過時時間，在binlog複製到從庫以後，從庫後續會自行重放中繼日誌。不過這樣也增長了客戶端的延遲。另外這個須要安裝下MySQL的插件。

MySQL的半同步插件爲：semisync_xx.so

具體如何操做，參考我以前的博客：MySQL複製詳解

複製方式

基於GTID和日誌

• 日誌：傳統的方式，默認的方式。依賴二進制日誌，根據日誌的偏移量。事務不斷提交，二進制日誌的偏移量也會不斷的變化。須要從庫告訴主庫，本身明確複製到了偏移量的什麼位置。
• GTID: 全局事務ID，在一個集羣內的一個GTID是惟一的， GTID= source_id:transcation_id，source_id爲那一臺機器上的，slave增量複製還未同步的GTID便可。

基於日誌複製	基於GTID
兼容性好	與老版本不兼容
支持MMM與MHA架構	僅支持MHA架構
準備切換後很難找到新的同步點	基於事務ID複製，很方便的找到未完成的事務ID
能夠方便的跳過複製操做	只能經過置入空事務的方式跳過操做，會更復雜一點

建議優先使用GTID方式，能夠更安全的進行故障轉移。

主從複製延遲

產生延遲緣由？

• 主節點若是執行一個很大的事務(更新千萬行語句，總之執行很長時間的事務)，那麼就會對主從延遲產生較大的影響
• 網絡延遲，日誌較大，slave數量過多。
• 主上多線程寫入，從節點只有單線程恢復

處理辦法：

• 大事務：將大事務分爲小事務，分批更新數據。
• 減小Slave的數量，不要超過5個，減小單次事務的大小。
• MySQL 5.7以後，可使用多線程複製，使用MGR複製架構

參考

• MySQL複製詳解