Skip to main content

误操作恢复指南

本文作者：张瑞远（OceanBase 社区论坛账号：@五月）

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

一、备份与还原​

1.1 定期备份的重要性​

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

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

1.2 还原策略​

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

二、闪回（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');

可参考博客《oceanbase 查询闪回实践》。

2.2 回收站​

回收站主要用于存储用户删除的数据库和表等信息。对于误删除的租户 / 数据库 / 表均可以从回收站找回（前提是开启回收站）。

可参考《DBA 入门教程 —— 扩展功能》小节中的 “回收站” 部分。

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

三、事务回滚​

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已经支持事务日志的分析，相关博客： 《oblogminer（事务日志分析）功能实现》

五、备集群​

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

可以参考该博客《OB 425 黑屏搭建集群以及三种方式搭建备库（包含主备切换）》 ，根据需要可以根据不同方式搭建备库，设计级联等方案。

六、单副本拉起​

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

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

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

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

单副本拉起这个方法不是官方的标准操作，有很多风险（例如多数派挂了，有可能在剩余的副本上看到的已经不是最新的数据了）。这个方法是标准意义上的 “奇技淫巧”，大家了解即可。

七、预防措施​

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

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

结语​

虽然没有真正的“后悔药”，但通过合理的规划和技术手段，我们可以大大降低误操作带来的风险。

希望本文提供的方法能为你在关键时刻提供帮助，让你不再为误操作而懊恼。

记住，最好的防御就是良好的习惯和完善的应急预案。祝你在数据库管理的道路上一帆风顺！

行之所向，莫问远方。

Loading...