MySql中主從復制機制的原理是什么

今天就跟大家聊聊有關MySql中主從復制機制的原理是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

主從復制機制

MySQL基于binlog實現主從復制，從節點跟蹤并獲取主節點binlog中最新更新并在自身進行重放，從而實現復制主節點數據。

下圖是MySQL主從復制過程的示意圖。在整個過程中涉及三個線程，他們的職責分別是：

• 主節點binlog dump線程：該線程在從節點連接上主節點后創建，負責向從節點發送binlog中新寫入的數據。在讀取binlog時，dump線程會首先獲取binlog的鎖，并在讀取完畢后立刻釋放，然后將讀取到的數據發送至從節點。

• 從節點I/O線程：從節點I/O線程職責為向主節點發送數據同步的請求，接收主節點發送的數據并將其寫入relay-log。

• 從節點SQL線程：該線程從relay-log中讀取數據更新并進行重放。

異步復制

默認情況下，MySQL的主從復制是異步復制，在這種機制下，主節點會在完成本地日志寫入后立刻響應客戶端的請求，從節點的數據復制過程異步執行。

很明顯，在這種機制下面，由于復制過程并不會影響主節點對客戶端請求的響應，因此，相比于單節點，并不會造成整體性能上的明顯損失。

但是，在這種機制下面，如果數據在主節點完成提交而未同步至從節點時主節點宕機，此時如果發生主從切換并寫入新的數據，可能導致數據丟失或不一致。

半同步復制（semisynchronous replication）

從5.6版本開始，MySQL支持半同步復制，這種機制與異步復制相比主要有如下區別：

主節點在收到客戶端的請求后，必須在完成本節點日志寫入的同時，還需要等待至少一個從節點完成數據同步的響應之后（或超時），才會響應請求。

從節點只有在寫入relay-log并完成刷盤之后，才會向主節點響應。

當從節點響應超時時，主節點會將同步機制退化為異步復制。在至少一個從節點恢復，并完成數據追趕后，主節點會將同步機制恢復為半同步復制。

可以看出，相比于異步復制，半同步復制在一定程度上提高了數據的可用性，在未退化至異步復制時，如果主節點宕機，此時數據已復制至至少一臺從節點。

同時，由于向客戶端響應時需要從節點完成響應，相比于異步復制，此時多出了主從節點上網絡交互的耗時以及從節點寫文件并刷盤的耗時，因此整體上集群對于客戶端的響應性能表現必然有所降低。

主從復制格式

由于MySQL的復制機制是基于binlog的，因此binlog的格式就決定了主從復制的格式。binlog有基于行的和基于語句兩種，從而復制也有兩種對應的格式。

Statement-Based Replication(SBR)

對于基于語句的復制機制，binlog僅記錄所執行的語句。這種方式，有如下優點：

• 自從3.23版本就存在，經過長期驗證的成熟技術

• 寫入日志文件的數據更少，這意味著更少的文件寫入和網絡傳輸消耗，從而整體上可以更快的完成主從復制，提升性能表現。

• 日志文件記錄了所有數據庫上執行的語句，可以用來進行審計等用途
  

有如下缺點：

• 用戶自定義函數(UDF)以及執行結果不確定的函數無法進行復制

• 進行數據更新時，需要比基于行的復制更多的行鎖

• 對于如先插入后更新式的復雜語句，從節點需要進行完全的對應重放，而基于行格式的復制只需要執行最終結果即可
  

Row-Based Replication(RBR)

基于行的復制機制下，對應binlog也是基于行的，這時每次數據更新當寫入binlog時，都被轉化所有受影響行的變化。

這種復制方式，有如下優點：

• 所有數據變化都可以被安全的復制，不會受到UDF以及特殊函數的影響。

• 大部分DBMS都采用這種復制方式，知識遷移成本低。

• 進行數據更新時，所需要的行鎖更少，從而可以獲取更高的性能表現。
  

有如下缺點：

• 在涉及大數據量的DML時，基于行的日志將會產生大量的日志數據，大數據量在日志文件寫入、網絡傳輸方面都意味著更長的時間，從而可能導致整體性能表現顯著變差，同時也可能導致并發問題。

• 無法通過日志查看所執行的語句，同時也無法獲知從節點上執行的語句。
  

看完上述內容，你們對MySql中主從復制機制的原理是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。