這幾天講的主軸是 Replication (數據複製)，如果你的資料不會變動，做到 Replication 很簡單，只要把資料複製到別的節點就好了，搞定！

但資料可是會時時刻刻改變，所以這就是 Replication 的難處，處理改變後的副本資料，我們之後會詳細討論以下 3 種常見處理資料改變的方法：leader-base, multi-leader 和 leaderless 。

Leaders and Followers

每一個 node (節點) 中儲存的資料庫複製資料稱為 replica ，在多台機器都有 replica 的情況下，我們要如何確保每一份 replica 都是最新的？每一次的資料庫寫入都應該在每份 replica 中也處理一次，否則 replica 的資料會不一樣；首先先來介紹一個很常見且又簡單的方法：leader-base replication (也可稱 master-slave replication)，如下圖：

處理步驟為：

1. 指定某一台 replica 為 Leader (也可稱 master 或 primary，但 master 一詞現在應該要少用了XD)，當 user 想要寫入資料時就寫到 Leader 中。
2. 其他的 replica 為 Follower (也可稱 slave, replicas, secondaries)，當 Leader 寫入資料時，Leader 同時也會通知 所有 Followers 它做了哪些變更，這些變更稱為 replication log 或 change stream，每一個 Follower 取得這些 log 後就更新自己的資料。
3. 當 user 想要查詢資料時，他可以選擇查詢 Leader 或任一 Follower，Leader 為 read-write，Follower 為 read-only 。

這個 Replication 模式已內建在許多 relational 資料庫中，像 PostgreSQL、MySQL、Oracle Data Guard 等等。

Synchronous Versus Asynchronous Replication (同步 v.s. 非同步 replication)

同步和非同步主要的差別如下圖，Follower 1 是同步，Follower 2 是非同步：

可以看到最大的差別就是 response time 的高低，同步就是需要每個 Follower 都回 Ok 後才會回覆 request 端，非同步就是通知 Follower 後就不等回覆了。

同步的好處是能確保所有 Followers 的資料都是最新的，壞處就是當 Follower 未回覆時 (可能是網路、Follower 掛掉或其他原因)，Leader 的寫入會等待，然後卡到後面其他的寫入。

非同步的好處就是不怕 Follower 爛掉，但就不能確保資料是最新。

還有一種是 semi-synchronous ，也就是只有一台 Follower 是同步，其他 Followers 為非同步，如此起碼會有 2 台的資料都是最新，然後也不怕對 Leader 影響太大。

Setting Up New Followers

這裡來看看 leader-base 要怎麼加入新的 Follower 後，又能確保新 Follower 的資料是一致的，因為我們是 high availability (高可用性) 的系統，所以沒有 downtime 才是我們的重點！做法如下：

1. 取得 Leader 資料庫 某個時間點 的 snapshot (快照)。
2. 複製該 snapshot 到新的 Follower。
3. 將這個 Follower 連接到 Leader 上，然後開始處理所有在 某個時間點 之後的資料變更。
4. 當 Follower 積累的資料都變更完成後，稱為 caught up ，此時就可以對外服務了。

Handling Node Outages

節點掛掉時怎辦？如何在 leader-based replication 方法維持 high availability (高可用性)？我們來分 2 個面向看。

Follower failure: Catch-up recovery

Follower 掛掉時很單純，在 log 裡，每筆資料都有時間戳記，Follower 只要向 Leader 請求某個時間戳記後的所有資料變更就好了，直到該 Follower caught up 。

Leader failure: Failover

Leader 掛掉就比較有趣了，首先要從所有的 Followers 裡選出一個 Follower 當新的 Leader，然後 user 需重新設定新的 Leader，其他的 Follower 也改為向新 Leader 做資料變更，通常這個 process 稱為 Failover ，整個 Failover 的處理步驟如下：

1. 檢查 Leader 是否掛掉：

   當節點超過一定秒數後還未回覆，可視為死去。

2. 選一個新的 Leader：

   這裡有許多種選新 Leader 的方法，最好的方法為挑一個資料最新的 replica 當 Leader，讓資料遺失降到最小。

3. 重設系統設定檔：

   主要是讓相關系統知道新 Leader 誕生了，如果舊的 Leader 恢復，要能確保舊 Leader 能變成 Follower。

然而，Failover 也可能會遇到下述幾個問題：

• 如果是非同步做 Replication，新 Leader replica 中的資料可能不是最新，可能會造成資料遺失。
• 在某些情形下可能會有 2 個節點都說自己是 Leader，因為是 leader-base 架構，所以不會有 process 解決資料衝突的問題。
• 什麼樣的 timeout 才是合理的？若設太短可能會造成無謂的 failover (假設流量忽然提高，然後各 service 會多花一些時間處理)，設太長又會影響該 Leader 恢復正常的時間。

明天繼續吧！