非同步複製
MySQL的複製預設是非同步的，主從複製至少需要兩個MYSQL服務，這些MySQL服務可以分佈在不同的伺服器上，也可以在同一臺伺服器上。
MySQL主從非同步複製是最常見的複製場景。資料的完整性依賴於主庫BINLOG的不丟失，只要主庫的BINLOG不丟失，那麼就算主庫當機了，我們還可以通過BINLOG把丟失的部分資料通過手工同步到從庫上去。
注意：主庫當機的情況下，DBA可以通過mysqlbinlog工具手工訪問主庫binlog，抽取缺失的日誌並同步到從庫上去；也可以通過配置高可用MHA架構來自動抽取缺失的資料補全從庫，或者啟用Global Transaction Identifiers（GTID)來自動抽取缺失binlog到從庫。
MySQL在BINLOG中記錄事務(或SQL語句),也就是說對於支援事務的的引擎(例如InnoDB)來說，每個事務提交時都需要寫BINLOG；對於不支援事務的引擎(例如MyISAM)來說，每個SQL語句執行完成時，都需要些BINLOG。為了保證Binlog的安全，MySQL引入sync_binlog引數來控制BINLOG重新整理到磁碟的頻率。
show variables like 'sync_binlog';
- 在預設情況下，sync_binlog=1，表示事務提交之前，MySQL都需要先把BINLOG重新整理到磁碟，這樣的話，即使出現資料庫主機作業系統崩潰或者主機突然掉電的情況，系統最多損失prepared狀態的事務；設定sync_binlog=1，儘可能保證資料安全。
- sync_binlog=0,表示MySQL不控制binlog的重新整理，由檔案系統自己控制檔案快取的重新整理。
- sync_binlog=N,如果N不等於0或者1，重新整理方式同sync_binlog=1類似，只不過此時會延長重新整理頻率至N次binlog提交組之後。
以上是傳統的非同步複製，在MySQL5.7的並行複製技術(也稱多執行緒複製)到來之前，為人詬病最多的還是效率問題，slave延遲是一個頑疾，雖然之前已經出現了schema級別的並行複製，但實際效果並不好。
多執行緒複製
在MySQL5.7中，帶來了全新的多執行緒複製技術，解決了當master同一個schema下的資料發生了變更，從庫不能併發應用的問題，同事也真正將binlog組提交的優勢充分發揮出來，保障了從庫併發應用Relay Log的能力。
在MySQL8.0中，多執行緒複製又進行了技術更新，引入了writeset的概念，而在之前的版本中，如果主庫的同一個會話順序執行多個不同相關物件的事務，例如，先執行了Update A表的資料，又執行了Update B表的資料，那麼BINLOG在複製到從庫後，這兩個事務是不能並行執行的，writeset的到來，突破了這個限制。
增強半同步複製
前面介紹的複製是非同步操作，主庫和從庫的資料之間難免會存在一定的延遲，這樣存在一個隱患：當在主庫上寫入一個事務並提交成功，而從庫尚未得到主庫的BINLOG日誌時，主庫由於磁碟損壞、記憶體故障、斷電等原因意外當機，導致主庫上該事務BINLOG丟失，此時從庫就會損失這個事務，從而造成主從不一致。
為了解決這個問題，從MySQL5.5開始，引入了半同步複製，此時的技術暫且稱之為傳統的半同步複製，因該技術發展到MySQL5.7後，已經演變為增強半同步複製(也成為無損複製)。在非同步複製時，主庫執行Commit提交操作並寫入BINLOG日誌後即可成功返回客戶端，無需等待BINLOG日誌傳送給從庫，如圖所示。
而半同步複製時，為了保證主庫上的每一個BINLOG事務都能夠被可靠地複製到從庫上，主庫在每次事務成功提交時，並不及時反饋給前端應用使用者，而是等待至少一個從庫(詳見引數rpl_semi_sync_master_wait_for_slave_count)也接收到BINLOG事務併成功寫入中繼日誌後，主庫才返回Commit操作成功給客戶端(不管是傳統的半同步複製，還是增強的半同步複製，目的都是一樣的，只不過兩種方式有一個席位地方不同，將在下面說明)
半同步複製保證了事務成功提交後，至少有兩份日誌記錄，一份在主庫的BINLOG日誌上，另一份在至少一個從庫的中繼日誌Relay Log上，從而更進一步保證了資料的完整性。
在傳統的半同步複製中，主庫寫資料到BINLOG，且執行Commit操作後，會一直等待從庫的ACK，即從庫寫入Relay Log後，並將資料落盤，返回給主庫訊息，通知主庫可以返回前端應用操作成功，這樣會出現一個問題，就是實際上主庫已經將該事務Commit到了事務引擎層，應用已經可以可以看到資料發生了變化，只是在等待返回而已，如果此時主庫當機，有可能從庫還沒能寫入Relay Log，就會發生主從庫不一致。增強半同步複製就是為了解決這個問題，做了微調，即主庫寫資料到BINLOG後，就開始等待從庫的應答ACK，直到至少一個從庫寫入Relay Log後，並將資料落盤，然後返回給主庫訊息，通知主庫可以執行Commit操作，然後主庫開始提交到事務引擎層，應用此時可以看到資料發生了變化。增強半同步複製的大致流程如下圖所示。
半同步複製模式下，假如在傳送BINLOG日誌到從庫時，從庫當機或者網路延遲，導致BINLOG並沒有即使地傳送到從庫上，此時主庫上的事務會等待一段時間(時間長短由引數rpl_semi_sync_master_timeout設定的毫秒數決定)，如果BINLOG在這段時間內都無法成功傳送到從庫上，則MySQL自動調整複製為非同步模式，事務正常返回提交結果給客戶端。
半同步複製很大程度上取決於主從庫之間的網路情況，往返時延RTT越小決定了從庫的實時性越好。通俗地說，主從庫之間的網路越快，從庫約實時。
注意：往返時延RTT(Round-Trip Time)在計算機網路中是一個重要的效能指標，它表示從傳送端傳送資料開始到傳送端接收到接收端的確認，總共經歷的時長(這裡可能有點拗口，我們可以理解為三次握手的前兩次握手)。
轉載請註明原文連結：https://www.cnblogs.com/itbsl/p/13507401.html
如果該文章對您有幫助，請您點選推薦，感謝。