重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

回復テーブル

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

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

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

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

TiDB Binlogレプリケーション中にアップストリームTiDBでRECOVER TABLEを使用すると、次の3つの状況で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つの状況では、 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拡張です。