Skip to content

Latest commit

 

History

History
105 lines (68 loc) · 3.9 KB

sql-statement-recover-table.md

File metadata and controls

105 lines (68 loc) · 3.9 KB
Raw
title summary aliases
RECOVER TABLE
An overview of the usage of RECOVER TABLE for the TiDB database.
/docs/dev/sql-statements/sql-statement-recover-table/
/docs/dev/reference/sql/statements/recover-table/

RECOVER TABLE

RECOVER TABLE is used to recover a deleted table and the data on it within the GC (Garbage Collection) life time after the DROP TABLE statement is executed.

Syntax

{{< copyable "sql" >}}

RECOVER TABLE table_name;

{{< copyable "sql" >}}

RECOVER TABLE BY JOB JOB_ID;

Synopsis

RecoverTableStmt ::=
    'RECOVER' 'TABLE' ( 'BY' 'JOB' Int64Num | TableName Int64Num? )

TableName ::=
    Identifier ( '.' Identifier )?

Int64Num ::= NUM

NUM ::= intLit

Note:

If a table is deleted and the GC lifetime is out, the table cannot be recovered with RECOVER TABLE. Execution of RECOVER TABLE in this scenario returns an error like: snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST.

Examples

  • Recover the deleted table according to the table name.

    {{< copyable "sql" >}}

    DROP TABLE t;

    {{< copyable "sql" >}}

    RECOVER TABLE t;

    This method searches the recent DDL job history and locates the first DDL operation of the DROP TABLE type, and then recovers the deleted table with the name identical to the one table name specified in the RECOVER TABLE statement.

  • Recover the deleted table according to the table's DDL JOB ID used.

    Suppose that you had deleted the table t and created another t, and again you deleted the newly created t. Then, if you want to recover the t deleted in the first place, you must use the method that specifies the DDL JOB ID.

    {{< copyable "sql" >}}

    DROP TABLE t;

    {{< copyable "sql" >}}

    ADMIN SHOW DDL JOBS 1;

    The second statement above is used to search for the table's DDL JOB ID to delete t. In the following example, the ID is 53.

    +--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE   | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME                        | STATE  |
+--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+
| 53     | test    |            | drop table | none         | 1         | 41       | 0         | 2019-07-10 13:23:18.277 +0800 CST | synced |
+--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+

    {{< copyable "sql" >}}

    RECOVER TABLE BY JOB 53;

    This method recovers the deleted table via the DDL JOB ID. If the corresponding DDL job is not of the DROP TABLE type, an error occurs.

Implementation principle

When deleting a table, TiDB only deletes the table metadata, and writes the table data (row data and index data) to be deleted to the mysql.gc_delete_range table. The GC Worker in the TiDB background periodically removes from the mysql.gc_delete_range table the keys that exceed the GC life time.

Therefore, to recover a table, you only need to recover the table metadata and delete the corresponding row record in the mysql.gc_delete_range table before the GC Worker deletes the table data. You can use a snapshot read of TiDB to recover the table metadata. Refer to Read Historical Data for details.

Table recovery is done by TiDB obtaining the table metadata through snapshot read, and then going through the process of table creation similar to CREATE TABLE. Therefore, RECOVER TABLE itself is, in essence, a kind of DDL operation.

MySQL compatibility

This statement is a TiDB extension to MySQL syntax.