- 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 的心得:
- Backup 分為 raw backup 和 logical backup, 各有利弊。若 file system 有支援 snapshot, 在 slave 上做 raw backup, 不管是執行時間還是占用的空間, 都挺划算的。切記要搭配 crash-safe 的方案, 如 MySQL + InnoDB。
- 針對 InnoDB 做 logical backup 的話, 用 XtraBackup 較快。
- 一定要測 restore, 我半信半疑的測了一下, 馬上發現少備份使用者帳號的 DB ......
參考資料
- LiveJournal's Backend: A history of scaling, 五年前的文章, 了解作者機器架構的轉變仍很有收獲
- MySQL 的 DRBD 與 MMM (1)
- MySQL HA
- MySQL (MyISAM) 的備份
- XtraBackup：線上備份 InnoDB 的好東西
- High performance mysql 2e (太厚了, 只讀了一部份)
你的解釋怪怪的，以 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 備份。
看起來我是以 Scale out, HA, backup 這三項「需求」為主, 說明那些「方法」可以滿足需求, 結果名詞用得有點亂。
回覆刪除你針對 replication (方法) 說明它能用來滿足那些需求。
來重寫看看