Percona XtraDB Cluster (PXC) 的感想

看到「Percona XtraDB Cluster 是 MySQL 的叢集與分散式解決方案」這篇,裡面提到了 Percona 包的 Galera Cluster,叫 Percona XtraDB Cluster

Percona 算是把 Galera Cluster 包的比較好的 distribution,是還蠻建議直接用他們家的版本。另外我記得 MariaDB 也有包一個版本,叫做 MariaDB Galera Cluster

這篇算是很早期使用 PXC 的人的一些感想:(大概是 2012 年導入,當年雲端也還沒流行,在地端上面自己建,對應的 MySQL 底層還是 5.5 的年代)

Percona XtraDB Cluster 建議至少三台

Galera Cluster 的三台可以是兩台有資料的,加上一台沒有資料,這台沒資料的只負責投票組成 quorum,不需要到三台都是大機器,而且這樣的配置也比較單純一點。

另外兩台雖然都可以當 writer 寫入,但實務上會建議都集中在一台寫,這樣可以大幅降低跨機器時產生的 lock contention。

基於上面這個因素,將兩台有資料的機器,一台做 writer,另外一台做 reader 算是常見的架構,然後把可以接受些許 replication lag 的應用 (像是什麼 BI 專用 DB server) 用傳統的 MySQL logical replication 掛出去 (標準的 master-slave 架構,或是後來政治改名為 source-replica 架構),不要直接參與 Galera Cluster 協定。

(MySQL 5.5 的時候還得自己處理當 master/source 切換時 replication binlog position 的問題,現在有 GUID 後會好一些)

除了 Galera Cluster 外,另外一種方式 (也是比較傳統的方式) 是 active-standby 的方式跑 DRBD:因為 DRBD 可以在兩台機器的 block 層做 mirror,所以切換的時候另外一台機器只要跑 journaling filesystem recovery (像是當年比較流行的 XFS 或是後來主力的 ext4) + InnoDB recovery 就可以跑起來。

DRBD 的老方法架構很單純,維護成本也很低,但缺點就是 recovery 的時間會高一些:在 crash 的 case 下可以做到十分鐘的 downtime 切換 (在傳統磁頭硬碟組成的 RAID),而 Galera Cluster 因為等於是 hot-standby,蠻容易就可以做到小於 30 秒。

另外在切換後 warmup 的時間上,Galera Cluster 也是因為 hot-standby 大勝:DRBD 這邊的情境等於是 cold start,資料庫內還有很多東西還沒進到 InnoDB buffer,對應的 SQL query 還不會快。

相比起來 Galera Cluster 看起來是個好東西,但後面運作的機制複雜不少 (而且需要有人維護),公司如果有專門的 DBOps 會比較好...

不過現在 SSD 變成主流的情況,讀取速度與 random access 的效率都快很多,這使得 DRBD 切換的成本低很多了,很有機會整個 downtime (切換 + warmup) 是五分鐘內搞定,如果這個時間是可以接受的,用 Galera Cluster 的優點可能就沒那麼高了...

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 還可以看到這類文章還蠻有趣的...

在家裡 (???) 建立 HA 的網路環境...

Brad Fitzpatrick 在他家裡弄的 HA 架構,對一般人來說是有點誇張了 (看起來主要還是玩得開心),但對網路公司來說是個可以參考的方式,降低網路與設備故障帶來的業務衝擊... 先前在弄辦公室連外網路時也有弄過類似的架構,還蠻有趣的。

然後發現原來西雅圖的電這麼便宜,一度大約 NTD$3:

The whole setup including all APs and switches draws about 220 watts idle. Power is pretty cheap in Seattle. Washington State (as of April 2018) has the cheapest electricity in the United States, at $0.0974/kWh.

其他技術的東西反而是看看而已 XD

DigitalOcean 提供 Floating IP 功能

DigitalOcean 推出的新功能,可以註冊 IP 並且動態掛到某個 droplet 上:「Floating IPs: Start Architecting Your Applications for High Availability」。

如果沒有掛到 droplet 上會收取 USD$0.006/hour 的費用,以一個月 720 小時來計算,大約是 USD$4.32/month。另外也限制在同一個 data center 內才能換來換去。

類似的功能在 Linode 很久前就有了 (2007 年底),雖然不是完全一樣:「Support for High Availability / IP Failover」,但 Amazon EC2 的 Elastic IP 功能幾乎就相同了,在 2008 年初開放:「New EC2 Features: Static IP Addresses, Availability Zones, and User Selectable Kernels」,所以只能算是補產品線,把大家都有的功能實作出來...

以往只能用 DNS 做 High Availability 的,現在可以用這種方法做,使得 downtime 可以更低。另外這樣做也可以架設 proxy server,使得對外的 IP 不變,讓 firewall 設定變得單純。

Oracle 對 MySQL HA 方案的介紹

Oracle 的 Andrew Morgan 前幾天辦了場 Webinar,投影片以及一些說明有放出來讓大家事後可以參考:「Choosing the right MySQL High Availability Solution – webinar replay」。

其中第七頁的開頭「Don’t assume 99.999% HA needed for all apps」這句帶出了一個重點:99.999% 的每一個九都是成本,而且不是可以簡單帶過去的成本。

第八頁與第九頁給出了不同 HA 層級中的每個方案 (要注意到這是以 Oracle 的觀點來看),至於最後面將近五十頁的產品介紹看看就好... XD

建立 Amazon VPC 的 High Availability NAT 架構

Amazon VPC 的架構裡最讓人碎碎唸的一個架構:NAT instance。

Amazon VPC 分成 Public Network 與 Private Network。

前者的 Public Network,裡面的機器除了會有 Private IP 外,需要申請 Public IP (可以是隨機分配,也可以是 Elastic IP) 透過 Intenet Gateway (沒有 NAT 功能) 連外,這邊問題比較小,因為 Routing Table 設一下就好了,High Availability 以及 Scalablility 的問題 AWS 會自己解決掉。

後者 Private Network 因為需要自己架設 NAT instance,所以要自己處理 High Availability 以及 Scalability 問題,由於把機器丟在後面,前面用 ELB 是蠻常見的架構,AWS 一直沒推出 NAT service 讓人感覺很疑惑...

目前一般在處理 Private Network 的 HA NAT 架構是參考「High Availability for Amazon VPC NAT Instances: An Example」這篇文章,但這篇文章的作法有點複雜。

我可以接受有一些 downtime 時間以及一些小狀況,相對的,我想要換取極低的管理成本。

研究了一陣子,最後決定的作法是受到「An Alternative Approach to “HA” NAT on AWS」這篇的啟發,這篇也只講了很簡單的概念,實際上還是要自己研究。

目前是做在 us-west-2 (Oregon) 的 1b 與 1c 兩個 AZ 上。下面討論時就不說明這點了。

規劃的想法是 1b 與 1c 兩個 AZ 各建立一個 auto scaling group,透過 auto scaling 各跑一台 NAT instance 處理自己 AZ 的 NAT traffic (所以不是手動跑)。然後我不想要自己建 image 寫太多 hard code 進去,最好是現成的用一用就好 XD

所以有幾個重點:

  • NAT instance 拿現成的 amzn-ami-vpc-nat 使用,寫這篇文章時是用 2014.09 版。
  • 由於官方的 NAT instance 支援 userdata 在開機時執行指令,所以完全透過 userdata 指定需要的做動就好。
  • 由於 Amazon 官方給的 instance 有 aws 這隻工具 (aws-cli),而這隻工具在有掛上 IAM Role 時會去 http://169.254.169.254/ 上取得對應的 IAM Role 權限,所以都不需要寫太多 hard code 的東西進去。

機器開起來以後希望做幾件事情:

  • 把自己的 Source/Destination IP check 關閉。
  • 把傳進來的 Route Table 的 0.0.0.0/8 設成自己。這邊需要傳進來是由於 NAT instance 是跑在 Public Network 裡,我不會知道要改哪個 Route Table。

所以就有兩個重點,一個是 userdata,其中粗體是要修改的 route table id:

#!/bin/bash
ROUTE_TABLE_ID=rtb-1a2b3c4d
INSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)
aws ec2 modify-instance-attribute \
    --region us-west-2 \
    --instance-id "${INSTANCE_ID}" \
    --no-source-dest-check
aws ec2 replace-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}" || \
aws ec2 create-route \
    --region us-west-2 \
    --route-table-id "${ROUTE_TABLE_ID}" \
    --destination-cidr-block 0.0.0.0/0 \
    --instance-id "${INSTANCE_ID}"

最前面事先抓 instance_id,然後修改 Source/Destination 檢查,最後面的指令是先試著 ReplaceRoute,如果失敗就 CreateRoute (注意到 shell 的 || 操作)。

另外的重點是 IAM Role,這台機器對應的 IAM Role 權限要開三個:

{
  "Statement": [
    {
      "Action": [
        "ec2:CreateRoute",
        "ec2:ReplaceRoute",
        "ec2:ModifyInstanceAttribute"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

拿 t2.medium 測試,burst 可以到 200Mbps 左右,應該還算夠用?反正不夠用就自己挑其他機器開吧 XD

最後討論一下 Availability 的情況。這樣的架構可能會有七八分鐘的 downtime,也就是當 instance 掛了,被 auto scaling 重新拉一台新的起來。這邊不做 cross-zone NAT 是因為這樣比較簡單,這邊的 downtime 我還可以接受。

至於某個 zone 掛掉,應該 cross-zone NAT 趕快導到另外一區的問題... 整個 zone 都滅了就沒有這個問題啊 XDDD

vCenter 的 HA 機制

在「vCenter is Still a Single Point of Failure」這篇文章裡面討論了 VMware vCenter 的 HA (High Availability) 問題。可以包括 comment 一起看,看到文章裡火氣還蠻大的...

文章後面有提到 VMware vCenter 並沒有辦法提供很高等級的 HA 機制,雖然官方提出來的 downtime 是五分鐘內,不過作者顯然對這點很不同意:

I can guarantee you that will take a hell of a lot longer than 5 minutes.

而下面 comment 有人提到至少是 20mins:

After reboot the first 20min CPU is high and vCenter Services is unable to start. 1000 VMs, 60 hosts. VM has 4 vCPU en 21GB RAM.

不過這設定看起來像是 60 台 host,每一台 384GB RAM,裡面每個 VM 都有 21GB RAM?這種環境真不錯... 不過如果量這麼大,我大概會自己弄 KVM 起來建環境?

Anyway,有用過 vCenter 的人看完這篇文章大概都有種「...」不知道要怎麼說的感覺 XD

Facebook 的 mcrouter

這也不知道積了多久,九月 Facebook 的文章,最近被同事提起來才又仔細看:「Introducing mcrouter: A memcached protocol router for scaling memcached deployments」。

memcached 應該當作普通的 cache layer 來用,拿來放掉了也沒關係的資料。如果掉了會很痛的資料應該丟到 Redis 或是 MySQL 這類 persistent storage。

但有些資料介於兩者之間,掉了會讓使用者用起來不太爽,但也不會死人... 於是總是想要在這上面做些改善。

Facebook 開發的 mcrouter 就可以拿來解這類問題。其中一個 scenario 是「寫的不多,但讀德很多」,寫的時候寫到所有機器上,但讀取時只挑一台:

而這個架構其實可以配合用在 memcached 的 HA 機制上。當有機器爛掉重開機變成空的 cache server 回來時可以暖機:

不過程式看起來並不好編,要先搞定 Facebook 的兩個 C++ 的套件後才能編...

Percona 的 MySQL High Availability 機制比較文

Percona 發了一篇「High-availability options for MySQL, October 2013 update」,比較目前 MySQL 上常見的 High Availability 機制。

包括了五個系統:

  • Percona XtraDB Cluster (PXC)
  • Percona replication manager (PRM)
  • MySQL master HA (MHA)
  • NDB Cluster
  • Shared storage/DRBD

這些都是把 High Availability 做在 MySQL 上,讓前端的程式不需要操心的方式。都是有個固定的 IP address 保證可以讀寫。

這五個方案都不完美,看環境需求而選擇使用。

我一般給的建議還是 Heartbeat + DRBD + InnoDB,這個方法是極為成熟的方法,會遇到的問題網路上都已經討論過了。如果找 Percona 的人支援也是完全沒問題。

MySQL HA 的選擇...

Percona 把常見的 MySQL High Availability 選擇整理後發表成 Webinar,投影片在這裡可以看到 (以及下載):「Choosing a MySQL High Availability Solution」。

沒有太多新的東西,主要還是再次描述 MySQL HA 這塊目前沒有萬靈丹,常見的這幾個方案各有自己的優缺點,會依照環境與需求而產生不同的選擇。裡面連 manual failover + 24x7 NOC 都出現了... XD

對於不清楚有哪些 HA 架構的人,可以透過這份投影片先抓出關鍵字。對於聽過一堆 HA 架構的人,想要複習各種方式的優缺點,也可以花時間看看。至於想要找萬靈丹的人就不用花時間了,目前沒這東西 :p