回復表

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

構文

RECOVER TABLE table_name

RECOVER TABLE BY JOB ddl_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以降の場合、TiDBBinlogを使用するときにRECOVER TABLEを使用することはお勧めしません。

• Binlogバージョン3.0.1ではRECOVER TABLEがサポートされているため、次の3つの状況でRECOVER TABLEを使用できます。

  • Binlogのバージョンは3.0.1以降です。
  • TiDB 3.0は、アップストリームクラスタとダウンストリームクラスタの両方で使用されます。
  • セカンダリクラスタのGCライフタイムは、プライマリクラスタのGCライフタイムより長くする必要があります。ただし、アップストリームデータベースとダウンストリームデータベース間のデータレプリケーション中に遅延が発生するため、ダウンストリームでデータリカバリが失敗する可能性があります。

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

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

• ダウンストリームデータベースは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つの状況では、TiDBBinlogからのデータレプリケーションを削除されたテーブルの完全インポートで再開できます。

例

• テーブル名に従って、削除されたテーブルを回復します。

  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拡張です。