Git for Data: 瞬間克隆PG數據庫/實例

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

但數據庫呢？

想給測試環境搞一份生產數據的副本？傳統方案是pg_dump+pg_restore。一個 100GB 的庫，喝杯咖啡回來可能還沒完。想做并行測試？再等一輪。想給 AI Agent 一個可以隨便折騰的沙盒？那得準備好足夠的磁盤和耐心。

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

但這玩意，PostgreSQL 其實早就有了。

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

這不是魔法，是寫時復制（Copy-on-Write）技術終于被 PostgreSQL 原生支持了。 今天我們就來聊聊這個特性，以及它對整個"數據版本控制"生態意味著什么。

寫時復制：為什么能這么快？

PostgreSQL 18 新增了一個參數file_copy_method，可選值為copy（傳統字節拷貝）和clone（基于 reflink 的瞬間克隆）。

設置file_copy_method = clone后執行：

CREATE DATABASE db_clone TEMPLATE db STRATEGY FILE_COPY;

PostgreSQL 會調用操作系統的reflink接口。Linux 上是FICLONEioctl，macOS 上是copyfile()。

關鍵來了：文件系統不會真的復制數據。

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

沒有數據移動，只有元數據操作。所以無論數據庫是 1GB 還是 1TB，克隆時間都是常數級的 —— 在現代 NVMe SSD 上，老馮測試 120GB 的庫復制大約 200 毫秒。797G 的數據復制大概 569 毫秒左右。

寫時復制：為什么不占空間？

克隆后，源庫和新庫共享所有物理存儲。當任意一方修改某個數據頁時，文件系統才會把這個頁復制出來單獨存儲：

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

你可以同時跑 10 個克隆庫做并行測試，只要它們不大量寫入，存儲幾乎不增長。對測試環境來說，這是巨大的福音。

不過，不是所有文件系統都支持 reflink。好消息是，大多數現代 Linux 發行版已經默認啟用：

如果你用的是 EL 8/9/10、Debian 11/12/13、Ubuntu 20.04/22.04/24.04 等主流發行版，默認的 XFS 都已經支持并啟用 reflink。

還在用 CentOS 7.9 和 ext4？那確實就沒辦法了，早點升級吧。

關鍵限制：模板庫不能有連接

這個功能雖然好，有一個繞不開的限制：克隆時，模板數據庫不能有任何活動連接。 原因很直接：PostgreSQL 需要確保克隆時數據處于一致狀態。如果有連接在跑，可能產生寫入，數據就不一致了。

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

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

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

請注意，這倆語句不能分開執行，但不能放在同一個事務里執行（CREATE DATABASE不能在事務塊內運行）。 所以你需要用 psql stdin 的方式來執行，用psql -c會自動包事務，反而會失敗。

Pigsty 中的優化

在 Pigsty 4.0 中，添加了對 PG18 這種克隆機制的支持：

比如，你已經有了一個meta數據庫，現在想創建一個meta_dev的克隆庫用于測試， 只需要在pg_databases里添加一條記錄，指定template和strategy: FILE_COPY即可。 然后執行：bin/pgsql-db pg-meta meta_dev，Pigsty 會幫你自動處理好所有細節。

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

還有沒有其他手段？

當然，即使是 200ms 的不可用時間，有時候對于比較嚴格的生產環境依然是不可接受的。 而且如果你的 PG 版本不是最新的 18，也沒法用這個特性。

Pigsty 提供了兩種更強大的克隆方式，場景稍微不太一樣：

實例級克隆：pg-fork

實例級別的克隆思路和 PG18 的 CoW 類似，都需要你的文件系統支持 reflink（XFS/Btrfs/ZFS）。 之前生產環境的文件系統老馮一直都強烈推薦用 xfs，現在也是很多地方都默認，這個要求并不難滿足。

用了 xfs 之后，你可以使用cp --reflink=auto來克隆整個 PGDATA 目錄，從而克隆一個完全獨立的 PostgreSQL 實例。 這個過程也是瞬間完成的，和數據庫大小無關，而且克隆出來的不占用實際存儲，除非你開始往里面寫數據，才會觸發 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

當然，實際上細節要比這個復雜，你如果直接這么復制，大概率得到的是一個數據狀態不一致的臟實例，啟動不了。 所以還要配合 PostgreSQL 的原子備份 API 來確保數據一致性 —— 核心就是這一行：

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

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

pg-fork 1 # 克隆一個 1 號實例，/pg/data1 ，監聽 15432 端口

實例級別克隆的好處是，克隆出來的是一個完全獨立的 PostgreSQL 實例，同樣不占用額外存儲空間，同樣是瞬間完成的。 但是它不需要你關閉原始模板數據庫的連接，所以不會影響生產環境的可用性。 最多就是拉起來的時候吃掉點內存，但這種時候你就發現 PG 的雙緩沖其實也有好處了。 默認配置 25% 的 Sharedbuffer，你可以很輕松的再拉起一兩個實例。

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

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

集群級別的克隆

當然，還有一種集群層面的克隆，利用的技術也是類似的，通過使用一個集中式的備份倉庫，你可以從任意一個集群的備份中恢復到備份保留期限內的任意時間點。

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

這種方式是最傳統的 PITR ，因為沒有那種 “瞬間克隆” 的效果，就不展開介紹了。

應用場景

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

修改數據庫名，就是 Database 克隆

修改端口號，就是實例級克隆

修改主機IP，就是集群級克隆

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

而數據庫克隆有一個獨特的優點，就是這個操作是 “完全在數據庫客戶端連接” 內完成的，也就是可以通過純 SQL 來完成，不需要服務器訪問權限。 這就意味著，你可以在任何能連接到數據庫的地方，執行這個克隆操作，唯一的代價就是 200ms 左右的斷連時間。

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

AI Agent 場景：給 Agent 只開一個數據庫連接的權限，每次需要"亂搞"的時候，讓它自己克隆一個沙盒出來。搞爛了就 DROP，沒有任何代價。10 個 Agent 并行跑，存儲開銷幾乎為零。

CI/CD 場景：以前數據庫發布膽戰心驚。現在用極低成本克隆出一堆測試庫跑集成測試，DDL 遷移在真實數據上驗證完再上生產，心里有底多了。

開發環境：每個開發者一個完整的數據庫副本，數據和生產一模一樣，存儲成本趨近于零。改壞了？重新克隆一個，200 毫秒的事。

"Git for Data" 這個概念被吹了好幾年，各種創業公司融了不少錢。但 PostgreSQL 用一個簡單直接的方式給出了自己的答案：不需要額外的中間層，不需要復雜的架構，利用現代文件系統已有的能力，在數據庫內核層面原生支持。

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

有時候，最好的方案就是最簡單的方案。

點一個關注 ??，精彩不迷路