テーブルを回復
RECOVER TABLEは、 DROP TABLEステートメントが実行された後、GC (ガベージ コレクション) の有効期間内に、削除されたテーブルとその上のデータを回復するために使用されます。
構文
RECOVER TABLE table_name;
RECOVER TABLE BY JOB JOB_ID;
あらすじ
- RecoverTableStmt
- TableName
- Int64Num
- NUM
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 ワーカーは、定期的にmysql.gc_delete_rangeテーブルから GC の有効期間を超えたキーを削除します。
したがって、テーブルを回復するには、GC ワーカーがテーブル データを削除する前に、テーブル メタデータを回復し、 mysql.gc_delete_rangeテーブル内の対応する行レコードを削除するだけで済みます。 TiDB のスナップショット読み取りを使用して、テーブル メタデータを復元できます。詳細は履歴データの読み取りを参照してください。
テーブルの復旧は、TiDB がスナップショットの読み取りによってテーブルのメタデータを取得し、次にCREATE TABLEと同様のテーブル作成プロセスを実行することによって行われます。したがって、 RECOVER TABLE自体は本質的に一種の DDL 操作です。
MySQL の互換性
このステートメントは、MySQL 構文に対する TiDB 拡張です。