幹壞事是進步最大的原動力
Hacker News 上看到「Sqlite3 Utility in the Browser (sqlite.org)」這個，看了一下是官方提供的 playground：「SQLite3 Fiddle」。
從 https://sqlite.org/fiddle/fiddle.js 這邊可以看到 2022 年就有的東西，在 Internet Archive 上也可以看到也是差不多時間被記錄下來的：「Saved 21 times between August 12, 2022 and January 24, 2024.」。
看起來是用 WebAssembly 包起來的，不過如果是自己的機器，本機跑 sqlite3 好像會方便一些...
這是在 Hacker News 上看到的：「Password may not contain: select, insert, update, delete, drop (uni-lj.si)」，原網站在「Password reset - ID portal」，熱鬧的地方在於原作者 (或是外包商？) 也在 Hacker News 上面回應...
禁止密碼裡面有某些字元還蠻常見的，但這次看到的很有趣 (然後被貼到 Hacker News 上)：
Your password must also not contain the following character combinations: script, select, insert, update, delete, drop, --, ', /*, */.
從網域及英文版的介面可以查到這是盧比安納大學的系統，作者 (或是外包) 在 id=39079030 提到了這是上面的要求：
Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management.
I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.
就... 很好玩？
現在應該是西方年底的假期期間，意外的看到 MariaDB 貼出 11.4.0 preview release 的消息 (當然也有可能是排程發表？)：「MariaDB 11.4.0 preview release now available」。
MariaDB 在十月的時候宣佈停掉一些周邊的產品線，「聚焦」回資料庫本體的消息後 (參考「MariaDB 停掉 SkySQL 與 Xpand」)，這兩個月累積出來的東西其實不算太多，以這次文章理列出來的來看，主要是以 replication 相關的功能為主。
另外翻了一下維基百科上的資料，MariaDB 最新的 LTS 是 10.11，支援到 2028 年二月。
目前 MariaDB 還是個很微妙的狀態，如果就 engine 來說，重新聚焦有機會拿出跟 InnoDB 可以抗衡的技術嗎？或是在 cluster 以及 sharding 拿出比較奇特的技術？
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...
不過應該也會有公司就是用下去，在上面跑的好好而且很賺錢的東西就不想亂動...
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 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 的支援只到今年十月 (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 了...
資料庫的部分，看到 AWS 在這次 re:Invent 放出「Getting started with new Amazon RDS for Db2」與「Join the preview of Amazon Aurora Limitless Database」這兩則消息。
首先是看到 Db2 這個詞覺得怪，查了以後發現原來是 2017 年改過名字正式的拼法：
The brand name was originally styled as DB/2, then DB2 until 2017 and finally changed to its present form.
這個消息比較像是補產品線，最大的資訊其實是查資料知道 2017 年改成 Db2...
另外的新產品 Amazon Aurora Limitless Database 就比較特別了，我翻了一下先前的 Amazon Aurora Serverless，是屬於利用 read replica 拓展「讀」的承載能力：
Amazon Aurora Serverless is an on-demand, autoscaling configuration for Amazon Aurora. It automatically starts up, shuts down, and scales capacity up or down based on your application's needs.
這次在 Amazon Aurora Limitless Database 裡面直接提到 sharding 技巧了，這就有機會拓展「寫」的承載能力：
Shards are Aurora PostgreSQL DB instances that each store a subset of the data for your database, allowing for parallel processing to achieve higher write throughput. Transaction routers manage the distributed nature of the database and present a single database image to database clients.
這次 preview 推出的是 PostgreSQL 15 的版本：
The preview runs in a new Aurora PostgreSQL cluster with version 15 in the AWS US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland) Regions.
這代表 database schema 不要設計的太差，是蠻有機會讓 RDS 幫你處理 sharding 底層所有需要的細節？等後續價錢出來可以看看... (應該是 open/public preview 或是 open beta 的階段)
雖然之前提過很多次 PostgreSQL 的 logical replication，但最近總算是有空實際架設起來測試，發現目前的 logical replication 還在進化的過程，只能算是階段性的產品。
在 PostgreSQL 16 的「31.6. Restrictions」裡面有列出了目前 logical replication 的限制。
第一條其實是最痛的，不支援各種 DDL 操作，所以像是 CREATE TABLE 或是 ALTER TABLE 都不會同步，這牽扯到 DBOps 的動作需要配合，DB schema 的改變會變得很詭異，需要 case by case 處理，甚至 application 端可能也會需要配合。
The database schema and DDL commands are not replicated.
另外一個頭痛的點是 sequence 資料居然不會同步，這個工具常被用到 SERIAL 類的設計 (雖然 SERIAL 被 deprecated 了)，這代表當偵測到 master 掛掉時無法直接 failover，除非有另外處理 sequence 的資料：
Sequence data is not replicated.
翻了資料發現官方 wiki 上有「Logical replication of DDLs」，裡面有今年六月的投影片：「Logical Replication of DDLs」，看起來 DDL 的部分有已經 patch 丟出來 (對 PostgreSQL 15 的 patch)，但看了 PostgreSQL 16 的 release notes 裡面還沒看到，看起來還要等...
所以 logical replication 看起來還在演進的過程，目前的限制使得 logical replication 還不到能用的成熟度。
可以繼續觀察看看...
看到「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 的優點可能就沒那麼高了...