對於分散式資料庫的高可用性，
在前面【Day 3】分散式系統模型、容錯、高可用的後段已經提過衡量的標準、服務不能用等於$$$飛走等，
這篇整理 3 大可達成 HA 的 replication 架構：single-leader / multi-leader / leaderless
以及收集目前常見的 HA 實作（盡量啦，就還沒開始工作），也就是一些備援機制，以有個初步認識。

但還是比較著重於基礎知識，畢竟每個 HA 方案的實作都有大量的細節，
不太可能研究完或是能夠很簡單的分為一類。

本篇會使用 leader / follower 代替歧視性字眼

使用 leader follower 是為了與前面的分散式系統課程保持一致。
我會避免使用 Master Slave 等用詞，以支持這些正名運動。
何況我們有那麼多可以使用的替代詞！
雖然確實已經用習慣、行之有年，可能會有人說「幹嘛那麼敏感？」
但我希望多花一點心力，轉換成沒有歧視意味的用詞，讓這個世界多一分善意。
況且，會覺得沒關係的人，都只是剛好，過得太幸福而已。

1. single-leader

這邊定義 leader 為可被讀寫，
follower 只能提供讀。
leader 決定處理 write request 的順序，follower 跟隨 leader 的決定。
希望減少歧義。

synchronous vs asynchronous

一個 write request 傳給 leader 時：

• sync: 只有當 follower 都更新好回報 leader，leader 才跟 client 説這個請求成功

• async: leader 不等 follower 回報就跟 client 説這個請求成功
  顯而易見，sync 情況下，可以確保每個 follower 們都有最新的資料，但這不現實，
  畢竟如果 follower 數量一多，就可能要等很久。

• semi-synchronous：讓少數 follower synchronous 就好，如果其他 follower 發現自己不是最新的可以跟他們要。

replication 不一致會碰到的問題前面分散式系統的筆記都有提到，
有興趣建議多看看。

2. multi-leader

• 有多個 leaders 可接受 write request，再同步給其他節點
• 通常是在每個 data center 各自有一個 leader，在同 dc 就像只有一個 leader 一樣，但 leader 之間會做 replication。

concurrent write on different leaders?

問題在不同 leaders 出現衝突的時候，他們都已經告訴 client 寫入成功，這該怎麼解決？

• 從一開始就避免衝突（conflict avoidance）
  例如如果有兩個 clients 都在更動同份文件，就把他們分到同一個 dc
• 解決衝突
  參考 【Day 6】Replication

3. leaderless

• 沒有 leader，需使用 Quorum 來確保 client 讀寫到最新資料
  參考 【Day 7】Replica 的 Quorum 、State machine replication
• 並靠 read repair、anti-entropy 來保持 replicas 一致
  Day 7 也提過。

實例：Amazon Dynamo

MySQL HA 方案

沒用過的東西真的不太好寫..
主要參考：
常見的高可用MySQL資料庫解決方案
一文了解数据库高可用容灾方案的设计与实现

Heartbeat + 共享存儲（SAN/NAS）

• heartbeat 偵測到 leader 掛掉時，把共享的存儲設備掛載到備用機上
• 成本高、可能 split-brain

MySQL replication

• 注意名詞歧異，這裡代表 MySQL 的其中一種 HA 方式
• 主要也算 leader/follower，但 MySQL replication 同步的是 log，而 DRBD 是傳資料過去

希望沒理解錯

Heartbeat + DRBD

• Distributed Replicated Block Device（DRBD）：Linux 上的軟體，可以說是分散式系統中的 RAID 1，通常是一台 leader + 一台 follower，平常 leader 的更新會傳給 follower，只要 leader 掛了，就把服務轉到一直有在同步資料的 follower 上。
• heartbeat：確認節點還存活的機制，

MMM（通常做雙主架構）

• Master-Master Replication Manager for MySQL（MMM）
• 雙主架構：業界流行？兩台都可讀寫，互為 leader / follower。
• 聽說是比 DRBD 稍微新的技術

MySQL Cluster

• 設置麻煩？
• 目前理解應該是 leaderless