MySQL

MySQL 8.4.0 出版

這是 LTS 版本，可以預期後續 Percona 也會準備對應的 distribution 使用。

先查了一下 MySQL 8.0 的 EoL 日期，目前是訂在 2026/04/30，大約還有兩年的時間可以準備。

回來看 8.4，從「What Is New in MySQL 8.4 since MySQL 8.0」這邊可以看到官方整理與 8.0 的差異。

InnoDB 這邊有不少預設參數調整，算是配合現在硬體愈來愈好而調整的數字。

在「MySQL Replication: tagged GTIDs」這邊有提到 replication 時用到的 GTID format 有更新，多了 tag 的欄位。看起來在 upgrade 時會相容舊格式，但要 rollback 或是 downgrade 時得注意到這邊的問題...

然後在「Replication SQL syntax」這邊有提到移除掉很多舊語法，像是 CHANGE MASTER TO 與 RESET MASTER 這種語法都被改成新的語法了，要重新背。

整體看起來沒有太多變化？

Amazon RDS 推出 RDS Extended Support

AWS 的 Amazon RDS 推出了 MySQL 5.7 與 PostgreSQL 11 的 RDS Extended Support 服務：「Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support」。

直接看官方整理的這張表格比較清楚：

基本上都到 2027Q1 左右，差不多再多支援三年。

另外表上的時間有些接不起來的地方，則是在 Note 的地方說明。

其中 MySQL 5.7 的部分分成兩塊，其中 RDS for MySQL 5.7 的部分是比較清楚的：原來的 RDS standard support 到 2024/02/29，後續從 2024/03/01 馬上接付費的 RDS Extended Support。

而 Aurora MySQL 2 的 RDS standard support 則是直接一路到 2024/10/31，然後 2024/11/01～2024/11/30 的 RDS Extended Support 不收費，從 2024/12/01 開始收費：

RDS Extended Support for Aurora MySQL 2 starts on November 1, 2024, but will not be charged until December 1, 2024. Between November 1 and November 30, all Aurora MySQL 2 clusters are covered under RDS Extended Support.

而 PostgreSQL 11 的部分都一樣 (RDS for PostgreSQL 11 與 Aurora PostgreSQL 11)，原來的 RDS standard support 到 2024/02/29，而 2024/03/01～2024/03/31 的 RDS Extended Support 則是免費的，從 2024/04/01 開始收費：

RDS Extended Support for PostgreSQL 11 starts on March 1, 2024, but will not be charged until April 1, 2024. Between March 1 and March 31, all PostgreSQL 11 instances on Aurora and RDS are covered under RDS Extended Support.

然後費用的部分也查的到了，是用 vCPU-hour 計算的，四條產品線的價位在 us-east-1 的計價是相同的，前面兩年是 $0.1/vCPU/hr，而第三年是 $0.2/vCPU/hr。

由於 RDS 的機器最少是 2 vCPU，所以一台機器至少要多付 $0.2/hr 的費用，這個費用基本上會比 RDS 費用還貴。

這邊給個比較的數字，同樣在 us-east-1 上，2 vCPU + 8GB RAM 的 db.t4g.large 要 $0.129/hr，而一樣 2 vCPU + 8GB RAM 如果是 db.m7g.large 則是 $0.168/hr，都還沒有 RDS Extended Support 貴；要到 r7g.large 這種以記憶體導向的 $0.1071/hr 才差不多跟上一樣的價錢。

另外一個方法應該就是改成自己在 EC2 上架設？這樣成本會因為 RDS 轉 EC2 的下降，整體大約會降到 1/4...

不過應該也會有公司就是用下去，在上面跑的好好而且很賺錢的東西就不想亂動...

Jepsen 回過頭來測試 MySQL 8.0

Hacker News 上看到作者自己貼的：「Jepsen: MySQL 8.0.34 (jepsen.io)」，原文在「MySQL 8.0.34」。

這次的測試不是 Oracle 付費讓 Jepsen 測，而是 Jepsen 這邊自己回頭測試 MySQL 8.0：

This work was performed independently without compensation, and conducted in accordance with the Jepsen ethics policy.

然後意外的流彈 (或是榴彈？) 打下了 AWS 的 RDS，測出 RDS 在 cluster 模式下無法達到 SERIALIZABILITY：

As a lagniappe, we show that AWS RDS MySQL clusters routinely violate Serializability.

然後 MySQL 本體則是找到 REPEATABLE-READ (預設 isolation level) 的問題：

Using our transaction consistency checker Elle, we show that MySQL Repeatable Read also violates internal consistency. Furthermore, it violates Monotonic Atomic View: transactions can observe some of another transaction’s effects, then later fail to observe other effects of that same transaction. We demonstrate violations of ANSI SQL’s requirements for Repeatable Read.

文章的前面一大段在寫歷史，解釋 ANSI 當初的 SQL 標準在定義 isolation level 時寫的很差，導致有很多不同的解讀，而且即使到了 SQL:2023 也還是沒有改善。

接著則是提到各家資料庫宣稱的 isolation level 跟 ANSI 定義的又不一樣的問題... (包括了無論怎麼解讀 ANSI 定義的情況)

不過中間有提到 1999 年 Atul Adya 試著正式定義 isolation level，把本來的四個 isolation level 用更嚴謹的方法重新給出相容的定義，這看起來是作者推薦在一般狀況下的替代方案：

In 1999, Atul Adya built on Berenson et al.’s critique and developed formal and implementation-independent definitions of various transaction isolation levels, including those in ANSI SQL. As he notes[.]

這四個會是 PL-1 對應到 READ UNCOMMITTED，PL-2 對應到 READ COMMITTED，PL-2.99 對應到 REPEATABLE-READ，以及 PL-3 對應到 SERIALIZABILITY；而其中 PL-2.99 的 REPEATABLE-READ 在後面也會重複出現多次。

這次比較意外是在單機上找出問題來，至於 RDS 的部分反倒不是太意外，因為知道 AWS 在底層做了不少 hack，總是會有些 trade off 的？

GitHub 的 MySQL 5.7 升級到 8.0 的細節

GitHub Blog 上面寫了一篇關於 GitHub 怎麼把 MySQL 5.7 升級到 8.0 的過程，有點長度但是裡面有蠻多數字與架構可以看：「Upgrading GitHub.com to MySQL 8.0」。

開頭先順便提一下，看這篇後可以交叉看 GitHub 的 Incident History，有幾次跟 database 有關的事件，雖然不能直接確認與這波升級有關，但心裡可以有個底...

數字與時間的部分主要是這些：

Our fleet consists of 1200+ hosts. It’s a combination of Azure Virtual Machines and bare metal hosts in our data center.

We store 300+ TB of data and serve 5.5 million queries per second across 50+ database clusters.

Preparation for the upgrade started in July 2022 and we had several milestones to reach even before upgrading a single production database.

另外雖然沒有明講，但從文章中其他段落的描述，以及相關的圖片，可以看出來 GitHub 是使用 single-primary (single-master) 的架構，這邊沒有用到 multi-primary (multi-master) 類的架構：

We opted not to do direct upgrades on the primary database host. Instead, we would promote a MySQL 8.0 replica to primary through a graceful failover performed with Orchestrator.

後續升級的部分有點長，第一波關於 read-only replica 的部分雖然有些地方沒講清楚，但基本上大家的作法都大同小異：

比較明顯有疑問的是，第一步為什麼不是直接生一台新的 8.0 觀察 (這樣觀察到的環境才會與後續過程接近)，而是 in-place upgrade，而後續開的機器又是 provision。不過這個算是小問題...

比較值得研究的是在第二步與第三步的說明裡面提到的 primary (master) 這塊。

第二步是先改變 topology，這個架構算是蠻特別的的過渡架構，只會維持幾個小時；會把其中一台 8.0 replica 拉起來放在中間，然後再串一台 5.7 replica，接下去再串 5.7/8.0 的 read-only replicas：

第三步把 primary (master) 指到 8.0 上：

這個特別的架構可以推敲出來是想要能夠快速在有狀況時完全 rollback 回 5.7，不過可以馬上想到 8.0 的資料丟到 5.7 上的問題。

MySQL 的慣例是下一個版本的 replication 通常都會通 (像是 5.0 -> 5.1，或是 5.1 -> 5.5，而這邊的例子是 5.7 -> 8.0)，這在官方的文件「Replication Compatibility Between MySQL Versions」有提過。

但反過來就不一定了，這也是看到圖時馬上會想到的問題，在文章裡面也有提到：

MySQL supports replication from one release to the next higher release but does not explicitly support the reverse (MySQL Replication compatibility).

所以他們只能在 staging 上演練看看，找出會炸掉的東西，然後得提前先修改完：

When we tested promoting an 8.0 host to primary on our staging cluster, we saw replication break on all 5.7 replicas.

另外一方面，在文章開頭的地方也有提到利用 CI 事先找出問題：

We added MySQL 8.0 to Continuous Integration (CI) for all applications using MySQL. We ran MySQL 5.7 and 8.0 side-by-side in CI to ensure that there wouldn’t be regressions during the prolonged upgrade process. We detected a variety of bugs and incompatibilities in CI, helping us remove any unsupported configurations or features and escape any new reserved keywords.

用這些方法儘量把問題圍堵找出來，而真的遇到在 production 上的問題時，應該是看情況來決定要不要 rollback 回 5.7 整包重來？

就... 看看當作一個有趣的 case study。

MySQL 5.7 已經 EoL

查資料發現忘記這件事情了... 先前就有寫過 MySQL 5.7 到今年十月就 EoL 了：「MySQL 5.7 的支援只到今年十月 (Oct 2023)」。

最後一版是 2023/10/25 釋出的 5.7.44：「Changes in MySQL 5.7.44 (2023-10-25, General Availability)」。

MySQL 5.7.44 is the final release of the MySQL 5.7 series.

然後 MySQL 8.1 也是十月 EoL。

雖然目前已經有 MySQL 8.2 了，但 MySQL 8.0 是 LTS，目前預定支援到 2026 年四月 (大約還有兩年多)，所以除非有需要用到 MySQL 8.2 的新功能或是特性，不然應該還是會先繼續用 MySQL 8.0...

然後翻了一下 Percona Server for MySQL，看起來還是沒有提供 ARM 的 binary 可以裝，所以在 ARM 上面的機器比較方便的還是裝 MariaDB 了...

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 的優點可能就沒那麼高了...

MySQL 改變發佈的方式，推出 LTS 版本

看到 Percona 寫的「LTS and Innovation Releases for Percona Server for MySQL」這篇，才注意到 Oracle 宣佈了 MySQL 的 LTS 版本：「Introducing MySQL Innovation and Long-Term Support (LTS) versions」。

這次的改變產生了 Innovation 版本與 LTS 版本：

We're transitioning to the new MySQL versioning model with our upcoming versions. MySQL database version 8.1.0 will be our first Innovation release, and 8.0.34+ will transition to only bug fixes until 8.0 End-Of-Life (EOL) scheduled for April-2026. Approximately one year from now, MySQL version 8.x will eventually become LTS which will provide ample time for users to migrate from 8.0.x to the 8.x LTS version.

從這段的解釋看起來是在講從舊的發佈模式到新的發佈模式的轉換期特例，MySQL 8.0.34+ (應該是指 8.0 的後續這條，從 8.0.34 開始) 會支援到 2026 年四月，大約是再兩年半多；而 8.x (應該是指 >8.0 的這條？) 會在距今一年後 (大約是 2024 年年中？) 成為 LTS 版本。

接著的段落拿了一些範例說明：

In practice, in this transition period, if you want the latest features, improvements, and all bug fixes for your MySQL databases, use the Innovation release track (eg., 8.1.x, 8.2.x, 8.3.x, etc.). If you need only bug fixes for your MySQL database, use 8.0.x releases (eg., 8.0.35, 8.0.36, 8.0.37, etc.). In both cases, you should plan to update your MySQL databases quarterly accordingly to Oracle Critical Patch Updates (CPU) calendar. When 8.x becomes LTS, you can plan, test, and migrate from the 8.0.x bug fix track to the LTS release track (ex., from 8.0.37 to 8.4.1).

看起來 8.0 是轉換期的特殊待遇，看起來有點像是 LTS 的 security update only？然後是官方給的這張圖，要注意這張圖下面有提到這張圖只是示意，實際發生的時間點可能會有改變，不過也可以看出來在 8.0 的地位比較特別：

Note that this is an example, there is no commitment that the version numbering will be exactly as presented.

而 LTS 的頻率會是兩年一版，支援 5+3 年，而 8.0 會走四年半：

About every 2 years, a minor version will be designated as Long Term Supported release. This version will have a 5 year premier and 3 year extended support, the same as the previously supported releases. This is similar to MySQL 5.7 and previous releases.

The LTS will also be the last version of the major release. The next (Innovation) release will increase it's major version. For example if MySQL 8.4.0 is the 8.x LTS release, then MySQL 9.0 will be the next Innovation release.

另外後面有提到他們會確保 LTS 在升級時會用到的方式，看了一下沒有太多意外，跟之前在 5.x 年代的感覺差不多。

倒是降級這件事情他們也提出方案，這點就蠻值得看一下了... 然後這邊可以看到 async replication 果然超萬用的。

基本上就是 release cycle 改變的公告，現在這個階段繼續黏在 8.0 上面應該就可以了，後續等第一個 LTS 的消息。

Meta (Facebook) 把 MySQL replication 丟上自製的 Raft 系統

看到「Building and deploying MySQL Raft at Meta」這篇，在講 Meta (Facebook) 把 MySQL 的 replication 架構換成自己用 Raft 的系統。

舊的系統是走 MySQL 的 semisync replication：

Previously, our replication solution used the MySQL semisynchronous (semisync) replication protocol.

其中 semisync replication 是在 MySQL 5.5 加入的功能，在至少一個遠端收到 replication log 後才傳回成功 (可以設定數量)：「Semisynchronous Replication」。

Semisynchronous replication falls between asynchronous and fully synchronous replication. The source waits until at least one replica has received and logged the events (the required number of replicas is configurable), and then commits the transaction.

然後舊的系統是透過一包 Python 軟體在管理這些機器的各種 failover 操作：

The control plane operations (e.g., promotions, failover, and membership change) would be the responsibility of a set of Python daemons (henceforth called automation).

這個方法常遇到的問題是切換 primary server (以前叫做 master server) 時有可能會因為 binlog position 接不起來而失敗。

所以後來 MySQL 導入了 GTID，可以緩解這個問題，但還是有可能會發生不同的 secondary server (以前叫做 slave server) 會有不一樣的資料。

而在 Meta 改出來的架構裡面，把 replication data 直接寫到一個用 Raft 同步的系統，同步到其他的 secondary server 上面：

In MySQL Raft:

Primary writes to binlog via Raft, and Raft sends binlog to followers/replicas.

Replicas/followers receive in binlog and apply the transactions to the engine. An apply log is created during apply.

Binlog is the replicated log from the Raft point of view.

是個一般單位不太會遇到的架構，而且可以預期其他公司的人遇到類似問題應該也不會用這個方法解...

MySQL 5.7 的支援只到今年十月 (Oct 2023)

剛剛翻資料才看到 Oracle 對 MySQL 5.7 的支援原來只剩下半年了，預定在 2023 年十月中止：「Oracle Technology Products - Oracle Lifetime Support Policy」。

隔壁棚 Percona 包的 Percona Server for MySQL 5.7 可以從「Percona Release Lifecycle Overview」這邊查，看起來也設定一樣的時間 (2023 年十月)，但不確定會不會宣佈延長，至少提供 security fix 之類的。

一直沒注意，突然發現只剩下半年...

Category: MySQL

Percona 的 Telemetry Package