Amazon RDS 支援 ARM 架構的 t4g 與 x2g

這兩篇剛好一起看,Amazon RDS 支援了 ARM 架構的 t4gx2g:「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。

目前主要是關注 t4g,因為目前量的關係反而是大量使用 t4g 類的機器,如果上面的 PostgreSQL 可以跑 t4g 的話,看起來只要沒有買 RI 的可以換過去,主要是比 t3 再省一些錢:以新加坡區的 PostgreSQL 來說,db.t4g.micro 目前是 $0.025/hr,而 db.t3.micro 則是 $0.028/hr,差不多是九折。

沒意外的話效能應該也會提昇一些,不過用 t 系列的機器本來就沒有太大的量在上面跑,這點應該是還好...

Amazon RDS 上 PostgreSQL 的不停機升級

Hacker News Daily 上看到「Zero downtime Postgres migration, done right」這篇,講 PostgreSQL 9.5 不停機的前提下升級到 12.5 的方式,而且是在 Amazon RDS 上:

We have successfully used this process to migrate our Postgres databases from version 9.5 to 12.5 on RDS, but the process isn’t restricted to RDS only, and does not depend on anything AWS specific.

然後整個重點就在一張圖:

其實幾個 open source database 在這塊的基本概念都類似,用 replication 的技巧升級。

這邊作者選的是用 Bucardo 同步資料,然後舊的與新的 replication 都是雙向的,這樣在切換應用程式的時候就比較不會有時間差的問題。

這邊值得說的是,PostgreSQL 10 (2017 年十月出) 之後因為有了 logical replication,這種不停機持續性的 replication 選擇就變多了,不一定要用 trigger-based replication。作者這邊應該是因為 PostgreSQL 9.5 的關係,所以需要挑了 Bucardo。

另外一個重點是,如果你可以允許短時間的停機 (十分鐘之類的),那就可以改用單向的 replication 升級。因為你可以先停掉舊的資料庫,確保所有的資料都已經更新到新的資料庫,再把應用程式切換到新的資料庫上。

而這套方法如同作者說的,不限於 AWS 家的產品,其他家也可以使用類似的方法,在傳統實體機房也可以這樣做。

另外在 Hacker News 上的討論「Zero downtime Postgres migration, done right (theblueground.com)」很正常的又在戰 MySQL 在這塊的成熟度好太多,看看就好 XDDD

AWS 淘汰 Amazon RDS (MySQL 5.5) 的計畫

AWS 規劃要淘汰 Amazon RDS (MySQL 5.5),不過我是從 Percona 這邊看到...:「Amazon RDS for MySQL 5.5 EOL Date is Approaching – Act Now!」,找了一下官方的文件,在「Announcement: Amazon RDS for MySQL 5.5 End-of-Life date is approaching」這邊可以翻到。

如果硬要待在 MySQL 5.5 的話,目前看起來比較容易的解法應該是自己用 EC2 架,不過這樣的話 High Availability 的架構就頗麻煩了,用 ELB 可能是個方法...

話說回來,好久沒用 MySQL 5.5 了,這個版本記得是 InnoDB Plugin 整合進 MySQL 的第一個版本,先前應該是 MySQL 5.1 + InnoDB Plugin 的方式跑,我記得當時就是要 COMPRESSED 格式,算是 MySQL 當時蠻重大的進展...

手上還有在 5.5 上跑的人應該要自己安排時間換,儘量不要等到 AWS 硬升級的時候換,這樣炸掉的機會蠻高的...

一人團隊的技術架構

Hacker News Daily 上看到的文章,在講一人團隊時所設計的技術架構:「The Tech Stack of a One-Man SaaS」。這種資訊通常帶有個人偏好,維護成本算是蠻重要的重點,在多人團隊就未必會這樣選,但就拿著爆米花看戲的心態來說應該還 OK。

像是作者很明顯熟悉 Python,就可以看到他裡面會列出許多 Python 相關的 toolchain 與維護工具。

裡面比較有趣的是他對 DigitalOcean 的 K8S 問題很多抱怨了一番,然後換去 Linode 後又因為不想要自己管 PostgreSQL 而決定搬到 AWS 上面,可以用 RDS 省事... 花錢解決 XD

算是當短文小說在看...

RDS 推出 ARM 版本

Amazon RDS 推出了 ARM 的版本:「New – Amazon RDS on Graviton2 Processors」,包含了 MySQLMariaDBPostgreSQL 的版本都有支援,不過看起來需要比較新版的才能用:

You can choose between M6g and R6g instance families and three database engines (MySQL 8.0.17 and higher, MariaDB 10.4.13 and higher, and PostgreSQL 12.3 and higher).

官方宣稱可以提供 35% 的效能提昇,考慮費用的部份會有 52% 的 c/p 值提昇:

Graviton2 instances provide up to 35% performance improvement and up to 52% price-performance improvement for RDS open source databases, based on internal testing of workloads with varying characteristics of compute and memory requirements.

對於 RDS 這種純粹就是個服務的應用來說,感覺應該不會有什麼轉移成本,只要測過沒問題,換過去等於就是現賺的。看起來等 RI 約滿了就可以切...

對 Amazon Aurora (MySQL-Compatible Edition) 另外建 Replica

Percona 的人寫了一篇怎麼對 Amazon Aurora (MySQL-Compatible Edition) 生 replica 的文章:「Creating an External Replica of AWS Aurora MySQL with Mydumper」。

這邊用的方法主要是出自「Replication with Amazon Aurora」這篇,裡面有提到有 binlog 可以用,所以 Percona 的作法應該是屬於「雖然不能 100% 保證以後還是可以用,但 99% 的機會以後應該還是可以用」。

這樣搞主要應該是用在 1) 省錢,2) 需要特殊的調整;如果不是這兩種,一般會選 Aurora 版本,應該不會太在意成本,直接用他提供的 read replica 就好?

AWS 提供程式,可以掃出有哪些 RDS 的憑證需要更新

先前在「AWS 的 CA 更新 (CA-2019),將會影響與資料庫相關的服務」這邊提到了 AWSRDS 因為 Root Certificate 快要過期,需要更新到 CA-2019。

剛剛在 Twitter 上看到 Jeff Barr 提到了一個可以直接列出有哪些機器需要更新的工具:

程式放在 GitHub 上的 aws-samples/rds-ssl-update,另外看到一個有趣的授權條款,叫做 MIT-0 License,是 AWS 自己改的一個授權版本,拿掉了 MIT License 裡面的這段:

subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

也就是要求要引用授權條款的部份被拿掉,不過我還是比較喜歡 BSD license,尤其是 3-clause 的版本...

AWS 的 CA 更新 (CA-2019),將會影響與資料庫相關的服務

AWS 要開始使用新的 CA 發各種資料庫相關服務的 SSL endpoint (包括 RDSAuroraDocumentDB),看一下差不多是十多天前的消息,不知道為什麼突然發個緊急通告:「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」。

本來的 CA 是 CA-2015,將在 2020 年到期:

March 5, 2020 – The CA-2015 certificates will expire. Applications that use certificate validation but have not been updated will lose connectivity.

所以會有裡面提到的事項要處理,其中前幾天讓新的 CA-2019 變成新機器的預設值,但如果有需要,還是可以選舊的:

January 14, 2020 – Instances created on or after this date will have the new (CA-2019) certificates. You can temporarily revert to the old certificates if necessary.

可以把 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 拉下來用 openssl x509 -text -in rds-ca-2019-root.pem 看,另外把網址裡的 2019 改成 2015 也可以拉到舊版的。

不過看起來沒有用 X.509 Name Constraints 限制在只有自家 RDS 的網域...

Amazon RDS 推出了 Connection Pool 的產品

Amazon RDS 推出了 Connection Pool 的產品,叫做 Amazon RDS Proxy:「Introducing Amazon RDS Proxy (Preview)」。

目前支援 MySQL (包括了傳統的與 Aurora 版本的):

Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.

定價策略看起來是依照後端資料庫的 vCPU 計算:

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.

翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料),而如果是 t2 系列的機器,最低是以 2 vCPUs 計算,不是照使用比例算:

RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.

這樣一個 vCPU 一個月大約要 USD$21.6,算起來頗貴的... 如果 SLA 允許的話,用基本的方式 failover 也許就 ok 了...

如果 SLA 真的要追求到這麼高的話,可以在這些區域測試:

Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.

Amazon Aurora MySQL 5.7 也可以上 Global Database 了

AWSAmazon Aurora MySQL 5.7 版本推出了 Amazon Aurora Global Database:「Aurora Global Database is Now Supported on Amazon Aurora MySQL 5.7」。

看起來 MySQL 系的 Global Database 就是跨區的 master-slave 架構 (所以標榜降低了 read latency,但沒有提到 write latency):

An Amazon Aurora Global Database is a single database that spans multiple AWS regions, enabling low latency global reads and disaster recovery from region-wide outages.

另外可以看到是 1 秒,所以應該是 async replication:

Aurora Global Database replicates writes in the primary region with typical latency of <1 second to secondary regions, for low latency global reads.

然後可以跨區切換:

In disaster recovery situations, you can promote the secondary region to take full read-write responsibilities in under a minute.

看了一下好像不用多付服務費用,就是各區自己的費用,加上傳輸的費用而已,看起來是個還不錯的服務?