【DB吐槽大會】第24期 - PG 不支援Partial PITR

背景

1、産品的問題點

• PG 不支援Partial PITR

2、問題點背後涉及的技術原理

• PG 通過過去的全量資料檔案備份 + 持續的增量的歸檔日志備份 可以恢複到過去的指定時間點.

3、這個問題将影響哪些行業以及業務場景

• 通用行業

4、會導緻什麼問題?

• 即使業務上隻需要恢複少部分資料, 也需要全量資料+歸檔進行恢複.

• • 耗時更長
  • 需要使用更大的存儲空間來進行恢複, 對于大執行個體隻需要恢複少量資料的場景非常不友好.

5、業務上應該如何避免這個坑

• 為了加快恢複速度, 以及使用更少的空間來恢複, 可以使用快照檔案系統進行備份, 例如ZFS.

• • 《如何建立RDS PG 的秒級 flashback閃回執行個體, 實時容災執行個體 - zfs - snapshot - clone - standby - compress》
  • 《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)驗證 - recovery test script for zfs snapshot clone + postgresql stream replication + archive》
  • 《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)雙機HA與塊級備份部署》
  • 《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)單個資料庫采用多個zfs卷(如表空間)時如何一緻性備份》
  • 《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)備份集有效性自動校驗》
  • 《PostgreSQL 最佳實踐 - 塊級增量備份(ZFS篇)方案與實戰》

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 管理成本增加, 一般使用者不懂

7、資料庫未來産品疊代如何修複這個坑

• 核心層面支援部分恢複, 例如隻恢複某個表或者某個表空間或者某個資料庫時, 不需要使用全量資料進行恢複.