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

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

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

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

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

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

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

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

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

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

CREATE DATABASE db_clone TEMPLATE db STRATEGY FILE_COPY;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實操的話，要想實際把這個數(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

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

Pigsty 中的優(yōu)化

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

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

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

還有沒有其他手段？

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

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

實例級克?。簆g-fork

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

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

當然，實際上細節(jié)要比這個復雜，你如果直接這么復制，大概率得到的是一個數(shù)據(jù)狀態(tài)不一致的臟實例，啟動不了。 所以還要配合 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

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

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

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

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

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

集群級別的克隆

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

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

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

應用場景

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

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

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

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

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

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

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

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

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

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

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

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

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

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