JPMorgan Chase 的 WePay 用的 MySQL 架構

看到「Highly Available MySQL Clusters at WePay」這篇講 WePayMySQL 的設計,本來以為是 WeChat 的服務,仔細看查了之後發現原來是 JPMorgan Chase 的服務...

架構在 GCP 上面,本來的 MySQL 是使用 MHA + HAProxy (patch 過的版本,允許動態改變 pool),然後用 Routes 處理 HAProxy 的 failover。

他們遇到的問題是 crash failover 需要至少 30 分鐘的切換時間,另外就是在 GCP 上面跨區時會有的 network partition 問題...

後續架構變得更複雜,讓人懷疑真的有解決問題嗎 XDDD

改用 GitHub 推出的 Orchestrator 架構,然後用兩層 HAProxy 導流 (一層放在 client side,另外一層是原來架構裡面的 load balancer),在加上用 Consul 更新 HAProxy 的資訊?

思考為什麼會有這樣設計 (考慮到金融體系的背景),其實還蠻有趣的...

AWS 上 MySQL + MHA、Galera Cluster、Amazon RDS for Aurora 的比較

Twitter 上看到的文章,對三套有 High Avaiilability 能力的 MySQL 系統比較:「AWS Aurora Benchmarking - Blast or Splash?」。

測試的項目包括了 MySQL + MHAGalera Cluster 以及 Amazon RDS for Aurora 三種,包括了 failover 的各種速度以及資料庫效能的比較。

測試的結果可以看到 Galera Cluster 有不少優勢,不過我必須說 Galera Cluster 並不好搞,初期要使用的話乾脆用 Aurora 就好,failover 的確是比較慢,而且效能也沒有 Galera Cluster 好,但管理上輕鬆很多啊...