[TOC] ## 概述 三種流行的變更復制算法：**單領導者（single leader）**，**多領導者（multi leader）**和**無領導者（leaderless）**。幾乎所有分布式數據庫都使用這三種方法之一 ## 領導者與追隨者 最常見的解決方案被稱為**基于領導者的復制（leader-based replication）**（也稱**主動/被動（active/passive）**或**主/從（master/slave）**復制） 1. 副本之一被指定為**領導者（leader）**，也稱為**主庫（master|primary）**。當客戶端要向數據庫寫入時，它必須將請求發送給**領導者**，領導者會將新數據寫入其本地存儲。 2. 其他副本被稱為**追隨者（followers）**，亦稱為**只讀副本（read replicas）**，**從庫（slaves）**，**備庫（ sencondaries）**，**熱備（hot-standby）**。每當領導者將新數據寫入本地存儲時，它也會將數據變更發送給所有的追隨者，稱之為**復制日志（replication log）**記錄或**變更流（change stream）**。每個跟隨者從領導者拉取日志，并相應更新其本地數據庫副本，方法是按照領導者處理的相同順序應用所有寫入。 3. 當客戶想要從數據庫中讀取數據時，它可以向領導者或追隨者查詢。 但只有領導者才能接受寫操作（從客戶端的角度來看從庫都是只讀的） ## 同步復制與異步復制 ? 復制系統的一個重要細節是：復制是**同步（synchronously）**發生還是**異步（asynchronously）**發生。 （在關系型數據庫中這通常是一個配置項，其他系統通常硬編碼為其中一個） **? 同步復制** 1. 優點: 從庫保證有與主庫一致的最新數據副本。如果主庫突然失效，我們可以確信這些數據仍然能在從庫上上找到。 2. 缺點: 如果同步從庫沒有響應（比如它已經崩潰，或者出現網絡故障，或其它任何原因），主庫就無法處理寫入操作。主庫必須阻止所有寫入，并等待同步副本再次可用 **半同步** 在數據庫上啟用同步復制，通常意味著其中**一個**跟隨者是同步的，而其他的則是異步的。如果同步從庫變得不可用或緩慢，則使一個異步從庫同步。這保證你至少在兩個節點上擁有最新的數據副本：主庫和同步從庫 ## 設置新從庫 有時候需要設置一個新的從庫：也許是為了增加副本的數量，或替換失敗的節點 1. 在某個時刻獲取主庫的一致性快照（如果可能），而不必鎖定整個數據庫。大多數數據庫都具有這個功能，因為它是備份必需的。對于某些場景，可能需要第三方工具，例如MySQL的innobackupex 【12】。 2. 將快照復制到新的從庫節點。 3. 從庫連接到主庫，并拉取快照之后發生的所有數據變更。這要求快照與主庫復制日志中的位置精確關聯。該位置有不同的名稱：例如，PostgreSQL將其稱為**日志序列號（log sequence number, LSN）**，MySQL將其稱為**二進制日志坐標（binlog coordinates）**。 4. 當從庫處理完快照之后積壓的數據變更，我們說它**趕上（caught up）**了主庫。現在它可以繼續處理主庫產生的數據變化了 ## 處理節點宕機 ### 從庫失效：追趕恢復 從庫可以從日志中知道，在發生故障之前處理的最后一個事務。因此，從庫可以連接到主庫，并請求在從庫斷開連接時發生的所有數據變更。當應用完所有這些變化后，它就趕上了主庫，并可以像以前一樣繼續接收數據變更流 ### 主庫失效：故障切換 ? 主庫失效處理起來相當棘手：其中一個從庫需要被提升為新的主庫，需要重新配置客戶端，以將它們的寫操作發送給新的主庫，其他從庫需要開始拉取來自新主庫的數據變更。這個過程被稱為**故障切換（failover）**。 ? 故障切換可以手動進行或自動進行。 自動故障切換過程 1. 確認主庫失效。有很多事情可能會出錯：崩潰，停電，網絡問題等等。沒有萬無一失的方法來檢測出現了什么問題，所以大多數系統只是簡單使用**超時（Timeout）**：節點頻繁地相互來回傳遞消息，并且如果一個節點在一段時間內（例如30秒）沒有響應，就認為它掛了（因為計劃內維護而故意關閉主庫不算）。 2. 選擇一個新的主庫。這可以通過選舉過程（主庫由剩余副本以多數選舉產生）來完成，或者可以由之前選定的**控制器節點（controller node）**來指定新的主庫。主庫的最佳人選通常是擁有舊主庫最新數據副本的從庫（最小化數據損失）。讓所有的節點同意一個新的領導者，是一個**共識**問題，。 3. 重新配置系統以啟用新的主庫。客戶端現在需要將它們的寫請求發送給新主庫。如果老領導回來，可能仍然認為自己是主庫，沒有意識到其他副本已經讓它下臺了。系統需要確保老領導認可新領導，成為一個從庫 ## 復制日志的實現 ### 基于語句的復制 存在的問題 * 任何調用**非確定性函數（nondeterministic）**的語句，可能會在每個副本上生成不同的值。例如，使用`NOW()`獲取當前日期時間，或使用`RAND()`獲取一個隨機數。 * 如果語句使用了**自增列（auto increment）**，或者依賴于數據庫中的現有數據（例如，`UPDATE ... WHERE <某些條件>`），則必須在每個副本上按照完全相同的順序執行它們，否則可能會產生不同的效果。當有多個并發執行的事務時，這可能成為一個限制。 * 有副作用的語句（例如，觸發器，存儲過程，用戶定義的函數）可能會在每個副本上產生不同的副作用，除非副作用是絕對確定的 的確有辦法繞開這些問題 ——例如，當語句被記錄時，主庫可以用固定的返回值替換任何不確定的函數調用，以便從庫獲得相同的值。但是由于邊緣情況實在太多了，現在通常會選擇其他的復制方法 ### 傳輸預寫式日志（WAL） * 對于日志結構存儲引擎，日志是主要的存儲位置。日志段在后臺壓縮，并進行垃圾回收。 * 對于覆寫單個磁盤塊的B樹，每次修改都會先寫入**預寫式日志（Write Ahead Log, WAL）**，以便崩潰后索引可以恢復到一個一致的狀態 ### 邏輯日志復制（基于行） 復制和存儲引擎使用不同的日志格式，這樣可以使復制日志從存儲引擎內部分離出來。這種復制日志被稱為邏輯日志，以將其與存儲引擎的（物理）數據表示區分開來 * 對于插入的行，日志包含所有列的新值。 * 對于刪除的行，日志包含足夠的信息來唯一標識已刪除的行。通常是主鍵，但是如果表上沒有主鍵，則需要記錄所有列的舊值。 * 對于更新的行，日志包含足夠的信息來唯一標識更新的行，以及所有列的新值（或至少所有已更改的列的新值） ### 基于觸發器的復制 ? 觸發器允許您注冊在數據庫系統中發生數據更改（寫入事務）時自動執行的自定義應用程序代碼。觸發器有機會將更改記錄到一個單獨的表中，使用外部程序讀取這個表，再加上任何業務邏輯處理，會后將數據變更復制到另一個系統去 ## 讀己之寫 如果用戶在寫入后馬上就查看數據，則新數據可能尚未到達副本。對用戶而言，看起來好像是剛提交的數據丟失了 在這種情況下，我們需要**讀寫一致性（read-after-write consistency）**，也稱為**讀己之寫一致性（read-your-writes consistency）**【24】 ## 單調讀 從異步從庫讀取第二個異常例子是，用戶可能會遇到**時光倒流（moving backward in time）**,首先查詢了一個延遲很小的從庫，然后是一個延遲較大的從庫 實現單調讀取的一種方式是確保每個用戶總是從同一個副本進行讀取（不同的用戶可以從不同的副本讀取） ## 多主復制 基于領導者的復制模型的自然延伸是允許多個節點接受寫入。 復制仍然以同樣的方式發生：處理寫入的每個節點都必須將該數據更改轉發給所有其他節點。 稱之為**多領導者配置**（也稱多主、多活復制） ## 需要離線操作的客戶端 ? 多主復制的另一種適用場景是：應用程序在斷網之后仍然需要繼續工作 ? 有一些工具旨在使這種多領導者配置更容易。例如，CouchDB就是為這種操作模式而設計的。 ## 協同編輯 ? 實時協作編輯應用程序允許多個人同時編輯文檔 如果要保證不會發生編輯沖突，則應用程序必須先取得文檔的鎖定，然后用戶才能對其進行編輯。如果另一個用戶想要編輯同一個文檔，他們首先必須等到第一個用戶提交修改并釋放鎖定。這種協作模式相當于在領導者上進行交易的單領導者復制