背景

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、数据库未来产品迭代如何修复这个坑

• 内核层面支持部分恢复, 例如只恢复某个表或者某个表空间或者某个数据库时, 不需要使用全量数据进行恢复.