テーブルの回復

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

構文

RECOVER TABLE table_name;
RECOVER TABLE BY JOB 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 ワーカーは、GC ライフタイムを超えたキーをmysql.gc_delete_rangeテーブルから定期的に削除します。

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

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

MySQL 互換性

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

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

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.