異步復制

MySQL的復制默認是異步的，主從復制至少需要兩個MYSQL服務，這些MySQL服務可以分布在不同的服務器上，也可以在同一臺服務器上。

MySQL主從異步復制是最常見的復制場景。數(shù)據(jù)的完整性依賴于主庫BINLOG的不丟失，只要主庫的BINLOG不丟失，那么就算主庫宕機了，我們還可以通過BINLOG把丟失的部分數(shù)據(jù)通過手工同步到從庫上去。

注意：主庫宕機的情況下，DBA可以通過mysqlbinlog工具手工訪問主庫binlog，抽取缺失的日志并同步到從庫上去；也可以通過配置高可用MHA架構來自動抽取缺失的數(shù)據(jù)補全從庫，或者啟用Global Transaction Identifiers（GTID)來自動抽取缺失binlog到從庫。

MySQL在BINLOG中記錄事務(或SQL語句),也就是說對于支持事務的的引擎(例如InnoDB)來說，每個事務提交時都需要寫B(tài)INLOG；對于不支持事務的引擎(例如MyISAM)來說，每個SQL語句執(zhí)行完成時，都需要些BINLOG。為了保證Binlog的安全，MySQL引入sync_binlog參數(shù)來控制BINLOG刷新到磁盤的頻率。

show variables like 'sync_binlog';

• 在默認情況下，sync_binlog=1，表示事務提交之前，MySQL都需要先把BINLOG刷新到磁盤，這樣的話，即使出現(xiàn)數(shù)據(jù)庫主機操作系統(tǒng)崩潰或者主機突然掉電的情況，系統(tǒng)最多損失prepared狀態(tài)的事務；設置sync_binlog=1，盡可能保證數(shù)據(jù)安全。
• sync_binlog=0,表示MySQL不控制binlog的刷新，由文件系統(tǒng)自己控制文件緩存的刷新。
• sync_binlog=N,如果N不等于0或者1，刷新方式同sync_binlog=1類似，只不過此時會延長刷新頻率至N次binlog提交組之后。
  

以上是傳統(tǒng)的異步復制，在MySQL5.7的并行復制技術(也稱多線程復制)到來之前，為人詬病最多的還是效率問題，slave延遲是一個頑疾，雖然之前已經出現(xiàn)了schema級別的并行復制，但實際效果并不好。

多線程復制

在MySQL5.7中，帶來了全新的多線程復制技術，解決了當master同一個schema下的數(shù)據(jù)發(fā)生了變更，從庫不能并發(fā)應用的問題，同時也真正將binlog組提交的優(yōu)勢充分發(fā)揮出來，保障了從庫并發(fā)應用Relay Log的能力。

在MySQL8.0中，多線程復制又進行了技術更新，引入了writeset的概念，而在之前的版本中，如果主庫的同一個會話順序執(zhí)行多個不同相關對象的事務，例如，先執(zhí)行了Update A表的數(shù)據(jù)，又執(zhí)行了Update B表的數(shù)據(jù)，那么BINLOG在復制到從庫后，這兩個事務是不能并行執(zhí)行的，writeset的到來，突破了這個限制。

增強半同步復制

前面介紹的復制是異步操作，主庫和從庫的數(shù)據(jù)之間難免會存在一定的延遲，這樣存在一個隱患：當在主庫上寫入一個事務并提交成功，而從庫尚未得到主庫的BINLOG日志時，主庫由于磁盤損壞、內存故障、斷電等原因意外宕機，導致主庫上該事務BINLOG丟失，此時從庫就會損失這個事務，從而造成主從不一致。

為了解決這個問題，從MySQL5.5開始，引入了半同步復制，此時的技術暫且稱之為傳統(tǒng)的半同步復制，因該技術發(fā)展到MySQL5.7后，已經演變?yōu)樵鰪姲胪綇椭?也成為無損復制)。在異步復制時，主庫執(zhí)行Commit提交操作并寫入BINLOG日志后即可成功返回客戶端，無需等待BINLOG日志傳送給從庫，如圖所示。

而半同步復制時，為了保證主庫上的每一個BINLOG事務都能夠被可靠地復制到從庫上，主庫在每次事務成功提交時，并不及時反饋給前端應用用戶，而是等待至少一個從庫(詳見參數(shù)rpl_semi_sync_master_wait_for_slave_count)也接收到BINLOG事務并成功寫入中繼日志后，主庫才返回Commit操作成功給客戶端(不管是傳統(tǒng)的半同步復制，還是增強的半同步復制，目的都是一樣的，只不過兩種方式有一個席位地方不同，將在下面說明)

半同步復制保證了事務成功提交后，至少有兩份日志記錄，一份在主庫的BINLOG日志上，另一份在至少一個從庫的中繼日志Relay Log上，從而更進一步保證了數(shù)據(jù)的完整性。

在傳統(tǒng)的半同步復制中，主庫寫數(shù)據(jù)到BINLOG，且執(zhí)行Commit操作后，會一直等待從庫的ACK，即從庫寫入Relay Log后，并將數(shù)據(jù)落盤，返回給主庫消息，通知主庫可以返回前端應用操作成功，這樣會出現(xiàn)一個問題，就是實際上主庫已經將該事務Commit到了事務引擎層，應用已經可以可以看到數(shù)據(jù)發(fā)生了變化，只是在等待返回而已，如果此時主庫宕機，有可能從庫還沒能寫入Relay Log，就會發(fā)生主從庫不一致。增強半同步復制就是為了解決這個問題，做了微調，即主庫寫數(shù)據(jù)到BINLOG后，就開始等待從庫的應答ACK，直到至少一個從庫寫入Relay Log后，并將數(shù)據(jù)落盤，然后返回給主庫消息，通知主庫可以執(zhí)行Commit操作，然后主庫開始提交到事務引擎層，應用此時可以看到數(shù)據(jù)發(fā)生了變化。增強半同步復制的大致流程如下圖所示。

半同步復制模式下，假如在傳送BINLOG日志到從庫時，從庫宕機或者網絡延遲，導致BINLOG并沒有即使地傳送到從庫上，此時主庫上的事務會等待一段時間(時間長短由參數(shù)rpl_semi_sync_master_timeout設置的毫秒數(shù)決定)，如果BINLOG在這段時間內都無法成功發(fā)送到從庫上，則MySQL自動調整復制為異步模式，事務正常返回提交結果給客戶端。

半同步復制很大程度上取決于主從庫之間的網絡情況，往返時延RTT越小決定了從庫的實時性越好。通俗地說，主從庫之間的網絡越快，從庫約實時。

注意：往返時延RTT(Round-Trip Time)在計算機網絡中是一個重要的性能指標，它表示從發(fā)送端發(fā)送數(shù)據(jù)開始到發(fā)送端接收到接收端的確認，總共經歷的時長(這里可能有點拗口，我們可以理解為TCP三次握手的前兩次握手)。

總結

到此這篇關于關于MySQL主從復制的文章就介紹到這了,更多相關MySQL主從復制方式內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！