由于DDL语句无法回滚,开发或运维人员如果误操作(例如DROP TABLE)可能会导致数据丢失。PolarDB支持回收站(Recycle Bin)功能,用于将删除的表临时转移到回收站,您可以自定义删除表的保留时间,方便您找回数据。
前提条件
PolarDB集群版本需为PolarDB MySQL 8.0且Revision version为8.0.1.1.2或以上,您可以参见查询版本号确认集群版本。
Recycle Bin介绍
- 回收和清理机制
- 回收机制
当执行
DROP TABLE
语句来删除数据表,或执行DROP DATABASE
语句来删除数据库时,PolarDB只会保留相关的表对象,并将表对象移动到专门的Recycle Bin目录中。其它对象的删除策略如下:- 如果是与表无关的对象,根据操作语句决定是否保留,不做回收。
- 如果是可能会修改表数据的表附属对象,做删除处理,例如Trigger和Foreign key。 但Column statistics不会被删除,而是随表进入回收站。
- 清理机制
回收站会启动一个后台线程,来异步清理超过recycle_bin_retention时间的表对象。在清理回收站表的时候,如果遇到大表,会再启动一个后台线程异步删除大表。
- 回收机制
- 权限
PolarDB集群启动时,会初始化一个名为__recycle_bin__的数据库,作为回收站使用的专有数据库。__recycle_bin__是系统级数据库,您无法直接进行修改和删除。
对于回收站内的表,虽然您无法直接执行
DROP TABLE
语句,但是可以使用CALL DBMS_RECYCLE.purge_table('table name');
进行清理。说明 执行清理操作的账号在原表和回收站表都需要具有DROP权限。 - 回收站表命名规则
Recycle Bin会从不同的数据库回收到统一的__recycle_bin__数据库中,因此定义了如下命名格式,用来保证目标表表名的唯一性:
"__" + <Storage Engine> + <SE private id>
参数说明如下。
参数 说明 Storage Engine 存储引擎名称。 SE private id 存储引擎为每一个表生成的唯一值。例如在InnoDB引擎中就是 table id
。 - 独立回收
例如我们可以在主节点上设置回收,保留7天;在只读节点上设置回收,保留14天。
说明 回收站保留周期不同,将导致集群的空间占用差别比较大。
注意事项
- 如果回收站数据库(__recycle_bin__)和待回收的表跨了文件系统,执行
DROP TABLE
语句将会搬迁表空间文件,耗时较长。 - 如果表空间为General,可能会存在多个表共享同一个表空间的情况,当回收其中一张表的时候,不会搬迁相关的表空间文件。
参数
使用Recycle Bin功能前,您需要先配置如下参数。
参数 | 说明 |
---|---|
recycle_bin | 是否打开表回收站功能,默认取值为OFF。包括session级别和global级别。 |
recycle_bin_retention | 回收站内数据的最长保留周期。取值范围为86400~1209600,单位为秒。默认取值为604800(即7天)。 |
管理语句
Recycle Bin提供了如下管理语句:
- 查看回收站中所有临时保存的表。
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)
参数 说明 SCHEMA
回收站的Schema。 TABLE
进入回收站后的表名。 ORIGIN_SCHEMA
原始表的Schema。 ORIGIN_TABLE
原始表的表名。 RECYCLED_TIME
回收时间。 PURGE_TIME
预计在回收站中被清理的时间。 - 手动清理回收站中的某张表。
CALL DBMS_RECYCLE.purge_table('TABLE_NAME')
说明TABLE_NAME
为进入回收站后的表名。- 执行清理操作的账号在原表和回收站表都需要具有DROP权限。
示例
mysql> CALL DBMS_RECYCLE.purge_table('__innodb_1063');
- 快速恢复回收站内的表。
CALL DBMS_RECYCLE.restore_table('RECYCLE_TABLE','DEST_DB','DEST_TABLE');
参数说明如下。
参数 说明 RECYCLE_TABLE
需要恢复的表在回收站内的表名。 说明 如果仅传入此参数,会恢复到原始表。DEST_DB 为恢复后的表指定目标数据库。 DEST_TABLE 为恢复后的表指定新的表名。 说明 执行此命令需要有数据库__recycle_bin__
的ALTER_ACL和DROP_ACL权限,以及目标表的CREATE_ACL和INSERT_ACL权限。示例
mysql> call dbms_recycle.restore_table('__innodb_1063','testDB','testTable');
在文档使用中是否遇到以下问题
更多建议
匿名提交