·

1.管理其他副本的節點稱為Follower。每當Leader將新數據寫入本地存儲d的副本時，也會將數據更改寫入日志之中。每個Follower會從Leader那里獲取修改日志，并相應地更新數據到的本地副本之中，這樣，所有的在Follower上副本的修改順序會和Leader保持相同的順序。

·

1.當客戶端需要從系統之中讀取數據時，它可以查詢Leader或其他Follower。(注：Follower與Leader之中的數據存在延遲，無法保證強一致性)寫入請求只能由Leader來響應，或是由Follower轉發給Leader。

許多關系數據庫在同步副本時使用這樣的機制，如PostgreSQL，MySQL，Oracle Data Guard 和SQL Server。同時許多非關系型數據庫與分布式消息隊列也采用這樣的機制，包括MongoDB，Rethinkd，Kafka，RabbitMQ。

在副本進行主從復制時一個重要細節是復制是同步還是異步發生的?(在關系數據庫中，這往往是一個可配置的選項。在其他系統之中，如Ceph，是系統默認的)

由上圖可知，同步復制有相當大的延遲，而異步復制的響應相當快速。但是異步復制卻不能保證完成所需要多長時間。有些情況下，Follower的數據可能比Leader上的數據落后幾分鐘或更多。如:節點之間存在網絡問題或節點的故障恢復。如果Leader失敗且不可恢復，則尚未復制到Follower的任何寫操作都將丟失。

而同步復制的優點是保證了Follower與Leader之間的副本一致性，一旦任意一個Leader失效了，任何一個Follower的數據都與Leader相同。但是同步復制一旦出現網絡或節點的故障，會導致無法處理寫入。Leader必須阻止所有寫入并等待Follow上的副本再次可用。如果所有的Follower都是同步復制，那么任何一個節點的中斷都會導致整個系統癱瘓。在實際運用之中，如果在數據庫上啟用同步復制，通常其中一個副本是同步復制的，而另一個是異步復制的。如果同步的副本變得不可用或十分緩慢，可以將同步操作切換到另一個異步副本之中。這樣保證了至少兩個節點上有一個數據的最新副本：Leader和一個同步Follower。這種配置稱之為半同步。(鏈式復制也是類似于半同步的一種復制機制，不丟失數據但仍能提供良好性能和可用性的復制方法。)

有時我們需要添加新的Follower來增加副本的數量，或者替換失敗的節點。此時就需要確保新的Follower擁有一個正確的副本的數據。僅僅將數據文件從一個節點復制到另一個節點通常是不夠的：客戶端不停向系統寫入數據，所以數據副本總是處于不斷變化的狀態。這里可以簡單地通過鎖定系統，使其拒絕客戶端的寫請求來使各個副本上保持一致，但這樣會大大降低系統的可用性。所以我們需要一個不停機的方式來添加新的Follower：

·1.在某個時間點對Leader的副本進行快照，并且將快照復制到新加入的Follower節點。

·2 .Follower連接到Leader，并向Leader請求快照之后所有的數據更改。通常是Leader節點的日志序列號。

·

1.當Follower處理完快照之后的數據更改之后，它就可以正常處理來自Leader的數據更改了。

在分布式系統之中，任何節點都可能出現故障，而能夠在不停機的情況下重新啟動單個節點是操作和維護是十分必要的。盡管每個節點故障，但我們需要讓一個節點停機的影響盡可能小。

·Follower故障

在Follower的本地磁盤上，都保存著從Leader收到的數據更改的日志。當一個Follower崩潰并重新啟動，或者Leader與Follower之間的網絡暫時中斷。Follower可從它的日志找到故障發生之前處理的最后一個事務，然后連接到Leader并請求在Follower斷開連接的時候發生的所有數據變化。(這個流程和添加新的Follower其實是同樣的思路)

·Leader故障

在處理Leader的失敗時顯然會更為棘手：其中一個Follower需要被提升為新的Leader，客戶端也需要識別并且將后續的請求發送給新的Leader，而其他的Follower則需要開始在新Leader之下工作。處理Leader故障通常是如下的流程:

·1、確認Leader失效。絕大多數系統使用超時機制：如果一個節點不響應一段時間，例如，30秒，它被認為是失效了。(如果是中心化的系統可以采用Lease機制。筆者在碩士生階段對Cassandra數據庫有過系統的調研，在Cassandra中采用了由日本學者Naohiro Hayashibara提出的《The Phi Accrual Failure Detector》失敗探測算法，通過多維度累積量來判斷節點是否失效，不失為一個好的解決方案，十分適合類P2P架構的分布式系統)

·2、選取新的Leader。在中心化架構之中，如HDFS，新的Leader可以用中心化節點指定。而在非中心化的架構之中，則可以通過選舉過程來完成，分布式系統之中的選舉協議有很多：2PC，3PC，Paxos，Raft等等。

·3、調整系統配置以使用新的Leader。如果舊的Leader回歸到集群，它可能仍然認為自己是Leader，這時需要確保舊的Leader成為Follower并承認新的Leader。

如果是異步復制的場景，新的Leader可能舊的Leader之前的完整的寫入信息。最常見的解決方案是丟棄舊Leader之前寫入多于新Leader的信息丟棄，但是這顯然違反了數據系統寫入持久性的要求。

在某些故障場景中，可能會出現兩個節點都認為他們是Leader，這種情況被稱為腦裂。此時兩個Leader都會接受寫請求，數據很可能會出現丟失或損壞。

什么時候進行故障切換也是一個值得探討的問題：較長的超時時間意味著在Leader失效的情況下恢復時間更長。然而，如果時間太短，可能會有不必要的故障轉移。例如，臨時負載高峰時刻可能導致節點的響應時間增加到超時，那么不必要的故障轉移會使情況變得更糟，而不是更好。為此，一些運營團隊更愿意執行手動的故障轉移，即使系統本身支持自動的故障轉移。

日志在副本的一致性之中是至關重要的，所以我們接下來簡要的梳理一下日志復制可用的方法：

·Statement-Based復制

在最簡單的情況下，Leader將每個寫請求通過日志的形式發送給Follower。每個Follower解析和執行對應的操作語句，雖然這聽起來很合理，但是實際操作中會存在一些坑：

(1)非確定性函數，如now()獲得當前的日期和時間或rand()得到一個隨機數，這樣會導致副本之間的不一致。(這里可以轉換思維，用一個確定的修改值，來替換不確定性的函數調用)

(2)如果使用一個自動遞增的列，或如果他們依賴于數據庫中的現有數據(例如，更新…在條件)，他們必須執行完全相同的順序在每個副本，否則也會產生不一致性。(異步轉發，亂序到達。這個可以通過操作序列號等強制要求進行規避。)

(3)有副作用的語句(例如觸發器、存儲過程、用戶定義函數)可能會導致每個副本上出現不同的副作用。

·Write-ahead日志復制

日志是一個只包含所有寫入操作的字節序列。我們可以使用完全相同的日志來在另一個節點上構建一個副本。Leader將日志寫入磁盤之后，將它通過網絡發送給Follower。當Follower處理這個日志時，它構建了一個與Leader完全相同的數據結構的副本。這種方式的缺點是：日志在非常低的級別上描述數據。這使得數據拷貝與存儲引擎緊密耦合。

·Row-based日志復制

Row-based與Write-ahead的方法類似，但是它允許復制日志與存儲引擎內部分離。這種日志稱為邏輯日志，邏輯日志通常是描述在一個行的粒度上記錄寫入操作：

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

對于已刪除的行，日志包含足夠的信息以唯一地標識刪除的行。(主鍵)

對于更新的行，日志包含足夠的信息以唯一地標識更新的行，以及所有列的新值。

由于邏輯日志與存儲引擎內部分離，因此可以更容易地保持向后兼容，從而允許Leader與Follower運行不同版本的數據系統，甚至是不同的存儲引擎。同時，邏輯日志格式對外部應用程序也更容易解析。可以將邏輯日志的內容發送到外部系統(如用于離線分析的數據倉庫)，或者用于構建自定義索引和緩存。

副本可以增加系統的可伸縮性(處理比單個機器處理更多的請求)和降低延遲(將副本放置在離用戶更近的地方)。寫入操作必須通過Leader副本，但是只讀查詢可以在任何副本上進行。對于一次寫入，多次讀取的應用來說，采用讀擴展架構是十分合理的。但是由于上文提及的原因，我們通常不會采用同步復制的方式。這將導致數據出現明顯的不一致性：如果您同時對Leader和Follwer執行相同的查詢，可能會得到不同的結果，因為并不是所有的寫入實時在Follower上反饋。這種不一致性僅僅是暫時狀態，所以這種情況被稱為最終一致性。