2009年5月10日 星期日
2009年5月1日 星期五
MySQL HA 與 Slave 的關係
上面一篇「MySQL HA」其實是要提 Mark Callaghan 所寫的「Global transaction IDs are hot」這篇文章。
在三種架構下,DRBD + Heartbeat 的系統要加掛 slave 是最容易的,因為 master server 雖然跳動,但 replication 位置不會變。
在 Master-Master 架構下,由於兩台 master 都有自己的 binlog,會使得 master 跳動時 slave 產生問題,也就是在 Mark Callaghan 文章裡所寫的三種解法 “switch and hope”、”check and lose”、”check and fix”。
這三種解法都並沒有很完滿的解決問題 (第三種解法雖然看起來有 “fix”,但是透過工人智慧手動解決)。
一種方法是引入 Global transactions IDs,這是由 Google 提出的 patch:「MySQL Hierarchical Replication & Global Group IDs」,對 binlog 每筆 transaction 都加上一組 64bits 且遞增的數字,這樣 slave 就不會受到 master 切換而產生 replication err。
先記錄下來,之後很有可能會透過 Google 又找到自己寫的文章…
Update:看到「High Availability for MySQL: Considering the Options」這篇文章,要如何做 HA。
選擇 MySQL 用的硬體
「5 Minute DBA – Database Server Hardware Selection」講了一些幫資料庫選擇硬體的方式,其實是偏向 MySQL…
簡單的說,CPU 超過 8 CPU 其實意義不大,不需要買 4*4core 或是 4*6core,因為 MySQL 目前無法利用到。
記憶體愈大愈好,記憶體現在便宜許多,如果有 I/O bound 的問題,除了改寫程式外,直接把記憶體加到 32GB 或是 64GB 通常是最划算的方法。
硬碟愈快愈好,有 Hardware RAID10 (要有電池) 會比軟體的 RAID10 好,不過這主要看需求,如果是 CPU bound 的應用,說不定 SATA 硬碟就夠用?
網卡請務必用 GigabitEthernet,最好是 bounding/trunking,除了增加 thoughput 外,也可以當作 redundant link。然後作業系統一定要選 64bits,不然會受限於記憶體可定址空間。
MySQL HA
MySQL 有幾種不同的方法實做 High Availability 架構:
- Master-Slave Replication,當 master 當掉時,將 slave 提昇為 master。
- DRBD + Heartbeat,透過網路對 Disk 層 RAID1,平常只有一台會 mount 並跑 mysql,當掉時會跳到另外一台。
- Master-Master Replication,當其中一台當掉時直接到另外一台使用。
這三種方法各有不同的缺點,舉例來說:
- Master-Slave Replication:master 當掉時可能有 transaction 已經寫入,但尚未被送到 slave 而造成不同步。
- DRBD + Heartbeat:當備援機跳起來時,記憶體內都還沒有 cache,會造成剛跑起來時 MySQL I/O bound,有時候叫做 “warm up problem”。
- Master-Master Replication:query 會有 race condition (同時在 db1 下
DELETE FROM table1;
,以及在 db2 下INSERT INTO table1 SET col1=1;
,有可能最後在 db1 上有資料,但在 db2 上沒有資料),這點可以用把寫入固定到某一台而避免,但由於也是 replication 類的架構,也會遇到 Master-Slave Replication 所敘述的問題。
由於資料的正確性會比其他的因素重要,現在我還是偏好用 DRBD + Heartbeat。因 query 的特性而不會有 query dependency 問題的系統才會用 Master-Master。