【dba 进阶教程共建投稿】oceanbase后悔药 —— 误操作恢复指南-c7电子娱乐

引言

在数据库管理中，误操作是一个常见但令人头疼的问题。无论是意外删除了重要数据、修改了关键配置，还是执行了错误的sql语句，这些误操作都可能导致业务中断或数据丢失。幸运的是，oceanbase 提供了一系列机制和工具来帮助我们从误操作中恢复。本文将介绍几种有效的恢复方法，为那些可能犯错的管理员们提供一份“后悔药”。

一、备份与还原

1.1 定期备份的重要性

预防总是胜于治疗。定期进行全量和增量备份是防止数据丢失的第一道防线。oceanbase 支持多种备份方式，包括物理备份和逻辑备份。

• 物理备份：3.x后期版本支持集群级别的备份 归档，和单独的租户全备。4.x支持租户级别的备份 归档。
• 逻辑备份：导出表结构和数据，适合小规模或特定表的数据备份。

1.2 还原策略

当发生误操作时，可以从最近一次成功的备份中恢复数据。确保你有一个清晰的还原计划，并且测试过整个流程以保证其有效性。可以按照时间点恢复整个租户或者部分表。

单表恢复可以参考下 。

二、闪回（flashback）

oceanbase 提供了强大的闪回功能，允许用户快速恢复到某个时间点的状态。这对于纠正短时间内的误操作非常有用。可以闪回的时间跟undo_retention大小有关系默认是1800s，该值确保可以闪回30分钟内的数据（如果未发生转储可以闪回更早的数据，该值确保的是可闪回的下限，并非上限），以及未合并前的转储时间点前30分钟的区间数据。

2.1 表级闪回

如果只是某张表受到了影响，可以通过以下命令将其恢复到指定的时间点：

##mysql根据as of snapshot 指定历史时间

--snapshot转换
obclient [(none)]> select time_to_usec('2020-08-13 16:20:00') * 1000;
 -------------------------------------------- 
| time_to_usec('2022-01-01 00:00:00') * 1000 |
 -------------------------------------------- 
|                        1597306800000000000 |
 -------------------------------------------- 
--闪回查询
select * from table1 as of snapshot 1597306800000000000;

##oracle可以指定scn和时间点闪回

--scn转换
obclient [(none)]> select (to_date('2020-08-13 16:20:00','yyyy-mm-dd hh24:mi:ss') - to_date('1970-01-01 08:00:00', 'yyyy-mm-dd hh24:mi:ss')) * 86400 * 1000 * 1000 * 1000 as unix_nsec_timestamp from dual;
 --------------------- 
| unix_nsec_timestamp |
 --------------------- 
| 1597306800000000000 |
 --------------------- 
1 row in set
--按照scn闪回
obclient [sys]> select * from table1 as of scn 1597306800000000000;
--按照时间闪回
obclient [sys]> select * from table1 as of timestamp to_timestamp('2020-08-13 16:20:00','yyyy-mm-dd hh24:mi:ss');

2.2 回收站

回收站主要用于存储用户删除的数据库和表等信息。

对于误删除的租户/数据库/表均可以从回收站找回（前提开启回收站）。

请注意，启用回收站特性需要预先配置并占用额外的存储空间。

三、事务回滚

3.1 自动提交模式下的处理

默认情况下，oceanbase 使用自动提交模式，这意味着每个sql语句都会立即生效。然而，在某些场景下，你可以通过设置会话变量来禁用自动提交，从而实现手动控制事务。

set autocommit = 0;
-- 执行一系列sql语句
rollback; -- 或者 commit;

3.2 利用保存点

即使在自动提交模式下，也可以利用保存点（savepoint）来标记事务中的关键位置。一旦发现误操作，可以回滚到最近的一个保存点而不影响之前的工作。

savepoint pointname;
-- 执行一些sql语句
rollback to savepoint pointname;

四、日志分析与恢复

4.1 重做日志（redo log）

重做日志记录了所有对数据库所做的更改。通过分析这些日志，可以找到导致问题的具体操作，并采取相应的措施进行修复。

4.2 归档日志（archive log）

归档日志是重做日志的副本，当系统崩溃时可以用来重建最新的状态。确保启用了归档模式，并定期归档日志文件。

联通软研院基于开源版ob建设的cbdb已经支持事务日志的分析，相关博客：

五、备集群

备集群在容灾要求高的场景中很有必要，可以分担读业务的压力。并且主库发生机房或地区，或者主集群多个zone同时故障时可以通过解耦或切换，由备集群切换为主，继续承担业务，减少业务连续性影响，以及保障数据的完整性(一般默认是最大性能模式，理论上是有损的)。

可以参考该博客： ，根据需要可以根据不同方式搭建备库，设计级联等方案。

六、单副本拉起

当集群没有以上容灾和恢复条件，又遇到多副本的故障的时候，仅存的一份副本可能是最后的一份希望，但是副本已经不满足多数派要求了，是起不来的。

该方法不是标准操作，也是被禁止的。单副本拉起有很多风险，技术上实际上并不能完全兜底。从方案上讲，单副本不是方案，官方并不会作为选项提供给客户。

通过ob_admin强制修改server_list来启服务。

/home/admin/oceanbase/bin/ob_admin -h 168.99.88.222 -p 2882  force_set_server_list 1 168.99.88.222:2882 

该方法可以紧急拉起单副本，但是要尽快备份数据，或者修复集群，风险极大，不建议！！！

七、预防措施

最后，除了事后补救外，还需要加强事前预防。这包括但不限于：

• 权限管理：严格限制用户的操作权限，避免不必要的高风险操作。
• 变更控制：引入变更审批流程，确保任何重大改动都经过充分评估。
• 培训教育：定期对dba和其他相关人员进行培训，提高他们应对突发事件的能力。
• 容灾方案：做好容灾备份工作，是最靠谱的后悔药，以及兜底方案。

结语

虽然没有真正的“后悔药”，但通过合理的规划和技术手段，我们可以大大降低误操作带来的风险。希望本文提供的方法能为你在关键时刻提供帮助，让你不再为误操作而懊恼。记住，最好的防御就是良好的习惯和完善的应急预案。祝你在数据库管理的道路上一帆风顺！

行之所向，莫问远方。