2026-04-28 — pgclone 4.0.0 SQL 複製、ClickHouse Index Sharding PB 級、pgBackRest 停止維護

pgclone 4.0.0：以純 SQL 實現 PostgreSQL 資料庫複製與資料遮罩

PostgreSQL News Archive · 2026-04-27

pgclone 4.0.0 於 2026 年 4 月 27 日在 PostgreSQL News Archive 公告，為一個以 PostgreSQL 擴充形式提供的資料庫複製與資料遮罩工具，支援 PostgreSQL 14–18，以 PostgreSQL Licence 授權。

架構設計

pgclone 以 Background Worker（BGW）實作並行複製：主控端連線送出 SQL 指令後，BGW 在 PostgreSQL 伺服器端以 COPY 協定進行資料傳輸，不依賴外部 shell 工具或 pg_dump/pg_restore。進度可透過 pgclone.jobs_view 視圖即時查詢。

SQL 介面

複製操作完全以 SQL 執行，適用於 psql 或任何 PostgreSQL 用戶端：

-- 複製整個資料庫
SELECT pgclone.clone_database('source_db', 'target_db');

-- 複製指定 schema
SELECT pgclone.clone_schema('source_db', 'public', 'target_db', 'backup_schema');

-- 複製單一資料表並套用資料遮罩
SELECT pgclone.clone_table(
    'source_db', 'public', 'users',
    'target_db', 'public', 'users',
    mask_rules => ARRAY[
        pgclone.mask_email('email'),
        pgclone.mask_hash('phone_number')
    ]
);

DDL 保留範圍

複製操作完整保留：索引、主鍵/UNIQUE/CHECK/外鍵/EXCLUDE 約束、觸發器、視圖、序列。衝突解決策略可選擇 error（衝突即報錯）、skip（跳過衝突物件）、replace（覆蓋既有物件）或 rename（重命名以避免衝突）。

自動敏感欄位探索

Auto-Discovery 功能掃描來源 schema，識別名稱或型別符合敏感資料模式（email、name、phone、hash 等）的欄位，並自動建議遮罩規則，降低了在大型 schema 中手動列舉需要遮罩欄位的工作量。

原始來源：PostgreSQL News — pgclone 4.0.0、pgclone GitHub

ClickHouse Cloud Index Sharding：一致性雜湊將索引分析橫向擴展至 PB 級

ClickHouse Blog · 2026-04-21

ClickHouse Cloud 推出 Index Sharding（目前為 Private Preview，適用於 SharedMergeTree 資料表），透過在副本間分散索引分析工作，解決了 PB 級資料表中索引記憶體消耗線性成長的問題。

問題根源

傳統副本架構中，每個副本需在記憶體中維護完整的主鍵索引與跳躍索引（skip indices，包含 Bloom Filter、向量索引、全文索引）。一個 100 GB 的主鍵索引在 12 個副本上累計消耗 1.2 TB——這些記憶體無法用於查詢處理，且隨副本數線性增長，使水平擴展的成本效益急劇惡化。

架構實作：虛擬雜湊環

Index Sharding 以一致性雜湊（consistent hashing）在虛擬雜湊環上分配 data part 的索引分析責任：

查詢發起者接收請求後，透過一致性雜湊將各 data part 的索引分析任務分派給特定副本
各副本僅分析其負責的 data part 子集，回傳匹配的 granule 範圍
發起者合併各副本的結果，生成完整的查詢執行計畫
資料讀取照常透過 parallel replicas 進行

啟動條件：data part 數量 ≥ 10（distributed_index_analysis_min_parts_to_activate）且未壓縮索引總大小 ≥ 1 GB（distributed_index_analysis_min_indexes_bytes_to_activate），兩者均為資料表級設定。

效能基準（50 億行資料表，17,000 個 data parts，10 個副本）

查詢類型	無分片	有分片	加速倍數
主鍵範圍	1.0s	0.23s	4.3×
Bloom Filter 點查	8.5s	1.1s	7.7×
向量搜尋	6.5s	0.9s	7.2×
全文搜尋	3.1s	0.53s	5.8×

從 10 個副本擴展至 20 個，依查詢類型獲得額外 1.4–1.7× 加速，驗證了近線性的橫向擴展能力。記憶體測試：16 GB 索引在 10 個副本上，每個副本的索引工作記憶體僅佔 3.41–3.84 MB。

容錯機制

當指定副本的索引分析失敗（網路問題、資料未載入等），系統自動降級到查詢發起者本地分析，確保可用性不依賴分片機制的完整性。

原始來源：ClickHouse Blog — Index Sharding

pgBackRest 停止維護：首席維護者離任，十三年 PostgreSQL 備份工具走入歷史

LWN.net / GitHub · 2026-04-27

PostgreSQL 備份工具 pgBackRest 的倉庫於 2026 年 4 月下旬被標記為 archived，首席維護者 David Steele 宣告在維持 13 年後終止開發。

技術背景

pgBackRest 以 Perl 撰寫（後期以 C 重寫核心），提供 PostgreSQL 的增量備份、PITR（Point-In-Time Recovery）、並行備份/還原、加密、以及 S3/Azure/GCS 雲端儲存整合。其 WAL archiving 與 pg_hba.conf/recovery.conf 的緊密整合使它成為複雜 HA 部署的標準組件，在 Crunchy Data 的 PostgreSQL Operator for Kubernetes（PGO）中被廣泛使用。

停止維護的經過

Steele 表示，Crunchy Data 被收購後，他在尋求替代雇主或贊助方以繼續 pgBackRest 維護工作的過程中未能取得足夠支持——贊助額度「遠低於維持專案所需」。此事件再次凸顯關鍵開源基礎設施對單一商業贊助者的依賴風險（類似 2022 年 core-js 事件）。

替代方案

PostgreSQL 生態系中的備份替代方案包含：Barman（2ndQuadrant/EDB 維護，Python，支援 PostgreSQL 9.4+）；WAL-G（Go 實作，支援 PostgreSQL、MySQL、MongoDB，具備增量備份與雲端儲存整合）；以及 Kubernetes 環境中的 CloudNativePG operator 內建備份機制。Crunchy Data 已在其 PGO v5 路線圖中規劃遷移至 WAL-G。

原始來源：LWN — pgBackRest is no longer maintained、pgbackrest/pgbackrest

End of article