幹壞事是進步最大的原動力
看到 Percona 的「MySQL Ripple: The First Impression of a MySQL Binlog Server」這篇提到了 Google 放出來的專案 mysql-ripple。
這個軟體的情境是針對有很多 replica (slave) 時的情境，要解決每一個 replica 都會對 master server 產生壓力，算是 binlog 的 cache layer。
MySQL Ripple 抓了 binlog 下來後就可以模擬成 mysql server (但是只能提供 binlog 服務) 讓 replica 接，在 replica 很多的情境下就可以橫向擴充，而且因為軟體只支援 GTID 模式，所以比較好做 HA 架構 (相對於 filename + position 模式)。
大概可以歸納出是 write 很多 (所以 binlog 量很大)，但又有大量 replica 需求的情境... 目前好像想不出來有什麼情境可以拿出來用 :o
Amazon Aurora (PostgreSQL) 支援 Read Replica 了：「Announcing Amazon Aurora PostgreSQL Read Replica for Amazon RDS for PostgreSQL」。
馬上想到的用途是量爆增時，如果當初有作 R/W split (讀寫分離) 就可以直接用錢撐住，不過官方給的範例是降低 RDS 轉移到 Aurora 的 downtime，這點就有點微妙...：
You can now create an Amazon Aurora PostgreSQL read replica for an Amazon RDS for PostgreSQL instance, allowing you to continuously replicate to Amazon Aurora PostgreSQL. This helps you minimize downtime when migrating a live workload from Amazon RDS for PostgreSQL to Amazon Aurora PostgreSQL, by keeping the instances in sync until you're ready to move your applications and users to Amazon Aurora PostgreSQL.
所以這次算是陸陸續續把功能補上來，在 Amazon Aurora (MySQL) 有的一般性功能，這邊就跟著先實作...
Amazon Aurora 推出了兩包玩意，第一包是 Serverless，讓需要人介入的情況更少：「In The Works – Amazon Aurora Serverless」。
在 Serverless 的第一個重點是支援以秒計費：
Today we are launching a preview (sign up now) of Amazon Aurora Serverless. Designed for workloads that are highly variable and subject to rapid change, this new configuration allows you to pay for the database resources you use, on a second-by-second basis.
然後是極為快速的 auto-scaling：
The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources. This allows your connections to remain intact even as scaling operations take place behind the scenes. Scaling is rapid, with new resources coming online within 5 seconds
這兩個組合起來，讓使用端可以除了在 Amazon EC2 上可以快速 scale 外，後端的資料庫也能 scale 了...
第二個是 Multi-master 架構：「Sign Up for the Preview of Amazon Aurora Multi-Master」。
Amazon Aurora Multi-Master allows you to create multiple read/write master instances across multiple Availability Zones. This enables applications to read and write data to multiple database instances in a cluster, just as you can read across Read Replicas today.
(話說我一直都誤以為 Aurora 是 R/W master...)
Anyway，這個功能不知道怎麼疊上去的... 不笑得會不會有嚴重的 distributed lock issue，反而推薦大家平常都寫到同一台 (像是 PXC 就會這樣)。
Percona 的人寫了一份文件，以 MySQL DBA 的角度說明兩者在 replication 上的差異，然後示範怎麼在單機上架起三個 MongoDB 並且設定 replica-set：「First MongoDB replica-set Configuration for MySQL DBAs」。
這邊文章拿的是 Percona Server for MongoDB，不過應該也還行，並竟是拿 MongoDB 3.2 改的，而不是完全重寫，所以裡面的步驟拿到原版的 MongoDB 上應該也行...
傳統的作法 (自己擁有機房時) 就是在兩個機房中間建立 site-to-site VPN (通常是 IPsec)，然後再用 MySQL 的 replication 接起來，而現在 Amazon Aurora 直接在界面上支援這件事情，可以在網頁上點一點開起來：「New – Cross-Region Read Replicas for Amazon Aurora」。
不過好像沒講到跨區的 VPC 對接設定問題？所以是透過他們自己的 network 接起來？這樣的話流量費用要怎麼算？
Amazon RDS 將提供跨區的 MySQL read replication。看起來是針對 5.6+ 的版本提供這個功能...
有兩篇官方文章，一篇是 CTO 發了一篇「Expanding the Cloud: Enabling Globally Distributed Applications and Diaster Recovery」，另外一篇是官方網誌上的「Cross-Region Read Replicas for Amazon RDS for MySQL」。
用圖表示比較容易懂：
在 US-East 建立 MySQL master，另外在 EU 與 Tokyo 建立 slave replication。不知道中間的 traffic 有沒有過 IPSec 或是 SSL？
以往要在 Amazon RDS 產生 Read Replica Replication 需要複雜的 snapshot 處理，但現在 AWS 直接提供這個功能了，而且可以同時生很多台：「New Read Replica Capabilities for Amazon RDS」。
這有多重要呢？以前因應流量瞬間爆增時的方式是增加 web server，並且利用 cache (可能是 memcached) 降低對後端的 query 數量。但因為引入 cache，平常就得處理 cache invalidate 的問題。
而這個方式平常只要處理讀寫分離就可以了。當量爆增時除了 web server 增加，直接增加後端的 RDS server (Read Replica Replication)，甚至可以分層：
以目前的步調來看，之後有可能會推出 Master-Master 的 HA 架構？
Update：照 comment 提到的，Multi-AZ 本身就是 HA 架構了...