TiDB Self-Managed
Learning Center
お問い合わせ

テーブルを回復

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

構文

RECOVER TABLE table_name

RECOVER TABLE BY JOB ddl_job_id

あらすじ

RecoverTableStmt
RECOVERTABLEBYJOBInt64NumTableNameInt64Num
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 ワーカーは、定期的にmysql.gc_delete_rangeテーブルから GC の有効期間を超えたキーを削除します。

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

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

MySQL の互換性

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