作者
digoal
日期
2021-09-29
标签
PostgreSQL , 坏块 , checksum , 恢复
1、产品的问题点
- PG 缺少便捷的坏块修复能力
2、问题点背后涉及的技术原理
- PG 的数据通过block组织, block可以开启checksum用于校验其正确性. 如果BLOCK出现了问题checksum可能和实际计算得到的checksum对不上, 或者完全无法读出该block.
- 遇到这样的问题, 需要通过备份进行恢复.
3、这个问题将影响哪些行业以及业务场景
- 通用
4、会导致什么问题?
- 通过备份进行恢复代价非常大. 如果只是少量block出现问题, 显然代价很高.
5、业务上应该如何避免这个坑
- 目前只能通过备份恢复, 包括逻辑备份, 物理备份.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 一旦涉及到备份恢复, 就要考虑2个问题
- 能不能恢复到最新的状态
- 需要多久完成恢复, 越大的实例, 可能需要花费越多时间.
- 虽然可以使用ZFS这种快照文件系统, 建立实时从库来解决恢复速度的问题. 但是物理坏块是可能传染的, 问题有可能传染到从库.
- 《如何创建RDS PG 的秒级 flashback闪回实例, 实时容灾实例 - zfs - snapshot - clone - standby - compress》
- 要有完整的备份, 导致成本增加
- 备份和恢复都需要资源来存储, 导致成本增加
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面支持通过WAL日志(有full page write时)来修复坏块, 效率大幅度提升, 而且没有通过PITR全量恢复耗时、耗资源的问题.
- 或者通过standby来修复坏块(类似PolarDB for PostgreSQL的功能).
PostgreSQL 许愿链接
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
9.9元购买3个月阿里云RDS PostgreSQL实例
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
