Eventbrite 的 MySQL 升級計畫

在 2021 年看到 EventbiteMySQL 升級計畫:「MySQL High Availability at Eventbrite」。

看起來是 2019 年年初的時候 MySQL 5.1 出問題,後續決定安排升級,在 2019 年年中把系統升級到 MySQL 5.7 (Percona Server 版本):

Our first major hurdle was to get current with our version of MySQL. In July, 2019 we completed the MySQL 5.1 to MySQL 5.7 (v5.7.19-17-log Percona Server to be precise) upgrade across all MySQL instances.

然後看起來是直接在 EC2 上跑,不過這邊提到的空間問題就不太確定了,是真的把 EBS 的空間上限用完嗎?比較常使用的 gp2gp3 上限都是 16TB,不確定是不是真的用到接近爆掉了:

Not only was support for MySQL 5.1 at End-of-Life (more than 5 years ago) but our MySQL 5.1 instances on EC2/AWS had limited storage and we were scheduled to run out of space at the end of July. Our backs were up against the wall and we had to deliver!

另外在升級到 5.7 的時候,順便把本來是 INT 的 primary key 都換成 BIGINT

As part of the cut-over to MySQL 5.7, we also took the opportunity to bake in a number of improvements. We converted all primary key columns from INT to BIGINT to prevent hitting MAX value.

然後系統因為舊版的 Django 沒辦法配合 MySQL 5.7,得升級到 Django 1.6 (要注意 Django 1 系列的最新版是 1.11,看起來光是升級到 1.6 勉強會動就升不上去了?):

In parallel with the MySQL 5.7 upgrade we also Upgraded Django to 1.6 due a behavioral change in MySQL 5.7 related to how transactions/commits were handled for SELECT statements. This behavior change was resulting in errors with older version of Python/Django running on MySQL 5.7

然後採用了 GitHub 家研發的 gh-ost 當作改變 schema 的工具:

In December 2019, the Eventbrite DBRE successfully implemented a table ALTER via gh-ost on one of our larger MySQL tables.

看起來主要的原因是有遇到 pt-online-schema-change 的限制 (在「GitHub 發展出來的 ALTER TABLE 方式」這邊有提到):

Eventbrite had traditionally used pt-online-schema-change (pt-osc) to ALTER MySQL tables in production. pt-osc uses MySQL triggers to move data from the original to the “duplicate” table which is a very expensive operation and can cause replication lag. Matter of fact, it had directly resulted in several outages in H1 of 2019 due to replication lag or breakage.

另外一個引入的技術是 Orchestrator,看起來是先跟 HAProxy 搭配,不過他們打算要再換到 ProxySQL

Next on the list was implementing improvements to MySQL high availability and automatic failover using Orchestrator. In February of 2020 we implemented a new HAProxy layer in front of all DB clusters and we released Orchestrator to production!

Orchestrator can successfully detect the primary failure and promote a new primary. The goal was to implement Orchestrator with HAProxy first and then eventually move to Orchestrator with ProxySQL.

然後最後題到了 Square 研發的 Shift,把 gh-ost 包裝起來變成有個 web UI 可以操作:

2021 還可以看到這類文章還蠻有趣的...

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 的資訊?

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

HAProxy 1.8 多了好多東西...

雖然大家都在用 nginx,但 HAProxy 還是在努力:「What’s New in HAProxy 1.8」。

這個版本多了好多東西...

  • 支援 HTTP/2。(終於...)
  • Multithreading 架構。(health check 總算是一隻了 XD 不會開八隻就打八次...)
  • DNS 的 Service Discovery。
  • TLS 1.3 0-RTT。(居然支援了...)

有種突然醒過來的感覺...

HAProxy 1.6 的兩個大功能:Quote 以及 Lua

HAProxy 1.6.0 出版的公告文章:「[ANNOUNCE] HAProxy 1.6.0 released」。

兩個大功能,第一個是「It’s 2015, let’s use QUOTE in configuration file」,可以用引號了... 另外一個是「Lua Scripting」,需要 Lua 5.3+。

還有提到一些改進,像是支援 SNI,以及對 HTTP/2 的計畫。

Mozilla 提供了 SSL/TLS 設定懶人包

MozillaMozilla SSL Configuration Generator 提供了各種 server side 的設定:

以及不同等級的設定 (Modern、Intermediate、Old),另外還有 HSTS 的選項可以選擇。

對於 security 的東西我不是很喜歡用 generator (因為我覺得既然是資安相關的東西,要盡可能知道每個細節),但算是一種推廣吧,看了一下設定也都還算合理...

Percona XtraDB Cluster 上用 keepalived 實作高可靠度架構

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

Galera Cluster + Heartbeat

我一向不太喜歡 Galera Cluster + HAProxy 的設計。有四個理由:

  • MySQL server 看不到 client 的 IP。
  • HAProxy 本身就是 SPoF。
  • HAProxy 會增加 latency,並且限制 bandwidth。
  • 通常需要額外的機器跑 HAProxy。

我把跑了超過半年的 Galera Cluster + Heartbeat 的經驗貼到 Codership 的 Group 上,裡面包括了設定與 script,希望能有些迴響:「HA solution - Galera Cluster with Heartbeat」。