【DB吐槽大会】第10期 - 不支持 flashback query

背景

1、产品的问题点

• 没有Query级别的闪回功能, 当发生DML误操作后, 恢复数据比较困难.

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

• flashback query属于查询“数据”在过去某个时刻的状态, 实现方法举例:
• 需要有旧的tuple版本, 以及事务提交或回滚状态, 事务结束时间的信息.

• 这种实现方法需要保留旧版本和事务结束时间, 可能导致UNDO数据膨胀.

• 或: 采用快照, 通过快照+WAL回放的形式回到过去状态.

• 这种实现方法需要支持快照, 可能导致额外的copy on write开销

• 最好仅仅针对重点表开启闪回功能.

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

• 所有行业

4、会导致什么问题?

• 发生DML误操作后, 依赖备份+时间点恢复功能. 恢复数据比较困难.

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

• 数据备份+WAL归档, 时间点恢复后将数据导出, 再导入到生产环境.
• 使用触发器, 将DML的UNDO操作记录下来, 使用UNDO语句回滚.
• 使用快照文件系统, 例如ZFS, 在ZFS上建立物理流复制从库, 当需要恢复时通过快照+WAL回放的形式回到过去状态. 将数据导出, 再导入到生产环境.

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

• 管理难道较大, 一般开发人员不懂, 较为复杂度

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

• 内核层支持: 表级别多版本管理, 同时使用UNDO回滚段代替数据文件内存储多版本.
• 内核层支持, partial PIRT. 表级别的数据文件+WAL时间点恢复.