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複製架構