PolarDB:データベースとテーブルの復元：ポイントインタイムリカバリ

適用範囲

バックアップセットが利用可能である必要があります。ポイントインタイム復元では、まず選択した時点より前に取得された最新の完全バックアップをクラスターに復元し、その後 redo ログを再生して選択した時点までの増分データを適用します。復元を高速化するために、拡張バックアップを有効にしてバックアップ間隔を短縮し、バックアップ密度を高めることができます。

利用シーン

注意事項

• ポイントインタイム復元とは、特定の時点を選択してデータベーステーブルを復元することです。復元後、データベーステーブルにはその時点のデータのみが含まれます。つまり、データベース内のテーブルデータはその時点のデータと一致します。

• データベース・テーブルの復元機能の「過去の時点に復元」モードは、1次バックアップの過去の時点からの復元のみをサポートします。2次バックアップからの復元はサポートされていません。

• 次のシナリオでは、データベースとテーブルの復元操作は失敗します。

  • 指定されたデータベース名またはテーブル名が元のクラスターにすでに存在する場合。

  • バックアップセットが生成された時点と復元時点の間に、復元対象のテーブルが削除されたか、クラスターにターゲットデータベースまたはテーブルと同じ名前のデータベースまたはテーブルが含まれている場合。

• データベースとテーブルの復元では、指定されたテーブルのみが復元されます。復元する必要があるすべてのテーブルを選択したことを確認してください。

  説明

  関連するすべてのテーブルを特定できない場合は、クラスター全体の既存データを新しいクラスターに復元し、その後、データを元のクラスターに移行することを推奨します。詳細については、「バックアップセットからの復元」および「クラスターを特定の時点に復元」をご参照ください。

• データベース全体を復元しない場合、各データベースで一度に最大 100 テーブルまで復元できます。データベース全体を復元する場合、データベース内のすべてのテーブルが復元されます。

  説明

  • 一度に復元するテーブルが多すぎると、復元に時間がかかります。そのため、一度に多くのテーブルを復元しないことを推奨します。

  • 多数のテーブルを復元する必要がある場合は、完全な既存データを新しいクラスターに復元することを推奨します。詳細な操作手順については、「バックアップセットからの復元」および「クラスターを特定の時点に復元」をご参照ください。

• クラスターに 50,000 を超えるテーブル (システムテーブルを含む) がある場合でも、データベース・テーブルの復元機能を使用できます。

  説明

  • この機能は現在、段階的なロールアウト中です。この機能を使用するには、お問い合わせいただき、クラスターをホワイトリストに追加してこの機能を有効にすることができます。

  • クラスター内のテーブル数 (システムテーブルを含む) を照会します。SQL ステートメントは次のとおりです。

    SELECT COUNT(*) FROM information_schema.tables;

  • クラスター内のシステムテーブルの数を照会します。SQL ステートメントは次のとおりです。

    SELECT COUNT(*) FROM information_schema.tables WHERE table_schema IN ('sys', 'performance_schema', 'mysql', 'information_schema', '__recycle_bin__');

• データベースとテーブルの復元は、トリガーの復元をサポートしていません。元のテーブルにトリガーが設定されている場合、そのトリガーは復元されません。

• データベースとテーブルの復元は、外部キーの復元をサポートしていません。元のテーブルに外部キーが設定されている場合、その外部キーは復元されません。

• データ復元はオフピーク時間に実行することを推奨します。

ステップ 1：誤操作の時刻を特定する

誤操作の時刻がすでにわかっている場合は、このステップをスキップできます。正確な時刻がわからない場合は、次の手順に従って特定してください。

方法 1：SQL Explorer

ご利用の PolarDB for MySQL Cluster Edition クラスターで SQL Explorer を有効にしている場合、この機能を使用して監査ログを表示し、誤操作の時刻を特定できます。

SQL Explorer は、機能が有効になった後に生成された SQL ログのみを表示できます。インシデント発生時にクラスターで SQL Explorer が有効になっていなかった場合は、方法 2 を使用してください。

方法 2：バイナリログをリモートでフェッチして解析する

1. クラスターのバイナリロギングを有効にします。詳細な手順については、「バイナリロギングの有効化」をご参照ください。

   説明

   バイナリログを表示およびフェッチする前に、クラスターのバイナリロギングを有効にする必要があります。そうしないと、You are not using binary logging というエラーが返されます。

2. ローカルサーバーに MySQL をインストールし、MySQL クライアントを使用してクラスターに接続します。詳細な手順については、「データベースクラスターへの接続」をご参照ください。このトピックでは、Linux システムを例として使用します。

   root@xxx:~# mysql -h xxx-polardb.rwlb.rds.aliyuncs.com -P3306 -utest_api -p
   Enter password:
   Welcome to the MySQL monitor.  Commands end with ; or \g.
   Your MySQL connection id is xxx
   Server version: 8.0.13 Source distribution
   Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
   Oracle is a registered trademark of Oracle Corporation and/or its
   affiliates.  Other names may be trademarks of their respective
   owners.
   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
   mysql>

3. 接続した MySQL クライアントで、次のコマンドを実行してターゲットクラスターのバイナリログファイルのリストを表示します。

   show binary logs;

   コマンドは次の出力を返します。

   +------------------+-----------+
   | Log_name         | File_size |
   +------------------+-----------+
   | mysql-bin.000005 |      2639 |
   +------------------+-----------+
   1 row in set (0.00 sec)

4. バイナリログをリモートでフェッチし、ローカルマシンに保存します。

   このトピックでは、Linux システムを例として使用します。まず、`exit` を実行して MySQL クライアントを終了します。次に、次のコマンドを実行してバイナリログをフェッチします。

   mysqlbinlog -u<username> -p<password> -h<endpoint> --read-from-remote-server --raw mysql-bin.******

   パラメーター	説明	例
   -u	クラスター内のデータベースアカウントのユーザー名。	test_api
   -p	アカウントのパスワード。これを空のままにすると、コマンド実行後に入力を求められます。	TestPwd123
   -h	クラスターのパブリックエンドポイント。 説明 クラスターエンドポイントがデフォルトのポート 3306 を使用している場合、ポート番号は省略できます。そうでない場合は、エンドポイントにポート番号を追加する必要があります。 現在、バイナリログはプライマリノードのパブリックエンドポイントまたはクラスターエンドポイント (デフォルトおよびカスタムクラスターエンドポイントを含む) を通じてのみリモートでフェッチできます。パブリックエンドポイントの申請方法については、「エンドポイントの管理」をご参照ください。	test-polardb.rwlb.rds.aliyuncs.com
   --read-from-remote-server	バイナリログがローカルのログファイルからではなく、MySQL サーバーから読み取られることを示します。	--read-from-remote-server
   --raw	フェッチされたバイナリログファイルが解析されたデータとしてではなく、元の形式で出力されることを示します。	--raw
   mysql-bin.******	show binary logs; コマンドの Log_name 列にリストされている、ターゲットのバイナリログファイルの名前。	mysql-bin.000005

   例：

   mysqlbinlog -utest_api -p -htest-polardb.rwlb.rds.aliyuncs.com --read-from-remote-server --raw mysql-bin.000005

5. 次のコマンドを実行して、mysqlbinlog ツールを使用してバイナリログファイルの内容を表示します。

   mysqlbinlog -vv --base64-output=decode-rows mysql-bin.****** | more

   説明

   • -vv：特定の SQL ステートメントとコメントを表示します。

   • --base64-output=decode-rows：バイナリログファイルを解析します。

   出力は次のようになります。

   [root@iZxxx ~]# mysqlbinlog -vv --base64-output=decode-rows mysql-bin.000110 | more
   /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
   /*!40019 SET @@session.max_insert_delayed_threads=0*/;
   /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
   DELIMITER /*!*/;
   # at 4
   #160217 23:04:37 server id 2802943055  end_log_pos 107  Start: binlog v 4, server v 5.5.18.1-log created 160217 23:04:37
   # at 107
   #160217 23:04:38 server id 2802943055  end_log_pos 171  Query    thread id=584632    exec time=0    error code=0
   SET TIMESTAMP=1xxx8/*!*/;
   SET @@session.pseudo_thread_id=584632/*!*/;
   SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
   SET @@session.sql_mode=2097152/*!*/;
   SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
   /*!\C utf8 *//*!*/;
   SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
   SET @@session.lc_time_names=0/*!*/;
   SET @@session.collation_database=DEFAULT/*!*/;
   BEGIN
   /*!*/;
   # at 171

6. バイナリログファイルの内容を取得した後、バイナリログを解析できます。

ステップ 2：データベースとテーブルの復元を開始する

1. PolarDB コンソールにログインします。左側のナビゲーションウィンドウで クラスター をクリックします。クラスターがデプロイされている [リージョン] を選択し、クラスター ID をクリックしてクラスター詳細ページに移動します。

2. 左側のナビゲーションウィンドウで、設定と管理 > バックアップと復元 を選択し、データベース / テーブルの復元 をクリックします。

3. 表示されるダイアログボックスで、復元タイプ を タイムポイントのバックアップ に設定し、復元時刻 で復元したい時点を選択します。

   説明

   • 復元時刻 で選択する時点は、復元先 の範囲内である必要があります。同時に、タイムポイントのバックアップ 機能が正しく動作するためには、復元対象のテーブルがこの時点より前に取得された最新の完全バックアップセットに存在している必要があります。復元可能な時点の範囲は、バックアップ設定の ログバックアップの保持期間 の期間に依存し、デフォルトでは 7 日間です。

   • データベース・テーブルの復元機能は、IOPS 消費量に基づいて 3 つの速度設定を提供します：速い、標準、安全。ビジネス要件に基づいて設定を選択してください。各速度設定の推定復元時間については、「データベースとテーブルの復元速度テストの参考」をご参照ください。

     • 速い：現在のクラスターにデータを復元する際、大量の IOPS が消費される可能性があります。この設定はオフピーク時間に選択することを推奨します。

     • 標準 (4 コア以上のクラスターに推奨)：現在のクラスターにデータを復元する際、中程度の IOPS が消費される可能性があります。

     • 安全 (4 コア以下のクラスターに推奨)：現在のクラスターにデータを復元する際、消費される IOPS は少量ですが、復元速度が大幅に影響を受ける可能性があります。

     4 コア以下のクラスターでは、innodb_io_capacity と innodb_io_capacity_max がクラスターの仕様に合った値に設定されていることを確認することを推奨します。各クラスター仕様でサポートされる最大 IOPS については、「Enterprise Edition のコンピューティングノード仕様」および「Standard Edition のコンピューティングノード仕様」をご参照ください。復元には 安全 速度を使用することを推奨します。

4. 復元するデータベースとテーブル セクションで、左側でターゲットデータベースを、右側でターゲットテーブルを選択します。

   説明

   • 新しいデータベース名やテーブル名を指定しない場合、システムは元のデータベース名やテーブル名に _backup を追加して、新しいデータベース名とテーブル名を自動的に生成します。たとえば、元のテーブル名が test の場合、自動生成される新しいテーブル名は test_backup になります。

   • ターゲットデータベースを選択し、テーブルを指定しない場合、デフォルトでデータベース内のすべてのテーブルが復元されます。

5. 復元したいデータベースとテーブルを選択したことを確認した後、OK をクリックします。

ステップ 3：復元されたデータの検証

データベースとテーブルの復元が完了したら、クラスターにログインして復元されたデータを検証できます。

DMS を通じて、または別のクライアントや CLI を使用してクラスターにログインできます。このトピックでは、DMS を通じてクラスターにログインして検証する方法について説明します。その他の方法については、「クラスターへの接続」をご参照ください。

1. クラスターの 概要 ページ右上隅にある データベースにログイン をクリックします。

2. 表示されるダイアログボックスで、クラスターの データベースアカウント と データベースパスワード を入力し、お 問い合わせ をクリックします。

3. DMS にログインした後、ページをリフレッシュします。左側のナビゲーションウィンドウで、[ログイン中のインスタンス] をクリックします。

4. [ログイン中のインスタンス] リストで、ターゲットクラスターの名前をクリックし、ターゲットデータベースの名前を見つけてダブルクリックし、管理対象のターゲットデータベースに切り替えます。

5. 誤操作されたデータを見つけ、誤操作前の状態に復元されているか、また他のデータも誤操作前の状態と一致しているかを確認します。