MySql主從復制機制全面解析

作為一個關系型數(shù)據(jù)庫，MySQL內(nèi)建地提供數(shù)據(jù)復制機制，這使得在使用時，可以基于其復制機制實現(xiàn)高可用架構等高級特性，從而使得MySQL無需借助額外的插件或其他工具就具備適用于生產(chǎn)環(huán)境。這是MySQL得到大面積實際應用的條件之一。

基于MySQL的復制機制，不僅可以實現(xiàn)數(shù)據(jù)庫的高可用，還能實現(xiàn)如：性能擴展、異地災備以及冷熱分離等高級特性。

• 高可用：通過配置一定的復制機制，MySQL實現(xiàn)了跨主機的數(shù)據(jù)復制，從而獲得一定的高可用能力，如果需要獲得更高的可用性，只需要配置多個副本，或者進行級聯(lián)復制就可以達到目的。
• 性能擴展：由于復制機制提供了多個數(shù)據(jù)備份，在讀寫一致性要求不高的場景下，可以通過配置一個或多個副本，將讀請求分發(fā)至副本節(jié)點，從而獲得整體上讀寫性能的提升。
• 異地災備：只需要將副本節(jié)點部署到異地機房，就可以輕松獲得一定的異地災備能力。實際當中，需要考慮網(wǎng)絡延遲等可能影響整體表現(xiàn)的因素。
• 交易分離：通過配置復制機制，并將低頻、大運算量的交易發(fā)送至副本節(jié)點執(zhí)行，就可以避免這些交易與高頻交易競爭運算資源，從而避免整體的性能問題。

為了獲得上述能力，需要了解基本的MySQL復制機制，并結合實際應用場景選擇恰當?shù)呐渲谩?/p>

主從復制機制

MySQL基于binlog實現(xiàn)主從復制，從節(jié)點跟蹤并獲取主節(jié)點binlog中最新更新并在自身進行重放，從而實現(xiàn)復制主節(jié)點數(shù)據(jù)。

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

• 主節(jié)點binlog dump線程：該線程在從節(jié)點連接上主節(jié)點后創(chuàng)建，負責向從節(jié)點發(fā)送binlog中新寫入的數(shù)據(jù)。在讀取binlog時，dump線程會首先獲取binlog的鎖，并在讀取完畢后立刻釋放，然后將讀取到的數(shù)據(jù)發(fā)送至從節(jié)點。
• 從節(jié)點I/O線程：從節(jié)點I/O線程職責為向主節(jié)點發(fā)送數(shù)據(jù)同步的請求，接收主節(jié)點發(fā)送的數(shù)據(jù)并將其寫入relay-log。
• 從節(jié)點SQL線程：該線程從relay-log中讀取數(shù)據(jù)更新并進行重放。

異步復制

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

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

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

半同步復制（semisynchronous replication）

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

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

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

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

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

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

主從復制格式

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

Statement-Based Replication(SBR)

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

• 自從3.23版本就存在，經(jīng)過長期驗證的成熟技術
• 寫入日志文件的數(shù)據(jù)更少，這意味著更少的文件寫入和網(wǎng)絡傳輸消耗，從而整體上可以更快的完成主從復制，提升性能表現(xiàn)。
• 日志文件記錄了所有數(shù)據(jù)庫上執(zhí)行的語句，可以用來進行審計等用途
  

有如下缺點：

• 用戶自定義函數(shù)(UDF)以及執(zhí)行結果不確定的函數(shù)無法進行復制
• 進行數(shù)據(jù)更新時，需要比基于行的復制更多的行鎖
• 對于如先插入后更新式的復雜語句，從節(jié)點需要進行完全的對應重放，而基于行格式的復制只需要執(zhí)行最終結果即可
  

Row-Based Replication(RBR)

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

這種復制方式，有如下優(yōu)點：

• 所有數(shù)據(jù)變化都可以被安全的復制，不會受到UDF以及特殊函數(shù)的影響。
• 大部分DBMS都采用這種復制方式，知識遷移成本低。
• 進行數(shù)據(jù)更新時，所需要的行鎖更少，從而可以獲取更高的性能表現(xiàn)。
  

有如下缺點：

• 在涉及大數(shù)據(jù)量的DML時，基于行的日志將會產(chǎn)生大量的日志數(shù)據(jù)，大數(shù)據(jù)量在日志文件寫入、網(wǎng)絡傳輸方面都意味著更長的時間，從而可能導致整體性能表現(xiàn)顯著變差，同時也可能導致并發(fā)問題。
• 無法通過日志查看所執(zhí)行的語句，同時也無法獲知從節(jié)點上執(zhí)行的語句。
  

在實際的架構應用中，需要根據(jù)系統(tǒng)的業(yè)務特點合理利用主從復制機制，并選擇合適主從復制格式。

以上就是MySql主從復制機制全面解析的詳細內(nèi)容，更多關于MySql主從復制機制的資料請關注腳本之家其它相關文章！