论坛徽章:: 0

发表于 2009-03-12 07:57 |显示全部楼层

http://blog.gslin.org/archives/2009/03/11/1969/

「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，不然會受限於記憶體可定址空間。

评分

参与人数 1	可用积分 +3	收起理由
枫影谁用了	+ 3	我很赞同

查看全部评分

文库|博客

sshnuke

家境小康

论坛徽章:: 0

发表于 2009-03-12 07:58 |显示全部楼层

MySQL HA

http://blog.gslin.org/archives/2009/03/12/1971/

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。

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

sshnuke

家境小康

论坛徽章:: 0

发表于 2009-03-12 07:58 |显示全部楼层

MySQL HA 與 Slave 的關係

http://blog.gslin.org/archives/2009/03/12/1972/

上面一篇「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 又找到自己寫的文章…