PolarDB之回收站

在Oracle 10g中的回收站（Recycle Bin）功能，可以在特殊情况下发挥保命之功能，比如当你删除一个表空间、一个Schema，可能会误删除的表。

刚好我们的一个子业务(OMS业务)使用了PolarDB自带了这个功能，默认是off的。

如果需要进入实例控制台----参数配置，进入相关的参数进行修改，打开默认是7天。

PolarDB之参数：

 

一、实例版本如下：
RDS MySQL 8.0（内核小版本20191225及以上）
RDS MySQL 5.7（内核小版本20210430及以上）

二、参数 说明

loose_recycle_bin 是否打开回收站功能，包括session级别和global级别。您可以在控制台修改参数。默认值：OFF。
loose_recycle_bin_retention 回收站保留时间，单位：秒。默认为604800，即一周。您可以在控制台修改参数。
loose_recycle_scheduler 是否打开回收站的异步清理任务线程。您可以在控制台修改参数。默认值：OFF。
loose_recycle_scheduler_interval 回收站异步清理任务线程的轮询间隔，单位：秒。默认为30。暂不开放。
loose_recycle_scheduler_purge_table_print 是否打印异步清理现场工作的详细日志。暂不开放。
说明 为了防止磁盘空间被占满，建议合理设置保留时间，并打开后台清理任务线程。

 

三、回收/清理机制
1.回收机制
(1)执行TRUNCATE TABLE语句时，将原始表移动到专门的recycle bin目录中，并在原位置使用相同的结构创建新表。
（说明：仅RDS MySQL 8.0（内核小版本20200331及以上）支持）。

(2)执行DROP TABLE/DATABASE语句时，只保留相关的表对象，并移动到专门的recycle bin目录中。其它对象的删除策略如下：

如果是与表无关的对象，根据操作语句决定是否保留，不做回收。
如果是表的附属对象，可能会修改表数据的，做删除处理，例如Trigger和Foreign key。 但Column statistics不做清理，随表进入回收站。

 

2.清理机制
(1)回收站会启动一个后台线程，来异步清理超过recycle_bin_retention时间的表对象。在清理回收站表的时候，如果遇到大表，会再启动一个后台线程异步删除大表。

 

四、权限
RDS MySQL实例启动时，会初始化一个名为__recycle_bin__的数据库，作为回收站使用的专有数据库。__recycle_bin__是系统级数据库，您无法直接进行修改和删除。

对于回收站内的表，虽然您无法直接执行drop table语句，但是可以使用call dbms_recycle.purge_table('<TABLE>');进行清理。

 说明：

账号在原表和回收站表都需要具有DROP权限。

 

五、回收站表命名规则
Recycle Bin会从不同的数据库回收到统一的__recycle_bin__数据库中，所以需要保证目标表表名唯一，所以定义了如下命名格式：

"__" + <Storage Engine> + <SE private id>
参数说明如下。

(1)参数

说明:
Storage Engine 存储引擎名称。
SE private id 存储引擎为每一个表生成的唯一值。例如在InnoDB引擎中就是table id。

(2)独立回收
回收的设置只会影响该实例本身，不会影响到binlog复制到的节点（备实例、只读实例和灾备实例）上。例如我们可以在主实例上设置回收，保留7天；在备实例上设置回收，保留14天。

说明:

回收站保留周期不同，将导致实例的空间占用差别比较大。

 

六、注意事项

如果回收站数据库和待回收的表跨了文件系统，执行drop table语句将会搬迁表空间文件，耗时较长。
如果Tablespace为General，可能会存在多个表共享同一个表空间的情况，当回收其中一张表的时候，不会搬迁相关的表空间文件。
管理Recycle Bin
AliSQL在DBMS_RECYCLE中定义了两个管理接口。详细说明如下：

 

七、show_tables查看
展示回收站中所有临时保存的表。命令如下：
call dbms_recycle.show_tables();

示例：

mysql> call dbms_recycle.show_tables();

+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| SCHEMA（回收站库）| TABLE（回收站中的表名） | ORIGIN_SCHEMA （被删除的表的库）| ORIGIN_TABLE（被删除的表名） | RECYCLED_TIME (删除时间)| PURGE_TIME（线程清理到期时间）          |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| __recycle_bin__ | __innodb_1063 | product_db | t1 | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1064 | product_db | t2 | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1065 | product_db | parent | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1066 | product_db | child | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
4 rows in set (0.00 sec)

(1)参数

说明:
SCHEMA 回收站的数据库名。
TABLE 进入回收站后的表名。
ORIGIN_SCHEMA 原数据库名。
ORIGIN_TABLE 原表名。
RECYCLED_TIME 回收时间。
PURGE_TIME 预计从回收站删除的时间。
(2)purge_table
手动清理回收站中的表。

命令如下：
call dbms_recycle.purge_table('<TABLE>');
说明:
TABLE为进入回收站后的表名。
账号在原表和回收站表都需要具有DROP权限。
示例：

call dbms_recycle.purge_table('__innodb_1063');

 

(3)restore_table
恢复回收站内的表。

命令如下：

call dbms_recycle.restore_table('<RECYCLE_TABLE>','<DEST_DB>','<DEST_TABLE>');

注意如果库也删除了，只能手动一个个创建库后，再 call dbms_recycle.restore_table('回收站中的表','原来库','原来表');