Git for Data: 瞬間克隆PG數(shù)據(jù)庫/實(shí)例

每個(gè)程序員都用過git clone。敲下回車，幾秒鐘后，一個(gè)完整的代碼倉庫就躺在硬盤上了。

但數(shù)據(jù)庫呢？

想給測(cè)試環(huán)境搞一份生產(chǎn)數(shù)據(jù)的副本？傳統(tǒng)方案是pg_dump+pg_restore。一個(gè) 100GB 的庫，喝杯咖啡回來可能還沒完。想做并行測(cè)試？再等一輪。想給 AI Agent 一個(gè)可以隨便折騰的沙盒？那得準(zhǔn)備好足夠的磁盤和耐心。

最近一堆數(shù)據(jù)庫公司都在卷 "Git for Data"，理由是：有了數(shù)據(jù)版本控制，Agent 就可以放心在數(shù)據(jù)庫里亂搞，壞了隨時(shí)回滾。

但這玩意，PostgreSQL 其實(shí)早就有了。

只不過PostgreSQL 18 把它提升到了一個(gè)新階段：一個(gè) 100GB 的數(shù)據(jù)庫，克隆時(shí)間從"分鐘級(jí)"變成了200 毫秒。不是快了一點(diǎn)，是快了幾百倍。更神奇的是，克隆完的數(shù)據(jù)庫不占用額外存儲(chǔ)空間。1TB、10TB 的庫？一樣是 200 毫秒，一樣零額外開銷。

這不是魔法，是寫時(shí)復(fù)制（Copy-on-Write）技術(shù)終于被 PostgreSQL 原生支持了。 今天我們就來聊聊這個(gè)特性，以及它對(duì)整個(gè)"數(shù)據(jù)版本控制"生態(tài)意味著什么。

寫時(shí)復(fù)制：為什么能這么快？

PostgreSQL 18 新增了一個(gè)參數(shù)file_copy_method，可選值為copy（傳統(tǒng)字節(jié)拷貝）和clone（基于 reflink 的瞬間克隆）。

設(shè)置file_copy_method = clone后執(zhí)行：

CREATE DATABASE db_clone TEMPLATE db STRATEGY FILE_COPY;

PostgreSQL 會(huì)調(diào)用操作系統(tǒng)的reflink接口。Linux 上是FICLONEioctl，macOS 上是copyfile()。

關(guān)鍵來了：文件系統(tǒng)不會(huì)真的復(fù)制數(shù)據(jù)。

它只是創(chuàng)建一組新的元數(shù)據(jù)指針，指向相同的物理磁盤塊。就像你在文件管理器里創(chuàng)建了一個(gè)"快捷方式"，但這個(gè)快捷方式可以獨(dú)立修改。

沒有數(shù)據(jù)移動(dòng)，只有元數(shù)據(jù)操作。所以無論數(shù)據(jù)庫是 1GB 還是 1TB，克隆時(shí)間都是常數(shù)級(jí)的 —— 在現(xiàn)代 NVMe SSD 上，老馮測(cè)試 120GB 的庫復(fù)制大約 200 毫秒。797G 的數(shù)據(jù)復(fù)制大概 569 毫秒左右。

寫時(shí)復(fù)制：為什么不占空間？

克隆后，源庫和新庫共享所有物理存儲(chǔ)。當(dāng)任意一方修改某個(gè)數(shù)據(jù)頁時(shí)，文件系統(tǒng)才會(huì)把這個(gè)頁復(fù)制出來單獨(dú)存儲(chǔ)：

這意味著：存儲(chǔ)開銷 = 實(shí)際變更量，而不是完整副本。

你可以同時(shí)跑 10 個(gè)克隆庫做并行測(cè)試，只要它們不大量寫入，存儲(chǔ)幾乎不增長(zhǎng)。對(duì)測(cè)試環(huán)境來說，這是巨大的福音。

不過，不是所有文件系統(tǒng)都支持 reflink。好消息是，大多數(shù)現(xiàn)代 Linux 發(fā)行版已經(jīng)默認(rèn)啟用：

如果你用的是 EL 8/9/10、Debian 11/12/13、Ubuntu 20.04/22.04/24.04 等主流發(fā)行版，默認(rèn)的 XFS 都已經(jīng)支持并啟用 reflink。

還在用 CentOS 7.9 和 ext4？那確實(shí)就沒辦法了，早點(diǎn)升級(jí)吧。

關(guān)鍵限制：模板庫不能有連接

這個(gè)功能雖然好，有一個(gè)繞不開的限制：克隆時(shí)，模板數(shù)據(jù)庫不能有任何活動(dòng)連接。 原因很直接：PostgreSQL 需要確保克隆時(shí)數(shù)據(jù)處于一致狀態(tài)。如果有連接在跑，可能產(chǎn)生寫入，數(shù)據(jù)就不一致了。

這個(gè)限制其實(shí)一直都有。以前它很致命 —— 你不可能讓生產(chǎn)庫停機(jī)幾分鐘等復(fù)制完成。但現(xiàn)在克隆只要亞秒級(jí)常數(shù)時(shí)間，這個(gè)限制的殺傷力大大降低了。 百毫秒級(jí)別的閃斷，對(duì)于很多場(chǎng)景是可以接受的，特別是那些 AI Agent 使用的庫——它們沒那么嬌氣。這就帶來了許多新鮮的可能性。

實(shí)操的話，要想實(shí)際把這個(gè)數(shù)據(jù)庫克隆出來，你需要先終止所有連接，在兩條緊挨著 SQL 語句里執(zhí)行：

psql <-EOF
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'prod';
CREATE DATABASE dev TEMPLATE prod STRATEGY FILE_COPY;
EOF

請(qǐng)注意，這倆語句不能分開執(zhí)行，但不能放在同一個(gè)事務(wù)里執(zhí)行（CREATE DATABASE不能在事務(wù)塊內(nèi)運(yùn)行）。 所以你需要用 psql stdin 的方式來執(zhí)行，用psql -c會(huì)自動(dòng)包事務(wù)，反而會(huì)失敗。

Pigsty 中的優(yōu)化

在 Pigsty 4.0 中，添加了對(duì) PG18 這種克隆機(jī)制的支持：

比如，你已經(jīng)有了一個(gè)meta數(shù)據(jù)庫，現(xiàn)在想創(chuàng)建一個(gè)meta_dev的克隆庫用于測(cè)試， 只需要在pg_databases里添加一條記錄，指定template和strategy: FILE_COPY即可。 然后執(zhí)行：bin/pgsql-db pg-meta meta_dev，Pigsty 會(huì)幫你自動(dòng)處理好所有細(xì)節(jié)。

當(dāng)然其實(shí)這里的細(xì)節(jié)還是不少的，比如，你要確保file_copy_method被正確設(shè)置為clone才有這個(gè)特性，這個(gè) Pigsty 創(chuàng)建的集群全都已經(jīng)針對(duì) PG18+ 都配置好了。 如果你要克隆的數(shù)據(jù)庫就是管理數(shù)據(jù)庫postgres本身怎么辦 (克隆的時(shí)候不允許連接)。再比如，克隆數(shù)據(jù)庫之前要先終止所有連接，這些都幫你自動(dòng)搞定了。

還有沒有其他手段？

當(dāng)然，即使是 200ms 的不可用時(shí)間，有時(shí)候?qū)τ诒容^嚴(yán)格的生產(chǎn)環(huán)境依然是不可接受的。 而且如果你的 PG 版本不是最新的 18，也沒法用這個(gè)特性。

Pigsty 提供了兩種更強(qiáng)大的克隆方式，場(chǎng)景稍微不太一樣：

實(shí)例級(jí)克隆：pg-fork

實(shí)例級(jí)別的克隆思路和 PG18 的 CoW 類似，都需要你的文件系統(tǒng)支持 reflink（XFS/Btrfs/ZFS）。 之前生產(chǎn)環(huán)境的文件系統(tǒng)老馮一直都強(qiáng)烈推薦用 xfs，現(xiàn)在也是很多地方都默認(rèn)，這個(gè)要求并不難滿足。

用了 xfs 之后，你可以使用cp --reflink=auto來克隆整個(gè) PGDATA 目錄，從而克隆一個(gè)完全獨(dú)立的 PostgreSQL 實(shí)例。 這個(gè)過程也是瞬間完成的，和數(shù)據(jù)庫大小無關(guān)，而且克隆出來的不占用實(shí)際存儲(chǔ)，除非你開始往里面寫數(shù)據(jù)，才會(huì)觸發(fā) CoW。

postgres@vonng-aimax:/pg$ du -sh data
797G data
postgres@vonng-aimax:/pg$ time cp -r data data2

real 0m0.586s
user 0m0.014s
sys 0m0.569s

當(dāng)然，實(shí)際上細(xì)節(jié)要比這個(gè)復(fù)雜，你如果直接這么復(fù)制，大概率得到的是一個(gè)數(shù)據(jù)狀態(tài)不一致的臟實(shí)例，啟動(dòng)不了。 所以還要配合 PostgreSQL 的原子備份 API 來確保數(shù)據(jù)一致性 —— 核心就是這一行：

psql <CHECKPOINT;
SELECT pg_backup_start('pgfork', true);
\! rm -rf /pg/data2 && cp -r --reflink=auto /pg/data /pg/data2
SELECT * FROM pg_backup_stop(false);
EOF

當(dāng)然實(shí)際上各種邊界情況要復(fù)雜一些，比如克隆出來的實(shí)例如果你要拉起來，不能擠占原來實(shí)例的端口， 不能寫臟原來生產(chǎn)實(shí)例的日志/WAL歸檔，諸如此類細(xì)節(jié)。所以 Pigsty v4 就提供了一個(gè)傻瓜式的克隆腳本pg-fork來解決這個(gè)問題。

pg-fork 1 # 克隆一個(gè) 1 號(hào)實(shí)例，/pg/data1 ，監(jiān)聽 15432 端口

實(shí)例級(jí)別克隆的好處是，克隆出來的是一個(gè)完全獨(dú)立的 PostgreSQL 實(shí)例，同樣不占用額外存儲(chǔ)空間，同樣是瞬間完成的。 但是它不需要你關(guān)閉原始模板數(shù)據(jù)庫的連接，所以不會(huì)影響生產(chǎn)環(huán)境的可用性。 最多就是拉起來的時(shí)候吃掉點(diǎn)內(nèi)存，但這種時(shí)候你就發(fā)現(xiàn) PG 的雙緩沖其實(shí)也有好處了。 默認(rèn)配置 25% 的 Sharedbuffer，你可以很輕松的再拉起一兩個(gè)實(shí)例。

更妙的是，這種克隆出來的實(shí)例，還可以通過pg-pitr腳本，利用基于 pgBackRest 的備份，做時(shí)間點(diǎn)恢復(fù)（PITR）。 而且這個(gè)時(shí)間點(diǎn)恢復(fù)也是增量進(jìn)行的，所以速度也很快。

這種機(jī)制最直接的應(yīng)用場(chǎng)景就是，誤刪數(shù)據(jù)了，但是刪的又不多，不至于全庫回檔。 那么這種情況下，就可以使用pg-fork腳本，瞬間克隆出一個(gè)和生產(chǎn)庫一模一樣的副本， 然后原地 pg-pitr 增量回滾到幾分鐘前，拉起來，把誤刪的數(shù)據(jù)查出來再寫回去。

集群級(jí)別的克隆

當(dāng)然，還有一種集群層面的克隆，利用的技術(shù)也是類似的，通過使用一個(gè)集中式的備份倉庫，你可以從任意一個(gè)集群的備份中恢復(fù)到備份保留期限內(nèi)的任意時(shí)間點(diǎn)。

這種方式的集群克隆不用消耗原本生產(chǎn)集群的任何資源，云上的各種 “PITR” 其實(shí)就是這種方式，給你拉起一套新的集群，恢復(fù)到指定時(shí)間點(diǎn)。但是這種方式的速度就慢多了，畢竟要把數(shù)據(jù)從備份倉庫里拉出來，恢復(fù)到新的集群上，時(shí)間和數(shù)據(jù)量成正比。

這種方式是最傳統(tǒng)的 PITR ，因?yàn)闆]有那種 “瞬間克隆” 的效果，就不展開介紹了。

應(yīng)用場(chǎng)景

三種克隆方式，各有適用場(chǎng)景，也很好理解，連接串五要素里面，去掉用戶名和密碼， 有三個(gè)要素可以修改：

修改數(shù)據(jù)庫名，就是 Database 克隆

修改端口號(hào)，就是實(shí)例級(jí)克隆

修改主機(jī)IP，就是集群級(jí)克隆

雖然已經(jīng)有了pg-fork這種實(shí)例級(jí)的 “瞬間克隆” 技術(shù)，而且沒有數(shù)據(jù)庫模版克隆要求幾百毫秒停機(jī)時(shí)間的限制。 但這種操作要求你必須擁有數(shù)據(jù)庫服務(wù)器的文件系統(tǒng)訪問權(quán)限。而且你克隆出來的實(shí)例也僅限于在同一臺(tái)機(jī)器上運(yùn)行 —— 從庫上是沒有的。

而數(shù)據(jù)庫克隆有一個(gè)獨(dú)特的優(yōu)點(diǎn)，就是這個(gè)操作是 “完全在數(shù)據(jù)庫客戶端連接” 內(nèi)完成的，也就是可以通過純 SQL 來完成，不需要服務(wù)器訪問權(quán)限。 這就意味著，你可以在任何能連接到數(shù)據(jù)庫的地方，執(zhí)行這個(gè)克隆操作，唯一的代價(jià)就是 200ms 左右的斷連時(shí)間。

這就打開了一扇新的大門：

AI Agent 場(chǎng)景：給 Agent 只開一個(gè)數(shù)據(jù)庫連接的權(quán)限，每次需要"亂搞"的時(shí)候，讓它自己克隆一個(gè)沙盒出來。搞爛了就 DROP，沒有任何代價(jià)。10 個(gè) Agent 并行跑，存儲(chǔ)開銷幾乎為零。

CI/CD 場(chǎng)景：以前數(shù)據(jù)庫發(fā)布膽戰(zhàn)心驚。現(xiàn)在用極低成本克隆出一堆測(cè)試庫跑集成測(cè)試，DDL 遷移在真實(shí)數(shù)據(jù)上驗(yàn)證完再上生產(chǎn)，心里有底多了。

開發(fā)環(huán)境：每個(gè)開發(fā)者一個(gè)完整的數(shù)據(jù)庫副本，數(shù)據(jù)和生產(chǎn)一模一樣，存儲(chǔ)成本趨近于零。改壞了？重新克隆一個(gè)，200 毫秒的事。

"Git for Data" 這個(gè)概念被吹了好幾年，各種創(chuàng)業(yè)公司融了不少錢。但 PostgreSQL 用一個(gè)簡(jiǎn)單直接的方式給出了自己的答案：不需要額外的中間層，不需要復(fù)雜的架構(gòu)，利用現(xiàn)代文件系統(tǒng)已有的能力，在數(shù)據(jù)庫內(nèi)核層面原生支持。

幾百毫秒，沒有額外存儲(chǔ)，一條 SQL 搞定。

有時(shí)候，最好的方案就是最簡(jiǎn)單的方案。

點(diǎn)一個(gè)關(guān)注 ??，精彩不迷路