2010年12月22日 星期三

Scale out, HA, backup

Scale out、high availability、backup 三者是不同的事, 之前對這幾個詞很陌生, 備忘一下它們的差別。
  • Replication 可以同時 scale out 讀取的操作和當作讀取的 HA, 但不是 backup。舉例來說, 不小心刪錯資料, slave 上的資料也一起飛了。所以 backup 要另外做。
  • Replication 無法保證寫入的 HA, 因為 master 和 slave 之間會因延遲同步而少資料。
  • 針對寫入操作的 HA, DRBD 看起來是最穩且易於實作的 方案。但 DRBD 沒有附帶 scale out, 備份機就是待機狀態。
  • MMM 可用作寫入的 HA, 備份機可充當讀取的 replication。
  • Sharding (partition) 用來 scale out 寫入的操作, 沒包含 HA。
結論是 backup 要分開規劃, scale out 和 HA 也要分開規劃。寫入量不大的話, 可以先用 replication 擋著。反之, 要用 sharding 來 scale out, 用 DRBD 或 MMM 做 HA。

順便記一下 backup 的心得:
  • Backup 分為 raw backup 和 logical backup, 各有利弊。若 file system 有支援 snapshot, 在 slave 上做 raw backup, 不管是執行時間還是占用的空間, 都挺划算的。切記要搭配 crash-safe 的方案, 如 MySQL + InnoDB。
  • 針對 InnoDB 做 logical backup 的話, 用 XtraBackup 較快。
  • 一定要測 restore, 我半信半疑的測了一下, 馬上發現少備份使用者帳號的 DB ......
大概有個概念了, 接下來先做 replication 和 backup, 將 DB 操作包在自己寫的 lib 裡, 待需要 scale out 時比較好套。之後有更深的需求再來細讀吧。

參考資料

2 則留言:

  1. 你的解釋怪怪的,以 MySQL 來解釋...

    replication 只是一個技術,他會因為不同的場景有不同的變化。

    在 R(Read) >> W(Write) 的情況下,replication 可以當作 scale out 的手段,爭取 refactor & shading 的時間。

    replication 也是 Master-Master HA 架構中重要的技術之一,利用 replication 可以同步資料。

    replication 也是 non-stoppable backup 需要的技術之一,利用 replication 可以跑 slave server 起來,在 slave server 上利用 snapshot 與 binlog 備份。

    回覆刪除
  2. 看起來我是以 Scale out, HA, backup 這三項「需求」為主, 說明那些「方法」可以滿足需求, 結果名詞用得有點亂。

    你針對 replication (方法) 說明它能用來滿足那些需求。

    來重寫看看

    回覆刪除

在 Fedora 下裝 id-utils

Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...