Category: MariaDB

翻資料的時候翻到「pg-osc: Zero downtime schema changes in PostgreSQL」這篇文章，可以在 PostgreSQL 上做到類似 pt-online-schema-change 的事情，這邊先提一下 pt-online-schema-change 的說明：

ALTER tables without locking them.

不管是 MySQL 還是 PostgreSQL，都會遇到 ALTER TABLE 常常會 lock 的問題，這點主要的影響就是 db migration。

在 dev 環境的機器應該沒什麼問題，資料量都不大，應該是很快就可以跑完；但在 stage 環境時就會開始有狀況了 (假設是從 production 複製過來的資料，表格的大小可能偏大)，但應該還是可以用 downtime 換，慢慢跑，花幾個小時把 db migration 跑完。

可是到了 production 環境時就不太能這樣搞了，這也是一般不太建議在 production 環境裡用現成的 db migration 工具，尤其當資料量偏大的時候。

解這個問題的方法就是透過繞路的方式，不要直接動原來的 table：基本的想法是開一個新的 table，然後一直從舊的 table 搬資料到新的 table 上 (包括應用程式下指令寫到舊的 table 上的資料)，直到最後用一個短暫的 lock 機制來切換 table。

在 MySQL 的世界裡比較有名的是 Percona 的 pt-online-schema-change (trigger-based) 以及 GitHub 的 gh-ost (replication-based)，另外找資料的時候有發現 Facebook 也有丟 OnlineSchemaChange (trigger-based) 出來。

在 PostgreSQL 的世界裡似乎是 pg_repack 這個方案，用了 trigger-based 的方式處理，但之前沒有注意到，是翻 pg-osc 的時候被提到才知道有這個工具。

而這次提到的 pg-osc 則是 2022 年才出的軟體，也是 trigger-based 的方式：

pg-osc uses the concept of shadow tables to perform schema changes. At a high level, it creates a shadow table that looks structurally the same as the primary table, performs the schema change on the shadow table (avoiding any locks since nothing is using this table), copies contents from the primary table to the shadow table and swaps the table names in the end while preserving all changes to the primary table using triggers (via audit table).

另外從 PostgreSQL 的 wiki 上看到「Change management tools and techniques」這頁，裡面看到「Metagration: Logical PostgreSQL Migration」這個工具，看起來好像是 replication-based 的方案，不過還是有用到一些 trigger 做事。

這些方案都先記錄起來好了...