テーブルを回復する

RECOVER TABLEは、 DROP TABLEステートメントの実行後、GC (ガベージコレクション) の有効期間内に削除されたテーブルとそのデータを回復するために使用されます。

構文

RECOVER TABLE table_name;

RECOVER TABLE BY JOB JOB_ID;

あらすじ

RecoverTableStmt
TableName
Int64Num
NUM

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

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

Int64Num ::= NUM

NUM ::= intLit

注記：
テーブルが削除され、GC ライフタイムが切れた場合、テーブルをRECOVER TABLEで回復することはできません。このシナリオでRECOVER TABLEを実行すると、次のようなエラーが返されます: snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST 。
TiDB バージョンが 3.0.0 以降の場合、TiDB Binlog を使用するときにRECOVER TABLEを使用することはお勧めできません。
RECOVER TABLEはBinlogバージョン 3.0.1 でサポートされているため、次の 3 つの状況ではRECOVER TABLE使用できます。
Binlogバージョンは 3.0.1 以降です。
TiDB 3.0 は、アップストリームクラスターとダウンストリームクラスターの両方で使用されます。
セカンダリクラスターの GC ライフタイムは、プライマリクラスターの GC ライフタイムよりも長くなければなりません。ただし、アップストリームデータベースとダウンストリームデータベース間のデータレプリケーション中にレイテンシーが発生するため、ダウンストリームでデータの回復が失敗する可能性があります。

TiDB Binlogレプリケーション中のエラーのトラブルシューティング

TiDB Binlogレプリケーション中にアップストリーム TiDB でRECOVER TABLE使用すると、次の 3 つの状況で TiDB Binlog が中断される可能性があります。

ダウンストリームデータベースはRECOVER TABLEステートメントをサポートしていません。エラーインスタンス: check the manual that corresponds to your MySQL server version for the right syntax to use near 'RECOVER TABLE table_name' 。
GC ライフタイムは、上流データベースと下流データベースの間で一致しません。エラーインスタンス: snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST 。
アップストリームデータベースとダウンストリームデータベース間のレプリケーション中に遅延が発生します。エラーインスタンス: snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST 。

上記の 3 つの状況の場合、削除されたテーブルの完全インポートを使用して TiDB Binlogからデータレプリケーションを再開できます。

例

テーブル名に従って、削除されたテーブルを復元します。
```
DROP TABLE t;
```
```
RECOVER TABLE t;
```
このメソッドは、最近の DDL ジョブ履歴を検索してタイプDROP TABLEの最初の DDL 操作を特定し、削除されたテーブルをステートメントRECOVER TABLEで指定されたテーブル名と同じ名前で回復します。

使用されているテーブルのDDL JOB IDに従って、削除されたテーブルを復元します。

テーブルt削除して別のtを作成し、さらに新しく作成したt削除したとします。そして、最初に削除したtを復元したい場合は、 DDL JOB ID指定する方法を使用する必要があります。

DROP TABLE t;

ADMIN SHOW DDL JOBS 1;

上記の 2 番目のステートメントは、テーブルのDDL JOB ID検索してtを削除するために使用されます。次の例では、ID は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 |
+--------+---------+------------+------------+--------------+-----------+----------+-----------+-----------------------------------+--------+

RECOVER TABLE BY JOB 53;

このメソッドは、削除されたテーブルをDDL JOB IDを介して復元します。対応する DDL ジョブがDROP TABLEタイプでない場合、エラーが発生します。

実施原則

テーブルを削除する場合、TiDB はテーブルのメタデータのみを削除し、削除するテーブルデータ (行データおよびインデックスデータ) をmysql.gc_delete_rangeのテーブルに書き込みます。 TiDB バックグラウンドの GC ワーカーは、GC の有効期間を超えたキーをmysql.gc_delete_rangeテーブルから定期的に削除します。

したがって、テーブルを回復するには、GC ワーカーがテーブルデータを削除する前に、テーブルのメタデータを回復し、テーブルmysql.gc_delete_range内の対応する行レコードを削除するだけで済みます。 TiDB のスナップショット読み取りを使用して、テーブルのメタデータを回復できます。詳細は履歴データの読み取りを参照してください。

テーブルのリカバリは、TiDB がスナップショット読み取りを通じてテーブルメタデータを取得し、その後CREATE TABLEと同様のテーブル作成プロセスを経ることによって行われます。したがって、 RECOVER TABLE自体は本質的には一種の DDL 操作です。

MySQLの互換性

このステートメントは、MySQL 構文に対する TiDB 拡張機能です。

このページは役に立ちましたか？

Playground

新規

登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。