📣新登場！TiDB Cloud BYOC、TiDB Cloud Filesystem、PostgreSQL-compatible TiDB Cloud Starter がパブリックプレビュー中。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者
ベストプラクティス
API

運用エラーからのリカバリ

このガイドでは、TiDB Cloud Lake における一般的な運用エラーからリカバリするための手順を段階的に説明します。

はじめに

TiDB Cloud Lake は、次のような一般的な運用エラーからのリカバリに役立ちます。

  • 誤ってデータベースを削除した
  • 誤ってテーブルを削除した
  • 誤ったデータ変更（UPDATE/DELETE 操作）
  • 誤ってテーブルを TRUNCATE した
  • データのロードミス
  • Schema Evolution のロールバック（テーブル構造の変更を元に戻すこと）
  • 削除されたカラムまたは制約

これらのリカバリ機能は、異なる時点のデータのスナップショットを維持する、Git ライクなストレージ設計を持つ TiDB Cloud Lake の FUSE エンジンによって実現されています。

リカバリのシナリオと解決策

シナリオ: 誤ってデータベースを削除した

誤ってデータベースを削除した場合は、UNDROP DATABASE コマンドを使用して復元できます。

  1. 削除されたデータベースを特定します。

    SHOW DROP DATABASES LIKE '%sales_data%';

  2. 削除されたデータベースを復元します。

    UNDROP DATABASE sales_data;

  3. データベースが復元されたことを確認します。

    SHOW DATABASES;

  4. 所有権を復元します（必要な場合）。

    GRANT OWNERSHIP on sales_data.* to ROLE <role_name>;

詳細は、UNDROP DATABASE および SHOW DROP DATABASES を参照してください。

シナリオ: 誤ってテーブルを削除した

誤ってテーブルを削除した場合は、UNDROP TABLE コマンドを使用して復元できます。

  1. 削除されたテーブルを特定します。

    SHOW DROP TABLES LIKE '%order%';

  2. 削除されたテーブルを復元します。

    UNDROP TABLE sales_data.orders;

  3. テーブルが復元されたことを確認します。

    SHOW TABLES FROM sales_data;

  4. 所有権を復元します（必要な場合）。

    GRANT OWNERSHIP on sales_data.orders to ROLE <role_name>;

詳細は、UNDROP TABLE および SHOW DROP TABLES を参照してください。

シナリオ: 誤ったデータ更新または削除

テーブル内のデータを誤って変更または削除した場合は、FLASHBACK TABLE コマンドを使用して以前の状態に復元できます。

  1. 誤った操作を行う前のスナップショット ID またはタイムスタンプを特定します。

    SELECT * FROM fuse_snapshot('sales_data', 'orders');

    snapshot_id: c5c538d6b8bc42f483eefbddd000af7d
snapshot_location: 29356/44446/_ss/c5c538d6b8bc42f483eefbddd000af7d_v2.json
format_version: 2
previous_snapshot_id: NULL
[... ...]
timestamp: 2023-04-19 04:20:25.062854

  2. テーブルを以前の状態に復元します。

    -- Using snapshot ID
ALTER TABLE sales_data.orders FLASHBACK TO (SNAPSHOT => 'c5c538d6b8bc42f483eefbddd000af7d');

-- Or using timestamp
ALTER TABLE sales_data.orders FLASHBACK TO (TIMESTAMP => '2023-04-19 04:20:25.062854'::TIMESTAMP);

  3. データが復元されたことを確認します。

    SELECT * FROM sales_data.orders LIMIT 3;

詳細は、FLASHBACK TABLE を参照してください。

シナリオ: Schema Evolution のロールバック

テーブル構造に意図しない変更を加えてしまった場合は、以前のスキーマに戻すことができます。

  1. テーブルを作成し、データを追加します。

    CREATE OR REPLACE TABLE customers (id INT, name VARCHAR, email VARCHAR);
INSERT INTO customers VALUES (1, 'John', 'john@example.com');

  2. スキーマを変更します。

    ALTER TABLE customers ADD COLUMN phone VARCHAR;
DESC customers;

    出力:

    ┌─────────┬─────────┬──────┬─────────┬─────────┐
│ Field   │ Type    │ Null │ Default │ Extra   │
├─────────┼─────────┼──────┼─────────┼─────────┤
│ id      │ INT     │ YES  │ NULL    │         │
│ name    │ VARCHAR │ YES  │ NULL    │         │
│ email   │ VARCHAR │ YES  │ NULL    │         │
│ phone   │ VARCHAR │ YES  │ NULL    │         │
└─────────┴─────────┴──────┴─────────┴─────────┘

  3. スキーマ変更前のスナップショット ID を見つけます。

    SELECT * FROM fuse_snapshot('default', 'customers');

    出力:

    snapshot_id: 01963cefafbb785ea393501d2e84a425  timestamp: 2025-04-16 04:51:03.227000  previous_snapshot_id: 01963ce9cc29735b87886a08d3ca7e2f
snapshot_id: 01963ce9cc29735b87886a08d3ca7e2f  timestamp: 2025-04-16 04:44:37.289000  previous_snapshot_id: NULL

  4. 以前のスキーマに戻します（前のスナップショットを使用）。

    ALTER TABLE customers FLASHBACK TO (SNAPSHOT => '01963ce9cc29735b87886a08d3ca7e2f');

  5. スキーマが復元されたことを確認します。

    DESC customers;

    出力:

    ┌─────────┬─────────┬──────┬─────────┬─────────┐
│ Field   │ Type    │ Null │ Default │ Extra   │
├─────────┼─────────┼──────┼─────────┼─────────┤
│ id      │ INT     │ YES  │ NULL    │         │
│ name    │ VARCHAR │ YES  │ NULL    │         │
│ email   │ VARCHAR │ YES  │ NULL    │         │
└─────────┴─────────┴──────┴─────────┴─────────┘

重要な考慮事項と制限

  • 時間の制約: リカバリは保持期間内でのみ機能します（デフォルト: 24 時間）。
  • 名前の競合: 同じ名前のオブジェクトが存在する場合、undrop はできません。先にデータベース名を変更またはテーブル名を変更してください。
  • 所有権: 所有権は自動的には復元されないため、リカバリ後に手動で付与してください。
  • トランジェントテーブル: トランジェントテーブルでは Flashback は機能しません（スナップショットが保存されないため）。

緊急時: 重大なデータ損失が発生した場合は、すぐに TiDB Cloud Lake Support に連絡して支援を受けてください。

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