背景
MySQL 在生产环境使用过程中,会伴随着开发和运维人员的误操作,比如 DROP TABLE / DATABASE,这类 DDL 语句不具有可操作的回滚特性,而导致数据丢失,AliSQL 8.0 新特性支持回收站功能(Recycle Bin),临时把删除清理的表转移到回收站,并保留可设置的时间,方便用户找回数据。为了方便,提供了 DBMS_RECYCLE package 作为管理接口。
Recycle Bin 管理接口
Recycle Bin 提供了两个管理接口,分别是:
DBMS_RECYCLE.show_tables()
展示回收站中所有临时保存的表:
-- Columns 解释:
SCHEMA
回收站的 schema
TABLE
进入回收站后的表名
ORIGIN_SCHEMA
原始表的 schema
ORIGIN_TABLE
原始表的表名
RECYCLED_TIME
回收时间
PURGE_TIME
未来被清理掉的时间
1,
DBMS_RECYCLE.purge_table(table_name=>)
手动清理回收站中的某张表
Recycle Bin 参数
Recycle Bin 一共设计了 5 个参数,分别是:
1,recycle_bin
2,recycle_bin_retention
3,recycle_scheduler
4,recycle_scheduler_interval
5,recycle_scheduler_purge_table_print
Recycle Bin 设计
Recycle Bin 总览
1. 回收机制
当操作 DROP TABLE / DATABASE 语句的时候, 只保留相关的表对象,并移动到专门的 recycle bin 目录中,
其它对象的删除策略是:
- 与表无关的对象,比如 procedure,根据操作语句决定是否保留,不做回收。
- 表的附属对象,比如 trigger,Foreign key,column statistics等,只要存在可能修改表数据的,做删除,
比如 trigger,Foreign key。 但columns statistics不做清理,随表进入回收站。
2. 清理机制
回收站会启动一个background 线程,来异步清理超过 recycle_bin_retention 时间的表对象, 在清理回收站表的时候,如果遇到是大表的清理,会再启动一个background 来做异步大文件删除。
Recycle schema 和权限控制
1. recycle schema
MySQL 系统启动的时候,会初始化一个 recycle bin 的schema, 命名为 "__recycle_bin__", 作为回收站使用的专有 database。
2. 权限控制
Database 权限:
recycle_bin 作为回收站的 schema,是系统级 database,没有权限做修改和删除。
用户无法使用drop table / database 来操作回收站。
比如:
recycled table 权限:
-- recycle scheduler 后台线程具有所有权限,可以做清理工作;
-- 用户虽然无法直接 drop table,可以使用 dbms_recycle.purge_table(),
但仍然需要原表和回收站表都具有 DROP_ACL 权限:
比如:
Recycled table 命名规则
Recycled table 会从不同的 schema,回收到统一的 recycle bin 回收站中,所以需要保证目标表表名唯一,所以
这里定义了一个命名格式:
Storge Engine:代表存储引擎名称,比如 innodb。
SE private id:是存储引擎为每一个表生成的唯一值,比如 InnoDB 中,就是 table id,
以此来唯一表示一个表名称。
Recycled table 关联对象
在回收表的过程中,需要处理表的相关对象,其处理的原则是:
- 如果是表附属对象,可能会存在修改表数据的可能性,就做删除,比如 trigger 和 FK。
- 如果是表相关对象,不会修改数据,就不做清理,比如相关的 view,统计信息等。
下面通过一个例子来看下:
原始结构
Drop 并回收(相关关联对象删除或失效)
Master-slave 独立回收
在 master - slave 结构中, 是否回收,或回收站保留的周期,都是实例本身的设置,不会影响到 binlog 复制到的节点上,所以,我们可以在 master 节点上设置回收,保留 7 天周期,在slave 节点上,设置回收,保留14天周期。
比如
master:
slave:
要注意的点就是,回收站保留周期不同,将导致 master - slave 节点之间的空间占用差别比较大。
异步表清理和大文件删除
当 recycle scheduler 异步线程 purge 回收站的表时候,如果遇到大表,那么将会启动大表异步删除逻辑,相关参数如下:
比如设置:
可以通过如下视图,查看大表异步删除的进展情况:
注意事项
1,回收站跨文件系统
如果你的回收站目录 "__recycle__bin_"_ 和回收的表跨了文件系统,那么drop table,将会搬迁表空间文件,耗时较长。
2,General tablespace
general tablespace 会存在多个表共享同一个表空间的情况, 当回收其中一张表的时候,不会搬迁相关的表空间文件,如果master 和 slave 设置的回收保留时间不同,那么就会存在在某一个时间点,主备间的这个general tablespace中的表数量不相等的情况。
本文作者:Roin
本文为云栖社区原创内容,未经允许不得转载。