Data definition language (DDL) operations cannot be rolled back. Data loss may occur due to accidental operations. For example, data may be lost when a user calls the DROP TABLE operation. PolarDB provides the table recycle bin feature and temporarily stores deleted tables. You can customize the retention period during which the deleted tables can be recovered.
The table recycle bin feature occupies storage capacity, which incurs storage fees. Configure the maximum retention period of the data in the recycle bin based on your business requirements.
Prerequisites
Your cluster runs one of the following database engine versions. For information about how to query the database engine version of a cluster, see Engine versions.
PolarDB for MySQL 8.0.1 with revision version 8.0.1.1.2 or later.
PolarDB for MySQL 8.0.2 with revision version 8.0.2.1.0 or later.
Features
Recycle and purge tables
Recycle tables
When you execute the
DROP TABLEstatement to delete a table or theDROP DATABASEstatement to delete a database, PolarDB retains only the table objects that are deleted and moves these objects to a specific directory of the recycle bin. Objects that are not related to table objects:Objects that are not related to the deleted tables: The system determines whether to retain the objects based on the statement that you execute. These objects are not recycled.
Objects that are attached to the tables and may modify the data of the tables: The system deletes the objects, which include
triggersandforeign keys.Column statisticsare moved to the recycle bin together with the tables, but are not deleted.
Purge tables
The recycle bin starts a background thread to asynchronously purge tables that are stored longer than the time period specified by the recycle_bin_retention parameter. For tables with a large amount of data, the system starts another background thread to asynchronously purge these tables.
Permissions
When a PolarDB cluster starts, a database named
__recycle_bin__is initialized as the database of the recycle bin. The__recycle_bin__database is a system database. You cannot modify or delete this database.You cannot execute the
DROP TABLEstatement on the tables in the recycle bin. However, you can execute thecall dbms_recycle.purge_table('table name');statement to purge these tables.NoteThe account that you use to purge tables must have the DROP permission on the original tables and the tables in the recycle bin.
How to name tables in the recycle bin
The recycle bin moves tables from different databases to the
__recycle_bin__database. The recycled tables must be named in the following format to ensure that the names are unique:"__" + <Storage Engine> + <SE private id>The following table describes the parameters.
Parameter
Description
Storage EngineThe name of the storage engine.
SE private idThe unique value that is generated by the storage engine to identify a table. For example, the value of this parameter in InnoDB is
table id.Independent recycling
For example, you can specify a 7-day retention period for the recycle bin of a primary node and a 14-day retention period for the recycle bin of a read-only node.
NoteThe storage space for the recycle bin depends on the retention period that you specify.
Precautions
If the
__recycle_bin__database and the tables that you want to recycle are in different file systems, theDROP TABLEoperation moves files across tablespaces, which is time-consuming.If the tables that you want to recycle are in a
generaltablespace that stores multiple tables, the files of the tablespace are not moved when you recycle one of the tables.
Billing
The table recycle bin feature uses the storage capacity of the cluster, which incurs storage fees. For more information, see Billing rules for storage.
Usage
Configure the loose_recycle_bin parameter to enable or disable the recycle bin. After you enable the recycle bin, data is recycled based on the rules for recycling tables. However, the tables are not purged by default. We recommend that you enable table purging to avoid additional storage fees caused by data in the recycle bin.
The loose_recycle_scheduler parameter controls the table purging feature. If table purging is disabled, the loose_recycle_bin_retention parameter is ignored and data remains in the recycle bin without being automatically deleted.
Parameter | Level | Description |
loose_recycle_bin | Global and session | Specifies whether to enable the recycle bin. Default value: OFF. Valid values:
|
loose_recycle_scheduler | Global | Specifies whether to enable the thread that is used to asynchronously purge the recycle bin. Default value: OFF. Valid values:
|
loose_recycle_bin_retention | Global | The maximum retention period of the data in the recycle bin. Valid values: 86400 to 1209600. Unit: seconds. Default value: 604800. The value 1209600 is equivalent to 14 days, and 604800 is equivalent to 7 days. Important
|
Manage the recycle bin
PolarDB provides the following statements to manage the recycle bin:
show_tables
You can execute the following statement to view all tables that are temporarily stored in the recycle bin:
call dbms_recycle.show_tables()Example:
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)The following table describes the parameters.
Parameter
Description
SCHEMAThe schema of the recycle bin.
TABLEThe name of the table after the table was moved to the recycle bin.
ORIGIN_SCHEMAThe schema of the original table before the table was moved to the recycle bin.
ORIGIN_TABLEThe original name of the table.
RECYCLED_TIMEThe time at which the table was moved to the recycle bin.
PURGE_TIMEThe estimated time at which the table is purged from the recycle bin.
purge_table
This method is used to manually delete a table from the recycle bin.
call dbms_recycle.purge_table('TABLE_NAME')NoteThe
TABLE_NAMEparameter specifies the name of the table after the table was moved to the recycle bin.The account that you use to purge tables must have the DROP permission on the original tables and the tables in the recycle bin.
Example:
mysql> call dbms_recycle.purge_table('__innodb_1063');restore_table
You can execute the following statement to restore a table from the recycle bin:
call dbms_recycle.restore_table('RECYCLE_TABLE','DEST_DB','DEST_TABLE');NoteOnly the clusters of PolarDB for MySQL 8.0 Cluster Edition whose revision versions are 8.0.1.1.12 or later allow you to restore tables from the recycle bin by executing the
restore_tablestatement. For more information about how to check the version, see Query the engine version.To execute the preceding statement, your account must have the ALTER_ACL and DROP_ACL permissions on the
__recycle_bin__database and the CREATE_ACL and INSERT_ACL permissions on the destination table.
The following table describes the parameters.
Parameter
Description
RECYCLE_TABLEThe name of the table that you want to restore from the recycle bin.
NoteIf you specify only this parameter, the data of the original table is restored.
DEST_DBThe destination database of the table that you want to restore.
DEST_TABLEThe new name of the recovered table.
Example:
call dbms_recycle.restore_table('__innodb_1063','testDB','testTable');
Contact us
If you have any questions about DDL operations, contact us.