Tag: rds

Amazon RDS for PostgreSQL 可以掛 155 台 Read Replica

看到 AWS 推出的新「功能」，可以讓 Amazon RDS for PostgreSQL 的 read replica 掛到 155 台：「Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity」。

作法是透過三層架構，每台機器可以堆五台 replica：

Amazon Relational Database Service (Amazon RDS) for PostgreSQL announces support for PostgreSQL 14 with three levels of cascaded read replicas, 5 replicas per instance, supporting a maximum of up to 155 read replicas per source instance.

需要 PostgreSQL 14.1 或是之後的版本：

Starting with Amazon RDS for PostgreSQL 14.1 and higher, read intensive workloads such as data analytics can now benefit from up to 155 cascaded read replicas that offer up to 30 times higher read capacity versus previous versions of PostgreSQL, thereby reducing the load on source instance.

我記得 Amazon RDS for PostgreSQL 的 replica 是 EBS block-level replication，這種搞法還蠻有趣的 XDDD

Amazon RDS 的 Free Tier 方案包含了 db.t3.micro 與 db.t4g.micro

AWS 把 db.t3.micro 與 db.t4g.micro 都放進 free tier 了：「Amazon RDS Free Tier now includes db.t3.micro, AWS Graviton2-based db.t4g.micro instances in all commercial regions」。

Customers new to AWS in the past 12 months and who were in regions where db.t2.micro was not available can now create free tier db.t3.micro or db.t4g.micro instances for the remainder of their first 12 months.

看說明是註冊的 12 個月內有這個方案可以用，可以拿來跑一些小東西...

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.

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

Babelfish：讓 PostgreSQL 可以吃 Microsoft SQL Server 的協定

看到「Goodbye Microsoft SQL Server, Hello Babelfish」這篇，AWS 對 Aurora (PostgreSQL) 推出了可以吃 Microsoft SQL Server 協定的 Babelfish：

Today, we are making Babelfish for Aurora PostgreSQL available. Babelfish allows Amazon Aurora PostgreSQL-Compatible Edition to understand the SQL Server wire protocol.

查了一下資料發現是去年年底的時候發表的：「Want more PostgreSQL? You just might like Babelfish」，不過當時沒注意到這東西，大概是因為是 preview 的關係：

We are open sourcing Babelfish in 2021. Until then, you can use Babelfish on Amazon Aurora in a preview to see how it works and to get a sense for whether this is the right approach for you.

用起來不知道怎樣，但感覺很值得注意，目前雖然沒用到 Microsoft SQL Server 的東西，但以後遇到可以考慮看看...

除了在 AWS 上用以外，也可以自己到 GitHub 上拉 patch 回來上：「babelfish-for-postgresql」。

話說回來，PostgreSQL 被 AWS 拿來用在好多地方啊，先前大家也猜是 DocumentDB 後面是 PostgreSQL (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」這篇)，不知道之後會不會想要跟 Oracle 的律師打架...

Amazon RDS 支援 ARM 架構的 t4g 與 x2g

這兩篇剛好一起看，Amazon RDS 支援了 ARM 架構的 t4g 與 x2g：「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」，包含了 MySQL、MariaDB 與 PostgreSQL 的版本都有支援，不過看起來需要比較新版的才能用：

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 就好？