iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 21
1
AI & Data

資料工程師修煉之路系列 第 21

[Day 21] Replication (1) - Leaders and Followers

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

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

Leaders and Followers

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

figure_5-1

處理步驟為:

  1. 指定某一台 replica 為 Leader (也可稱 master 或 pimary,但 master 一詞現在應該要少用了XD),當 user 想要寫入資料時就寫到 Leader 中。
  2. 其他的 replica 為 Follower (也可稱 slave, replicas, secondaries),當 Leader 寫入資料時,Leader 同時也會通知 所有 Followers 它做了哪些變更,這些變更稱為 replication logchange 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 是非同步:

figure_5-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. 將這個 Folloer 連接到 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 恢復正常的時間。

明天繼續吧!


上一篇
[Day 20] Distributed Data
下一篇
[Day 22] Replication (2) - Problems with Replication Lag
系列文
資料工程師修煉之路30

尚未有邦友留言

立即登入留言