幹壞事是進步最大的原動力
Percona 發了一篇「High-availability options for MySQL, October 2013 update」，比較目前 MySQL 上常見的 High Availability 機制。
包括了五個系統：
這些都是把 High Availability 做在 MySQL 上，讓前端的程式不需要操心的方式。都是有個固定的 IP address 保證可以讀寫。
這五個方案都不完美，看環境需求而選擇使用。
我一般給的建議還是 Heartbeat + DRBD + InnoDB，這個方法是極為成熟的方法，會遇到的問題網路上都已經討論過了。如果找 Percona 的人支援也是完全沒問題。
Percona 的人寫了一篇「Using keepalived for HA on top of Percona XtraDB Cluster」，是用 Keepalived 實作高可靠度架構。
目前常見的文章是透過 HAProxy 達成，但 HAProxy 本身就會成為 SPOF，所以一般人的想法就是在 HAProxy 上跑 Keepalived，保持可靠度。但這個問題我之前就抱怨過，既然要跑 Keepalived (我的例子裡是 Heartbeat)，為什麼不在 Percona XtraDB Cluster 上跑就好，load balance 的任務則可以透過 DNS round robin 達成：
We would standardly use keepalived to HA HAproxy, and keepalived supports track_scripts that can monitor whatever we want, so why not just monitor PXC directly?
不過我還是偏愛 Heartbeat，因為 Heartbeat 的功能多了一些，不過架構還是很簡單，實際用起來也發現不容易出問題。
另外 Heartbeat 不論是在 Linux 還是 FreeBSD 上都跑得很好，我連內部機器用的 DNS resolver (跑 Unboound) 都上 Heartbeat。
另外也因為 Keepalived 目前不支援 FreeBSD (參考「About "ipvs" and "keepalived"」這篇文章)，所以也沒打算花時間測試了... :o
pfSense 是一套很不錯的 firewall 以及 NAT 服務，上面還可以跑一切服務 (像是 OpenVPN 或是 Squid)，不過後來都是用商用的硬體方案來處理...
看到「Build your own pro-grade firewall」這篇突然想到要查 pfSense 是否可以 High Availability，如果做的夠好的話，其實可以用兩台機器來跑，成本相對低很多。
結果查到這篇官方文件「Configuring pfSense Hardware Redundancy (CARP)」，裡面有幾個關鍵字，像是 XMLRPC Sync 似乎暗示了設定也可以同步？
該測試看看了，兩台 server 也才十萬，但兩台能跑到 500Mbps+ 的硬體防火牆的價錢就貴多了... (不過比較省電？)
Percona 把常見的 MySQL High Availability 選擇整理後發表成 Webinar，投影片在這裡可以看到 (以及下載)：「Choosing a MySQL High Availability Solution」。
沒有太多新的東西，主要還是再次描述 MySQL HA 這塊目前沒有萬靈丹，常見的這幾個方案各有自己的優缺點，會依照環境與需求而產生不同的選擇。裡面連 manual failover + 24x7 NOC 都出現了... XD
對於不清楚有哪些 HA 架構的人，可以透過這份投影片先抓出關鍵字。對於聽過一堆 HA 架構的人，想要複習各種方式的優缺點，也可以花時間看看。至於想要找萬靈丹的人就不用花時間了，目前沒這東西 :p
我一向不太喜歡 Galera Cluster + HAProxy 的設計。有四個理由：
我把跑了超過半年的 Galera Cluster + Heartbeat 的經驗貼到 Codership 的 Group 上，裡面包括了設定與 script，希望能有些迴響：「HA solution - Galera Cluster with Heartbeat」。
看到 AWS 推出新的 EC2 instance：「EC2 for In-Memory Computing - The High Memory Cluster Eight Extra Large Instance」，看完這個 instance 的規格笑了出來 XDDD
120GB SSD 兩顆 (所以是 240GB)，加上 244GB RAM，結果記憶體比 SSD 空間大，應用程式一定得分層利用... XDDD
Colin Percival 開了台 FreeBSD 9.1 起來測試，可以順便看到一些硬體資訊。
目前還沒有 Reserved Instances 可以買，所以依照目前的價錢 USD$3.50/hour，一年大約是 90 萬新台幣，而這金額差不多可以直接買一台了... 所以這個 instance 的定位是在非長期的大量運算？不過依照 AWS 的慣例，過陣子應該還是會出 Reserved Instances 讓需要的人買...
不過這也是目前記憶體最多的機器，如果下次看到有文章寫「因為資料超過 244GB，所以資料庫效能炸掉」的訊息，就知道發生什麼事情了 XDDD
Chaos Monkey 是 Netflix 丟出來的工具，這個工具的目的是希望建立超高可靠度的系統。方法則是沒事就亂關 AWS 上的 instance：「Chaos Monkey released into the wild」。
基本的想法是這樣：
照 Netflix 的說法，他們不僅在開發環境測試，也在正式環境測試。利用 Chaos Monkey 看看 failure 的結果是否如預期。
Netflix 甚至建議可以排成每個上班日都隨機跑一跑：
The service has a configurable schedule that, by default, runs on non-holiday weekdays between 9am and 3pm.
只有在爆炸機率超高的系統上，設計師才會在意 failure 的問題...