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

PostgreSQL 的 meme 與對應的解釋

看到「Explaining The Postgres Meme」這篇,很努力在解釋 PostgreSQL 的 meme:

這份 meme 的下半部意外的把很多常見的問題都涵蓋進去了,如果要做教材的話好像是個不錯的起點,不過要注意有些不是專屬 PostgreSQL 的 meme 也有被放進去。

裡面有很多都還不熟悉,之前在 MySQL 陣營太久了,很多東西都不會想要讓 MySQL 處理... (或是無法在在 MySQL 處理)

窮舉 PostgreSQL 的 LOCK 機制

PostgreSQL Lock Conflicts 這份資料窮舉了 PostgreSQL 的 lock 機制,分成兩種方式呈現:

  • 依照 Lock:文內列出 12 種 lock。
  • 依照 Command:文內列出了 67 種指令。

可以交叉查,用 lock 查出有哪些 command 有用到,或是反過來用 command 查會產生那些 lock:

This tool shows all commands and locks in postgres. If you select a command, it lists the locks that it acquires, commands that conflicts with it and commands that are allowed to run concurrently with it (with no conflict or blocking). If you select a lock, it lists commands that acquire the lock and what are the other conflicting locks.

舉個例子來說,Lock 列表裡的第一個,AccessShareLock,這個點進去後可以看到有三個指令會有使用到 AccessShareLock 的情境,分別是 SELECTCOPY TO 以及 ALTER TABLE ADD FOREIGN KEY (PARENT)

是個更熟悉 PostgreSQL 的路徑?

HashiCorp 內 scale 的方法

去日本前在 Hacker News 上看到「Squeeze the hell out of the system you have」這篇,用作者的名字翻了一下 LinkedIn,看起來講的是 HashiCorpSRE 事情:「Dan Slimmon」。

看的時候可以注意一下,文章裡面的觀點未必要認同,大多是他自己的看法或是想法,但裡面提到很多發生的事情,可以知道 HashiCorp 內目前搞了什麼東西。

從 LinkedIn 的資料可以看到他從 2019 就加入 HashiCorp 了,所以文章一開頭這邊講的同事應該就是 HashiCorp 的同事:

About a year ago, I raised a red flag with colleagues and managers about Postgres performance.

往下看可以看到他們有遇到 PostgreSQL 的效能問題,然後每次都是以 scale up (加大機器) 的方式解決,考慮到 HashiCorp 的產品線,我會猜應該是 Terraform Cloud 這個產品線遇到的狀況。

然後在後面提到的解法則是提到了 codebase 是 Rails,他們花了三個月的時候不斷的重複 profiling + optimizing,包括 SQL 與 PostgreSQL 的設定:

Two engineers (me and my colleague Ted – but mostly Ted) spent about 3 months working primarily on database performance issues. There was no silver bullet. We used our telemetry to identify heavy queries, dug into the (Rails) codebase to understand where they were coming from, and optimized or eliminated them. We also tuned a lot of Postgres settings.

另外一組人則是弄了 read-only replication server,把 loading 拆出去:

Two more engineers cut a path through the codebase to run certain expensive read-only queries on a replica DB. This effort bore fruit around the same time as (1), when we offloaded our single most frequent query (a SELECT triggered by polling web clients).

這兩個方法大幅降低了資料庫的 peak loading,從 90% 降到 30%:

These two efforts together reduced the maximum weekly CPU usage on the database from 90% to 30%.

可以看到都還沒用到 sharding 的技巧,目前硬體的暴力程度可以撐很久 (而且看起來是在沒有投入太多資源在 DB-related tuning 上面),快撞到的時候也還可以先用 $$ 換效能,然後投入人力開始 profiling 找問題...

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

看到 Percona 寫的「LTS and Innovation Releases for Percona Server for MySQL」這篇,才注意到 Oracle 宣佈了 MySQLLTS 版本:「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 的消息。

SQLite 官方自己搞的 Cloud Backed SQLite

SQLite 自己搞了一套使用雲端空間為儲存空間的技術:「Cloud Backed SQLite」,對應的 Hacker News 討論可以看「Cloud Backed SQLite (sqlite.org)」這邊。

他說目前支援 Azure Blob StorageGoogle Cloud Storage,這點比較有趣,沒有提到 Amazon S3

The system currently supports Azure Blob Storage and Google Cloud Storage. It also features an API that may be used to implement support to other cloud storage systems.

跟之前的 sql.js 專案不太一樣,sql.js 的作法是用 HTTP range 存取現有的 SQLite 資料庫檔案,而這次的這個專案則是改變底層架構,去配合雲端環境的特點。

雲端的 storage 因為每個 access 都會有很高的 latency (相比於本地的空間),所以要避免太多 random access,儘量以 sequential access 為主,這個特性像是以前在處理傳統磁頭硬碟時的技巧。

另外一個特點是雲端空間有多檔案的概念,所以也可以利用這個方式設計資料結構。

還蠻有趣的計畫,而且是官方搞的...

AWS Aurora Xanadu?

在「Why PostgreSQL High Availability Matters and How to Achieve It (yugabyte.com)」裡面看到 AWS 也在研發類似 GCP 提供的 Spanner 的服務,計畫名稱叫做 Aurora Xanadu:「36328981」。

franckpachot

Google has Spanner. AWS is working on something similar (project Aurora Xanadu). And both have YugabyteDB in their marketplace. Those are Distributed SQL (Global ACID), not Citus. For DataWarehouse which doesn't need ACID, there are other services.

也先把這個連結備份起來,看看後面是不是直接拿這個名字來用?

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.

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

MariaDB 嘗試相容於 PostgreSQL 協定的產品

Twitter 上看到的消息,新聞在「MariaDB's Xpand offers PostgreSQL compatibility without the forking drama」這邊:

看起來是 SkySQL 的服務,這樣聽起來不像會 open source... 看起來賣點在於 globally distributed RDBMS 這個部分:

MariaDB is previewing a PostgreSQL-compatible front end in its SkySQL Database-as-a-Service which provides a globally distributed RDBMS on the back end.

再看看後續會不會有更多消息?

SQL:2023 的新玩意

Hacker News 上看到「SQL: 2023 is finished: Here is what's new (eisentraut.org)」這篇題到了 SQL:2023 標準的新東西,對應的原文在「SQL:2023 is finished: Here is what's new」這邊。

「UNIQUE null treatment (F292)」讓你可以決定 NULL 到底要不要算 unique,剛好跟之前寫過的「PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了」要做的事情一樣。

「ORDER BY in grouped table (F868)」則是針對沒有出現在 SELECT 的欄位頁可以 ORDER BY,看了一下說明,主要是在 JOIN 的時候限制住了。很明顯的 workaround 是多加上這個欄位,但就代表會增加傳回的資料量。

「GREATEST and LEAST (T054)」這個因為 MIN()MAX() 已經被 aggregate function 用掉了,所以只好另外取名。

「String padding functions (T055)」與「Multi-character TRIM functions (T056)」是熟悉的語法,各家都有對應的 function 可以做,但這次就放進標準化。

「Optional string types maximum length (T081)」是 VARCHAR 可以不用指定大小了,實務上應該是還好?

「Enhanced cycle mark values (T133)」這編提到的 recursive 真的是每次用每次忘,然後 cycle 這個功能就沒看懂了...

「ANY_VALUE (T626)」看起來可以隨機取出資料,搭配 GROUP BY '' 就不用拿 ORDER BY RAND() 這種髒髒的東西出來了?

「Non-decimal integer literals (T661)」與「Underscores in numeric literals (T662)」都是讓數字更好讀以及操作。

後面講了很多 JSON 功能,看起來是 SQL:2016 有先納入一些,但 SQL:2023 補的更完整了。

然後有 Graph 相關的標準也被定義進 SQL:2023,原文介紹的也不是很多,看起來是要跨足過來?