Amazon RDS 支援 readonly instance 當作 Multi AZ 的機器了

從來沒在用 RDS 的 Multi AZ,所以根本沒注意到居然沒這個功能:「New Multi-AZ deployment option for Amazon RDS for PostgreSQL and for MySQL; increased read capacity, lower and more consistent write transaction latency, and shorter failover time (Preview)」。

看起來 (加上印象中) 之前的 Multi AZ 是另外一台機器先開著但不能用:

In the case of an infrastructure failure, Amazon RDS performs an automatic failover to the standby, so that database operations resume as soon as the failover is complete.

現在則是開著的機器可以跑 readonly 模式:

The standby DB instances act as automatic failover targets and can also serve read traffic to increase throughput without needing to attach additional read replica DB instances.

這樣做除了省成本外,另外因為這些 instance 平常就有 query 的量,當真的遇到 failover 切換時,warmup 的時間也會短很多 (尤其是服務夠大的時候)。

不過有些限制,首先看起來只支援 Graviton2 (ARM-based) 的機種?

The readable standby option for Amazon RDS Multi-AZ deployments works with AWS Graviton2 R6gd and M6gd DB instances (with NVMe-based SSD instance storage) and Provisioned IOPS Database Storage.

然後是支援的區域:

The Preview is available in the US East (N. Virginia), US West (Oregon), and Europe (Ireland) regions.

以及夠新的版本,MySQL 8 與 PostgreSQL 13.4 才有提供:

Amazon RDS for MySQL supports the Multi-AZ readable standby option for MySQL version 8.0.26. Amazon RDS for PostgreSQL supports the Multi-AZ readable standby option for PostgreSQL version 13.4.

但看起來還不錯,畢竟這比較接近以前在地端機房時的作法...

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

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

Amazon Aurora Global Database

AWSAurora (MySQL) 推出 Amazon Aurora Global Database:「Announcing Amazon Aurora Global Database」。

看起來不是 multi-master (從 secondary region 這個字看),所以寫入的部分還是得送回 primary region 處理:

Aurora Global Database uses storage-based replication with typical latency of less than 1 second, using dedicated infrastructure that leaves your database fully available to serve application workloads. In the unlikely event of a regional degradation or outage, one of the secondary regions can be promoted to full read/write capabilities in less than 1 minute.

應該是單一 endpoint 幫你處理這些雜事...

CloudFront 十週年、在東京的第十個 PoP,以及支援 WebSocket 與 Origin Failover

CloudFront 宣佈十年了,另外這次在東京又加節點了,變成 10 個:「Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations」。

另外宣佈支援 WebSocket:「Amazon CloudFront announces support for the WebSocket protocol」,以及支援 Origin Failover:「Amazon CloudFront announces support for Origin Failover」。

WebSocket 算是大家等蠻久的功能,大家主要是希望利用 CloudFront 擋 DDoS,正常流量才往後丟。而 Origin Failover 則是可以設定兩個 Origin,當主要的掛掉時可以切到備用的,對於支援多節點的架構算是第一步 (目前看起來只能設兩個):

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

都是隔壁棚 Cloudflare 支援許久的功能... 算是補產品線與進度?

大型 WordPress 站台會用到的 LudicrousDB (以及 HyperDB)

最近收到 HyperDB 的 mailing list 信件 (開頭是「[HyperDB] How can I set up HyperDB with latest version.」這封),有人提到 HyperDB 很久沒更新了... 結果在信理看到有人回了「stuttter/ludicrousdb」這個專案:

LudicrousDB is an advanced database interface for WordPress that supports replication, failover, load balancing, & partitioning

兩個專案都是抽換掉 WordPress 在處理 database 的 library,然後希望自己控制 master/slave 的讀寫分離以及各機房之間的處理 (還有 replication lag),而不要靠 ProxySQL 這類工具來做 (以時間來看,當初他們發展這些工具時,ProxySQL 這類的方案也還不夠成熟,大家都不會想要選這個方向...)。

先記錄下來,如果之後有遇到時可以當作是一個選項...

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 好,但管理上輕鬆很多啊...

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 設定變得單純。

多資料中心的備援機制

100% 的 uptime 有點誇張啦,不過看到這篇文章有些啟發:「Multi-Home the Data Center for 100% uptime」。

這張圖裡面,如果 DC1 的 DB master 掛掉,那麼 DC2 也只能進入唯讀狀態?甚至有些應用連唯讀狀態都不能進...

不過想到 Percona XtraDB Cluster 放三個機房的方法,不過如果只放三台的話會有其他的風險就是了,本粗一點變成六台 (每個機房都兩台) 也是個方法 :o

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝),像是這樣的架構:

其中 node{1,2} 為 cluster,node3 則是傳統的 async replication,來源的 master 為 node1。

當 node1 掛掉時,我們沒辦法自動將 node3 的 master 從 node1 改指到 node2,因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值,這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的,就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO,而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後,就有機會寫成程式自動化... 這算是一個不錯的開頭 :p

jQuery CDN failover 的方式...

之前有在其他網站上看到 failover 的技巧,但剛剛才發現 jQuery 官方網站上也用上了類似的技巧,將 Google (ajax.googleapis.com) 與 EdgeCast (code.jquery.com) 的 CDN:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>!window.jQuery && document.write('<script src="http://code.jquery.com/jquery-1.4.2.min.js"><\/script>');</script>

雖然 jQuery 網站上是放在開頭,但放在 HTML 最後面也有一樣的效果...