背景
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时间点恢复.
