TiDBで削除されたテーブルを即座に復元する方法

※このブログは2026年3月18日に公開された英語ブログ「How to Instantly Restore a Dropped Table in TiDB」の拙訳です。

主なポイント

• FLASHBACK TABLEを使用すると、削除されたテーブルを1秒未満で復元でき、データとスキーマはすべてそのまま維持されます。
• FLASHBACK TABLE、FLASHBACK DATABASE、およびFLASHBACK CLUSTERを使用することで、テーブル、データベース、およびクラスタの各スコープで復旧作業を行うことができます。
• Stale Readクエリを使用すると、GCの保持期間内のテーブルの過去のバージョンを確認できます。
• デフォルトの復旧期間は10分間です (tidb_gc_life_timeパラメータで設定可能)。したがって、この機能は定期的なバックアップを補完するものであり、それを置き換えるものではありません。

誤ってテーブルを削除してしまうことは、すべてのデータベースオペレーターが恐れる最悪の事態の一つです。そのテーブルはもう使われていないと思ったのかもしれません。あるいは、間違った環境に接続していたのかもしれません。いずれにせよ、何が起こったのかを察知した瞬間から、時間は刻一刻と過ぎていきます。

MySQLのような従来のデータベースでは、削除されたテーブルを復旧するには、最新のバックアップから復元し、バイナリログを削除直前の時点までロールフォワードする必要があります。この処理にはデータのサイズによっては数時間かかる場合があり、アプリケーションが停止している状況では、一分一秒が貴重です。

TiDBは、根本的に異なるアプローチをとります。そのLSM-Treeストレージアーキテクチャのおかげで、TiDBは単一のSQLコマンドで削除されたテーブルを即座に復元できます。バックアップも、バイナリログのリプレイも、ダウンタイムも必要ありません。

TiDBで削除されたテーブルを復元する方法

TiDBでFLASHBACK TABLEを使用してテーブルを即座に復元する手順は、以下のようになります。

-- Verify the table exists
tidb> TABLE auth_tokens;
+------+
| id   |
+------+
| 1234 |
+------+
1 row in set (0.003 sec)

-- Accidentally drop the table
tidb> DROP TABLE auth_tokens;
Query OK, 0 rows affected (0.152 sec)

-- The table is gone
tidb> TABLE auth_tokens;
ERROR 1146 (42S02): Table 'test.auth_tokens' doesn't exist

-- Restore it instantly
tidb> FLASHBACK TABLE auth_tokens;
Query OK, 0 rows affected (0.137 sec)

-- Data fully recovered
tidb> TABLE auth_tokens;
+------+
| id   |
+------+
| 1234 |
+------+
1 row in set (0.003 sec)

復旧作業全体は1秒足らずで完了します。リストアパイプラインも、アプリケーションのダウンタイムも、最新のバックアップを探し回る必要もありません。

データベースとクラスタのためのFLASHBACK

FLASHBACK TABLEは個々のテーブルに対して動作しますが、TiDBは同じ復元機能をより広い範囲に拡張しています。

• FLASHBACK DATABASEコマンドは、削除されたスキーマ全体を一度に復元します。
• FLASHBACK CLUSTER TO TIMESTAMP は、クラスタ全体を特定の時点までロールバックします。

FLASHBACK TABLEとFLASHBACK DATABASEの両方で、別の名前で復元することも可能です。これは、元のテーブルやスキーマがすでに同じ名前で再作成されている場合に便利です。

古いデータを含む履歴データのクエリ

TiDBは削除されたテーブルを復元させるだけではありません。GC保持期間内であれば、その後に変更または削除されたデータやカラムを含む、テーブルの任意の時刻のデータをクエリすることもできます。

SELECT * FROM my_table AS OF TIMESTAMP '2025-03-15 10:30:00';

また、読み取り専用トランザクションに対してSTART TRANSACTIONと共にAS OF TIMESTAMPを使用して、過去の任意の時点におけるデータの整合性のあるスナップショットを取得することもできます。

このタイムトラベル機能は、TiDBの論理データエクスポートツールであるTiDB Dumplingにも拡張されています。Dumplingを使用すると、テーブルの最新バージョンだけでなく、GC保持期間内の任意の以前のバージョンをエクスポートできます。これは、完全なリストアを行わずに特定のレコードを監査、デバッグ、または回復するのに役立ちます。

制限事項とトレードオフ

FLASHBACK TABLEは強力な機能ですが、バックアップの代わりにはなりません。バックアップは、ディスク障害やデータの破損を引き起こすソフトウェアのバグなどの、フラッシュバックでは対処できないシナリオからあなたを守ります。

フラッシュバック機能は、TiDBのGCライフタイム設定 (tidb_gc_life_time) に依存しており、デフォルトは10分です。削除されたテーブルを回復できるのは、この期間内で行動した場合のみです。多くのオペレーターは余裕を持たせるためにGC保持期間を長く設定しますが、考慮すべきトレードオフがあります。

• ストレージの回収が遅くなります：すべての削除されたデータはGC保持期間を過ぎるまで保持されるため、テーブルを削除したり行を削除したりした後にディスクスペースがすぐには解放されません。
• クエリのオーバーヘッドが増加します：読み取りクエリは、より多くの削除された行バージョン (トゥームストーン) をスキップする必要がある場合があります。TiKVのMVCCインメモリエンジンはこれを軽減するのに役立ちますが、デフォルトでは有効になっていません。

なぜTiDBは削除されたテーブルを即座に復元できるのか

即時にテーブル回復を提供するTiDBの能力は、そのストレージアーキテクチャに由来します。その理由を理解するには、TiDBの分散型SQLストレージレイヤーであるTiKVがどのようにデータを管理しているかを簡単に確認する必要があります。

LSM-Treeを使用したTiKVのデータ保存方法

TiKVはテーブルデータをキー・バリューペアとして保存し、各キーにはテーブルおよび行の識別子がプレフィックスとして付加されます。

キー	バリュー
t_101_r_12345	{"test", 1000, "this is a test"}

すべてのキー・バリューペアは、タイムスタンプオラクル (TSO) として機能するTiDBのPlacement Driver (PD) によって生成されたタイムスタンプも保持しています。これらのタイムスタンプは、個々のデータのバージョンと、それらを作成したトランザクションの両方を識別します。

内部的には、各TiKVノードはRocksDBを使用しており、これはログ構造化マージツリー (LSM-Tree) を実装しています。これは、MySQLのInnoDBが使用するB+Treeとは根本的に異なる構造です。

LSM-Treeでは、データは階層 (レベル) を移動します。新しい書き込みはメモリ内のMemTableに送られます (耐久性のためにディスクにも永続化されます)。MemTableがいっぱいになると、ディスク上のレベル0にフラッシュされます。時間が経つにつれて、コンパクションと呼ばれるプロセスが、あるレベルから次のレベルへとデータを統合します。

重要なポイント：更新と削除は、データをその場で変更しません。更新は、新しいタイムスタンプを持つ新しいバージョンの行を書き込みます。削除は、行が削除されたことを示すマーカーであるトゥームストーンを書き込みます。以前のバージョンの行は、GC保持期間が期限切れになった後にコンパクションがそれらをクリーンアップするまで、ストレージに残ります。

例えば、以下の3つの操作を考えてみましょう：

INSERT INTO demo1 VALUES (123, 'abc', 'first test');
UPDATE demo1 SET description = 'second test' WHERE id = 123;
DELETE FROM demo1 WHERE id = 123;

内部的には、TiKVは以下の3つのバージョンすべてを保存します。

タイムスタンプ	キー	バリュー
100	t_1_r_123	abc, first test
150	t_1_r_123	abc, second test
160	t_1_r_123	<tombstone>

タイムスタンプ155のトランザクションは、descriptionがsecond testである行を表示します。タイムスタンプ100のトランザクションはfirst testを表示します。そして、これこそがフラッシュバックを可能にしているものです。データはまだ保存されています。

FLASHBACK TABLEは、削除操作のタイムスタンプを特定し、その直前の時点からテーブルの状態を回復します。古いバージョンはまだガベージコレクションされていないため、回復は瞬時に行われます。

MySQLとTiDBにおける削除されたテーブル復旧の比較

InnoDBを使用したMySQLには、同等の機能はありません。InnoDBがテーブルを削除するとき (デフォルトのテーブル毎のファイル構成を使用している場合)、テーブルスペースファイルのリンクを解除し、バッファプールから関連するページを削除します。回復するには、バックアップ (MySQL Enterprise Backup、Percona XtraBackupなどを使用) からリストアし、削除前の時点までバイナリログをリプレイする必要があります。これは、データの量によってはかなりの時間を要するプロセスです。

理論的には、MySQLは削除されたテーブルファイルを一時的に保持しておくことも可能です。しかし、特に多くのチームがgh-ostやpt-online-schema-changeといった外部のスキーマ移行ツールを使用しており、それらがDDL操作中に一時テーブルを作成することを考えると、これは実際には複雑になります。それらを保持し続けることは、メリットがないまま膨大なストレージを消費することになります。

一般的な回避策は、テーブルを削除する前に名前を変更し (例：_delete_after_20251101__mytable)、実際に削除するまで待機することです。これは手動のセーフティネットを提供しますが、スキーマごとの復旧はサポートせず、既存のテーブルの履歴バージョンをクエリすることもできず、アプリケーションレイヤーとの調整が必要になる場合があります。

TiDBでは、これらの回避策は一切不要です。FLASHBACK TABLEは、データベースに直接組み込まれた1秒未満のテーブル復旧を提供します。

FLASHBACK TABLEを自分で試してみましょう

FLASHBACK TABLEは、FLASHBACK DATABASE、FLASHBACK CLUSTER、および履歴データを検査するためのStale ReadクエリとともにTiDBで利用可能です。完全な構文と例については、FLASHBACK TABLEのドキュメントをご覧ください。

これを実際に確認する最も速い方法は、無料のTiDBクラスタを起動し、テーブルを削除して、1秒以内に復旧させることです。今すぐ無料のTiDB Cloud Starterクラスタを起動して、ご自身で試してみてください。