背景
1、产品的问题点
2、问题点背后涉及的技术原理
- PG的备份包括2种, 1种是全量数据文件+WAL归档日志增量备份, 支持按时间点还原.
- 还原时需要全量数据文件+自从备份开始到恢复到的目标时间点的所有WAL
- 另一种是逻辑备份, 支持表级别的备份粒度, 不支持增量备份, 只能恢复到备份集的状态, 不支持按时间点还原.
- block级增量备份指的是: 只备份自从上一次备份以来修改过的数据块, 适合全量数据文件备份的加速. PG社区版本暂时不支持该功能.
- block 级的增量备份可以减少全量数据文件备份的次数.
3、这个问题将影响哪些行业以及业务场景
4、会导致什么问题?
- 按时间点还原数据库时需要全量数据文件+自从备份开始到恢复到的目标时间点的所有WAL, 恢复速度取决于有多大的数据文件, 以及有多少wal日志.
- 为了保障时间点还原的SLA, 我们必须提高全量数据文件备份的频率, 从而减少需要回放的wal个数, 从而提高PITR恢复速度.
- 问题1: 备份需要更大的存储空间.
- 问题2: 频率不可能无限提高, 对于特别大的数据库实例, 例如1天都备份不完, 那么备份频率就不能到每天一次, 因为上一次备份还没有完成, 新的备份又发起了.
- 问题3: 增加备份库的负担, 因为备份要读区数据文件, 拷贝数据文件, 增加了网络、IO开销.
5、业务上应该如何避免这个坑
- 使用 pg_rman第三方备份工具, 支持数据文件的block级别增量备份和恢复.
- pg_probackup第三方备份工具, 支持数据文件的block级别增量备份和恢复.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 不是PG社区原生功能, 品质、持续性无法保障.
- 管理复杂度增加
7、数据库未来产品迭代如何修复这个坑