テーブルの回復

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

構文

RECOVER TABLE table_name;

RECOVER TABLE BY JOB JOB_ID;

概要

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のステートメントで指定された 1 つのテーブル名と同じ名前を持つ削除されたテーブルを回復します。

• 使用されたテーブル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 拡張です。