背景

1、产品的问题点

• PG 缺少便捷的坏块修复能力

2、问题点背后涉及的技术原理

• PG 的数据通过block组织, block可以开启checksum用于校验其正确性. 如果BLOCK出现了问题checksum可能和实际计算得到的checksum对不上, 或者完全无法读出该block.
• 遇到这样的问题, 需要通过备份进行恢复.

3、这个问题将影响哪些行业以及业务场景

• 通用

4、会导致什么问题?

• 通过备份进行恢复代价非常大. 如果只是少量block出现问题, 显然代价很高.

5、业务上应该如何避免这个坑

• 目前只能通过备份恢复, 包括逻辑备份, 物理备份.

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 一旦涉及到备份恢复, 就要考虑2个问题

• • 能不能恢复到最新的状态
  • 需要多久完成恢复, 越大的实例, 可能需要花费越多时间.

• • • 虽然可以使用ZFS这种快照文件系统, 建立实时从库来解决恢复速度的问题. 但是物理坏块是可能传染的, 问题有可能传染到从库.

• 要有完整的备份, 导致成本增加
• 备份和恢复都需要资源来存储, 导致成本增加

7、数据库未来产品迭代如何修复这个坑

• 希望内核层面支持通过WAL日志(有full page write时)来修复坏块, 效率大幅度提升, 而且没有通过PITR全量恢复耗时、耗资源的问题.