分散式資料庫—複製

為了讓資料庫備份、高可用性、低延時。

文本於此

為什麼

擴增性
高可用性（高容錯性）
低潛時

借鏡單台機器。

擴增性：放更多 CPU/Memory/Disk
容錯性：即時置換（hot-swappable）
共享磁碟（shared-disk）的架構

分散式資料庫

中文	統一	其他
單一領袖	leader/follower	master/slave(standby), active/passive, primary/secondary
多領袖	multi-leader	master/master, active/active
無領袖	leaderless	dynamo-style

複製日誌

複製日誌的類型比較

前面提了很多領袖把資料轉到追隨者時會遇到的問題和權衡。但是都沒提他怎麼把資料轉到追隨者的。基本上有三種：

透過輸入的語法（SQL、MapReduce等等）直接複製到其他資料庫。好處是這種方式通常很簡單實作而且傳遞的資料通常很小。5.1 版前的 MySQL 和特定情況下的 VoltDB 都會使用這方式。其帶來的問題：
- 非常數的資料的傳遞，例如 NOW()、RAND()、AUTO_INCR() 等等。
- 若資料是有限制條件的，例如 WHERE <some condition>，則會要求所有資料庫狀態都是一致的，否則很容易因為狀態不一致導致執行結果不一樣。
- 資料庫在更新資料時會有很多其他被影響的資料，例如觸發器（trigger）、貯存程序（stored procedure）、參考鍵（reference key）。導致執行結果可能一樣但是資料庫的整體狀態卻不一致
第二種方式是直接使用 WAL。前面在討論索引的時候有提到兩種儲存方式：日誌結構和頁導向。日誌結構本來就有在維持日誌並持續在背景執行整合壓縮，頁導向則是利用 WAL 保證資料不會被遺失。我們就可以透過這些日誌的資料進行傳遞。PostgreSQL 和 Oracle 等多個資料庫都使用這方式。不過會有些問題：
- 通常日誌的資料都很細，甚至細到哪個磁碟的哪個 byte 會塞哪些資料。這導致複製日誌的資料不能在不同版本的資料格式間使用，進而增加維運的困難度。
邏輯日誌介於上述兩種方式的中間，不會像語法那樣抽象，但又不會細到像 WAL 那樣。例如語法是 UPDATE users SET age = age + 10 WHERE age < 10 則可能傳遞更新的使用者 ID 和其更新後的資料。使用這方式的有 MySQL 的 binlog。除此之外，他也方便透過 ETL 等方式製作其他衍生資料。
額外補充一種，有可能在傳遞資料時會希望有個中介器幫助我們加上一些客制的商務邏輯修正，例如加密、特定資料的修正和處理衝突等等。這時可以使用 Oracle 的 GoldenGate。你也可以透過觸發器和貯存程序把資料匯進其他表格（table）中來達成一樣的事情。例如 Oracle 的 Databus 和 Postgres 的 Bucardo。這些方法雖然可以增加很多彈性，但是通常容易有錯（因為涉及到應用程式邏輯和資料庫邏輯間的轉換）而且會增加資料庫的負擔。