背景
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、数据库未来产品迭代如何修复这个坑
- 内核层面支持部分恢复, 例如只恢复某个表或者某个表空间或者某个数据库时, 不需要使用全量数据进行恢复.
