主從復制：其中一種設計，包括一個同步的從節(jié)點，和一個異步的從節(jié)點。

從節(jié)點2在接收復制日志之前有一段很長的延遲。通常情況下，復制速度會非常快，例如多數(shù)數(shù)據(jù)庫系統(tǒng)可以在一秒之內完成所有從節(jié)點的更新。但是，系統(tǒng)其實并沒有保證一定會在多長時間內完成復制。有些情況下，從節(jié)點可能落后主節(jié)點幾分鐘甚至更長時間，例如，由于從節(jié)點剛從故障中恢復，或者系統(tǒng)已經(jīng)接近最大設計上限，或者節(jié)點之間的網(wǎng)絡出現(xiàn)問題。

同步復制的優(yōu)點是：一旦向用戶確認，從節(jié)點可以明確保證完成了與主節(jié)點的更新同步，數(shù)據(jù)已經(jīng)處于最新版本。萬一主節(jié)點發(fā)生故障，總是可以在從節(jié)點繼續(xù)訪問最新數(shù)據(jù)。缺點則是：如果同步的從節(jié)點無法完成確認（例如：由于從節(jié)點發(fā)生崩潰，或者網(wǎng)絡故障，或任何其他原因），寫入就不能視為成功。主節(jié)點會阻塞其后所有的寫操作，直到同步副本確認已完成。

因此，把所有從節(jié)點都配置為同步復制有些不切實際。因為這樣子的話，任何一個同步節(jié)點的中斷都會導致整個系統(tǒng)更新停滯不前。**實踐中，如果數(shù)據(jù)庫啟用了同步復制，通常意味著其中某一個從節(jié)點是同步的，而其他節(jié)點這是異步模式。**萬一同步的從節(jié)點變得不可用或性能下降，則將另一個異步的從節(jié)點提升為同步模式。這樣可以保證至少有兩個節(jié)點（即主節(jié)點和一個同步從節(jié)點）擁有最新的數(shù)據(jù)副本。這種配置有時候也叫做半同步。

主從復制還經(jīng)常會被配置為全異步模式。此時如果主節(jié)點發(fā)生失敗且不可恢復，則所有尚未復制到從節(jié)點的寫請求都會丟失。這意味著即使向客戶端確認了寫操作，卻無法保證數(shù)據(jù)的持久化。但是全異步配置的優(yōu)點則是，不管從節(jié)點上數(shù)據(jù)多么滯后，主節(jié)點總是可以繼續(xù)響應寫請求，系統(tǒng)的吞吐性能更好、

異步模式這種弱化的持久性聽起來是一個非常不靠譜的折中設計，但是異步復制還是被廣泛使用，特別是那些從節(jié)點數(shù)量巨大或者分布于廣域地理環(huán)境。我們常見的問題，會有復制滯后問題

配置新的從節(jié)點：
當如果出現(xiàn)以下情況下，如需要增加副本數(shù)以提高容錯能力，或者替換失敗的副本，就需要考慮增加新的從節(jié)點。但是如何確保新的從節(jié)點和主節(jié)點保持數(shù)據(jù)一致呢？

簡單地將數(shù)據(jù)文件從一個節(jié)點復制到另一個節(jié)點通常是不夠的，主要是因為客戶端仍在不斷得向數(shù)據(jù)庫寫入新數(shù)據(jù)，數(shù)據(jù)始終處于不斷變化之中，因此常規(guī)的文件拷貝方式將會導致不同節(jié)點上呈現(xiàn)出不同時間點的數(shù)據(jù)，這不是我們所期待的。

或許應該考慮鎖定數(shù)據(jù)庫（使其不可寫）來使磁盤上的文件保持一致，但是這會違反高可用的設計目標。好在我們可以做到在不停機，數(shù)據(jù)服務不中斷的前提下完成從節(jié)點的設置。邏輯上的主要操作步驟如下：

在某個時間點對主節(jié)點的數(shù)據(jù)副本產(chǎn)生一個一致性的快照。這樣子避免長時間鎖定整個數(shù)據(jù)庫，爐前大多數(shù)數(shù)據(jù)庫都支持此功能，快照也是系統(tǒng)備份鎖必須的。而在某些情況下，可能需要第三方工具，入MYSQL的innobackupex

將此快照拷貝到新的從節(jié)點

從節(jié)點鏈接到主節(jié)點并請求快照點之后所發(fā)生的的數(shù)據(jù)更改日志；因為在第一步創(chuàng)建快照時候，快照與系統(tǒng)復制日志的某一個確定位置相關聯(lián)，這個位置信息在不同的系統(tǒng)中有不同的稱呼，

獲得日志之后，從節(jié)點來應用這些快找點之后所有數(shù)據(jù)變更，這個過程稱之為追趕。接下來，他可以繼續(xù)處理主節(jié)點上新的數(shù)據(jù)變化。并且重復步驟一~步驟4

從節(jié)點失效：追趕式恢復
主節(jié)點失效：節(jié)點切換

上述這些問題，包括節(jié)點失效，網(wǎng)絡不可靠，副本一致性，持久性，可用性與延遲之間各種細微的權衡，實際上正是分布式系統(tǒng)核心的基本問題。

基于行的邏輯日志復制 mySql
另一種方法就是復制和存儲引擎采用不同的日志格式，這樣復制與存儲邏輯剝離，這種復制日志稱為邏輯日志，用來區(qū)分物理存儲引擎的數(shù)據(jù)表示。

關系型數(shù)據(jù)庫的邏輯日志通常是指一系列記錄來描述數(shù)據(jù)表行級別的寫請求：

對于行插入，日志包含所有相關列的新值。

對于行刪除，日志里有足夠的信息來唯一標識已經(jīng)三處的行，通常是靠主鍵，但是如果表上沒有定義
主鍵，就需要記錄所有列的舊值
3.對于行更新，日志包含足夠的信息來唯一表示更新的行，以及所有列的新值（或者至少包含所有已經(jīng)更新列的新值）

如果一條事務設計多行的修改，則會產(chǎn)生多個這樣的日志記錄，并在后面跟著一條記錄，指出該事務已經(jīng)提交。Mysql的二進制日志binlog（當配置為基于行的復制時）使用該方式。

從節(jié)點最終會趕上并且與主節(jié)點保持一致，這種效應也被稱為最終一致性。正常情況下，主節(jié)點和從節(jié)點上完成寫操作之間的時間延遲（復制滯后）可能不足1秒，這樣子的滯后，在實踐中中通常不會導致太大的影響。但是，如果系統(tǒng)已經(jīng)接近設計上線，或者網(wǎng)絡存在問題，則滯后可能輕松增加到幾秒甚至幾分鐘不等。

離線客戶端操作：
另一種多主復制比較適合的場景是：應用在于網(wǎng)絡斷開后還需要繼續(xù)工作。

總結

以上是生活随笔為你收集整理的同步复制与异步复制的全部內容，希望文章能夠幫你解決所遇到的問題。

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