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主从配置原理_MySQL主从复制原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。