表回收站原理

由于DDL操作无法回滚，如果开发或运维人员误操作了数据库（例如DROP TABLE），可能会导致数据丢失。PolarDB支持回收站（Recycle Bin）功能，用于将删除的表临时转移到回收站，并且您可以自定义删除表的保留时间，方便您找回数据。

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> 

参数说明如下：

• 独立回收
  例如您可以在主节点上设置回收站内数据的最长保留周期为7天；在只读节点上设置回收站内数据的最长保留周期为14天。

设置不同的回收站内数据的最长保留周期，将导致集群的存储空间占用差别较大。