物理復旧に失敗した場合

この記事では、物理復旧が失敗した場合の問題のトラブルシューティングと特定方法について説明します。

物理復旧機能は、データバックアップおよびログアーカイブ機能に強く依存しています。つまり、物理復旧を開始する前に、少なくとも1つの利用可能なバックアップセットが存在し、かつログアーカイブが連続していることを保証する必要があります。

このドキュメントでは、OceanBaseデータベースのインストールディレクトリを/home/admin/oceanbaseとして説明します。ドキュメント内で言及されているログの実際の保存パスは、実際の環境に基づいてください。

課題1：復旧コマンドの実行に失敗

ALTER SYSTEM RESTORE ステートメントを実行して物理的復旧を開始する際に、コマンドの実行が失敗した場合は、以下の手順でトラブルシューティングを行うことができます。

1. root ユーザーでクラスタの sys テナントにログインします。

2. 以下のステートメントを実行し、エラー報告されたエラーコードを確認します。

   SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE module='physical_restore';
   

   クエリ結果では、特に以下の情報に注目してください：

   • result に対応する値、つまりエラー報告されたエラーコードです。

   • RS_SVR_IP の値、つまりRoot Serviceが配置されているマシンのIPアドレスです。

3. 前のステップで取得した RS_SVR_IP を使用して、Root Serviceが配置されているマシンにログインし、rootservice.log ログファイルを検索して、エラー発生箇所を確認します。

   1. Root Serviceが配置されているマシンにログインします。

   2. ログファイルが保存されているディレクトリに移動します。

      cd /home/admin/oceanbase/log
      

   3. 以下のコマンドを実行し、クエリで取得したエラーコードに基づいてログを検索し、エラー発生箇所を特定します。

      上記のステップで取得した result 情報のエラーコードが -4016 である場合を例に、コマンドは以下のとおりです。

      grep "ob_restore_util" rootservice.log | grep "ret=\-4016"
      

      注意

      rootservice.log ファイル内で grep で関連ログが見つからない場合は、rootservice.log ファイルが切り替わった可能性があります。その場合は、grep "ob_restore_util" rootservice.log.* | grep "ret=\-4016" コマンドを実行してください。

      また、一般的なコマンド実行失敗のエラーメッセージは -4018 no enough log for restore. です。この問題は通常、ユーザーが ALTER SYSTEM RESTORE ステートメントを実行する際に指定した復旧終了点が正しくないために発生します。そのため、その復旧終了点より前に利用可能なバックアップセットやログアーカイブが存在するかどうかを確認する必要があります。つまり、選択した復旧終了点が復旧可能な範囲内にない可能性があります。復旧可能な範囲の詳細については、物理的復旧関連パラメータの紹介 の timestampとscnの選定制約 を参照してください。

4. 検索したログのエラー情報を取得した後、技術サポート担当者に連絡して、問題の解決を依頼します。

質問2：テナントの復旧状態が常にRESTORE_WAIT_LS状態に留まる

ALTER SYSTEM RESTORE ステートメントを実行して物理的復旧を開始した後、CDB_OB_RESTORE_PROGRESS ビューを確認すると、復旧タスクの状態が常に RESTORING 状態にあることがわかります。

次の方法でさらに調査を進めることができます。

1. root ユーザーでクラスタの sys テナントにログインします。

2. 次のコマンドを実行して、復旧タスクの具体的な状態を照会します。

   SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE event LIKE 'change_restore_status' AND value1 = $job_id;
   

   ここで、$job_id は復旧タスクのID、つまり CDB_OB_RESTORE_PROGRESS ビュー内の job_id の値です。

   クエリ結果に基づいて、status の最後の値が RESTORE_WAIT_LS の場合は、次のステップを実行し、復旧対象のテナントのログストリームレプリカの復旧状態を確認する必要があります。

   status の最後の値が RESTORE_WAIT_LS 以外の場合は、このドキュメントの 質問3：Schemaフラッシュの問題 を参照して、さらに調査を進めてください。

3. 次のステートメントを実行して、復旧対象のテナントのログストリームレプリカの復旧状態を確認します。

   SELECT ls_id,svr_ip,svr_port,role,restore_status,zone FROM oceanbase.__all_virtual_ls_meta_table  WHERE tenant_id = xxxx;
   

   たとえば、クエリ例は次のとおりです：

   +-------+----------------+----------+------+----------------+------+
   | ls_id | svr_ip         | svr_port | role | restore_status | zone |
   +-------+----------------+----------+------+----------------+------+
   |     1 | 100.xx.xx.xx   |     5003 |    1 |              0 | z1   |
   |  1001 | 100.xx.xx.xx   |     5003 |    1 |              0 | z1   |
   |  1002 | 100.xx.xx.xx   |     5003 |    1 |              6 | z1   |
   +-------+----------------+----------+------+----------------+------+
   3 rows in set
   

   クエリ結果では、主に以下の列の情報に注目します：

   • role：レプリカの役割。1 は外部メディアからデータを復旧するリーダーレプリカを表し、2 はリーダーレプリカから復旧データを取得するフォロワーレプリカを表します。
   • restore_status：ログストリームレプリカの復旧状態。0 はログストリームレプリカが正常に復旧されたことを表します。

4. クエリで得られたログストリームレプリカの restore_status 値が 6 または 8 の場合、6 または 8 状態のログストリームは主にログとダンプの復旧を行うため、この段階ではログの復旧問題を優先的に考慮します。

   注意

   V4.1.0バージョン以降、OceanBaseデータベースはすべての復旧ログが同時に進むポリシーに従っています。ログストリームが 6 または 8 より前の状態に滞っている場合、他のログストリームの状態も 6 で動かない可能性があります。

   1. 次のコマンドを実行して、ログがアーカイブディレクトリからターゲットテナントに復旧されたかどうかを確認します。

      SELECT count(1) FROM oceanbase.GV$OB_LOG_STAT WHERE tenant_id = xxxx AND end_scn < (SELECT recovery_until_scn FROM oceanbase.DBA_OB_TENANTS WHERE tenant_id = xxxx);
      

      ステートメント内：

      • end_scn：最大消費可能なポイントを表します。

      • recovery_until_scn：テナントの復旧終了点を表します。

      クエリ結果が空でない場合、ログがアーカイブディレクトリからターゲットテナントに復旧されていないことを意味します。引き続き GV$OB_LOG_STAT ビュー内の end_scn の値を監視してください。end_scn が引き続き進んでいる場合は、待機を続けてください。長時間進まない場合は、技術サポートに連絡して次の処理を行ってください。

      説明

      ログをアーカイブディレクトリからテナントに復旧するプロセス全体には、かなりの時間がかかる場合があります。このプロセスの持続時間は、復旧対象のログ量、アーカイブメディアの読み取り性能、およびOceanBaseデータベースの負荷などの要因によって異なります。

      クエリ結果が空の場合、end_scn の値が recovery_until_scn の値以上であることを意味し、ログがアーカイブディレクトリからテナントに復旧されたことを示します。ログが再生されたかどうかをさらに確認する必要があります。

   2. ログが再生されたかどうかを確認します。

      まず、仮想テーブル __all_virtual_replay_stat を確認して、再生待ちのタスクがあるかどうかを確認します。

      SELECT * FROM oceanbase.__all_virtual_replay_stat WHERE tenant_id = xxxx;
      

      クエリ結果では、主に以下の列の値に注目します：

      • pending_cnt：再生待ちのタスク数を表します。この値がゼロでない場合、再生待ちのタスクがあることを意味します。

      • unsubmitted_log_scn：再生されていない再生ポイントを表します。

      次に、ビュー DBA_OB_TENANTS を確認して、recovery_until_scn の値を取得します。

      SELECT recovery_until_scn FROM oceanbase.DBA_OB_TENANTS WHERE tenant_id = xxxx;
      

      2回のクエリ結果に基づいて、pending_cnt の値が 0 であり、かつ unsubmitted_log_scn の値が recovery_until_scn の値より大きい場合、ログの再生が完了したことを意味します。ログストリーム1が復旧されたかどうかをさらに確認する必要があります。

      そうでない場合、いずれかの条件が満たされていない限り、再生は完了していないことを意味します。引き続き unsubmitted_log_scn が進んでいるかどうかを監視してください。長時間経っても unsubmitted_log_scn が進まない場合は、技術サポートに連絡して次の処理を行ってください。

   3. ログストリーム1が復旧されたかどうかを確認します。

      SELECT * FROM oceanbase.CDB_OB_LS WHERE tenant_id = xxxx;
      

      クエリ結果では、sync_scn と recovery_until_scn の値を比較します。ログストリーム1の sync_scn の値が recovery_until_scn と等しい場合、ログストリーム1の復旧が完了したことを意味します。そうでない場合、ログストリーム1の復旧は完了しておらず、技術サポートに連絡して次の処理を行ってください。

   4. ログの復旧プロセス全体が完了したことを確認した上で、restore_status の値が依然として 6 または 8 の場合は、技術サポートに連絡して次の処理を行ってください。

質問3：スキーマのリフレッシュに関する問題

ALTER SYSTEM RESTORE ステートメントを実行して物理復旧を開始した後、質問2：テナントの復旧状態が常にRESTORE_WAIT_LS状態に停止している の方法でビュー DBA_OB_ROOTSERVICE_EVENT_HISTORY を調査したところ、復旧待機中のテナントに残存するレコードが存在し、そのテナントの復旧状態は RESTORE_WAIT_LS 状態ではなく他の状態に停止していることが判明しました。これは、復旧待機中のテナントのスキーマがリフレッシュされておらず、システムがテナントの状態をNormalに変更することに失敗している可能性があります。

以下の方法で調査処理を行うことができます：

1. root ユーザーでクラスタの sys テナントにログインします。

2. ビュー GV$OB_SERVER_SCHEMA_INFO を照会し、スキーマのリフレッシュ進捗を確認します。

   SELECT * FROM oceanbase.GV$OB_SERVER_SCHEMA_INFO WHERE tenant_id=xxxx;
   

   クエリ例は以下のとおりです：

   +----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | REFRESHED_SCHEMA_VERSION | RECEIVED_SCHEMA_VERSION | SCHEMA_COUNT | SCHEMA_SIZE | MIN_SSTABLE_SCHEMA_VERSION |
   +----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+
   | xx.xx.xx.5     |     4000 |      1002 |                        1 |                       1 |            4 |     1086    |                         -1 |
   | xx.xx.xx.9     |     4002 |      1002 |                        1 |                       1 |            4 |     1086    |                         -1 |
   | xx.xx.xx.9     |     4001 |      1002 |                        1 |                       1 |            4 |     1086    |                         -1 |
   | xx.xx.xx.5     |     4005 |      1002 |                        1 |                       1 |            4 |     1086    |                         -1 |
   | xx.xx.xx.11    |     4004 |      1002 |                        1 |                       1 |            4 |     1086    |                         -1 |
   | xx.xx.xx.11    |     4003 |      1002 |                        1 |                       1 |            4 |     1086    |                         -1 |
   +----------------+----------+-----------+--------------------------+-------------------------+--------------+-------------+----------------------------+
   6 rows in set
   

   スキーマのリフレッシュが成功するためには、以下の条件を満たす必要があります：

   • REFRESHED_SCHEMA_VERSION = RECEIVED_SCHEMA_VERSION

   • REFRESHED_SCHEMA_VERSION の値が8より大きい

   • REFRESHED_SCHEMA_VERSION/8 の値が整数である

   上記のいずれかの条件を満たしていない場合、スキーマがリフレッシュされていないことを意味し、ログを検索してさらに調査する必要があります。

3. 前のステップで取得したビューの情報に基づき、スキーマがリフレッシュされていないマシンを任意に選択してログインし、ログを検索します。

   1. ログが保存されているディレクトリに移動します。

      cd /home/admin/oceanbase/log
      

   2. 関連情報を取得するためにログを検索します。

      ログを検索する際は、スレッド名で直接検索するだけで済みます。スキーマのリフレッシュはバックグラウンドスレッドであるため、システムは継続的に再試行します。そのため、最新のログを確認するだけで十分です。

      grep "SerScheQueue" observer.log
      

      検索したログの例は以下のとおりです：

      observer.log.20220811114045:[2022-08-11 11:39:54.382533] WARN  [RPC.OBRPC] rpc_call (ob_rpc_proxy.ipp:361) [192069][SerScheQueue0][T0][YFA00BA2D905-0005E5DEE6A2294E-0-0] [lt=8] execute rpc fail(ret=-4012, dst="11.xx.xx.9:4001")
      observer.log.20220811114045:[2022-08-11 11:39:54.382552] WARN  log_user_error_and_warn (ob_rpc_proxy.cpp:315) [192069][SerScheQueue0][T0][YFA00BA2D905-0005E5DEE6A2294E-0-0] [lt=20]
      

      検索したログに基づいて、対応するtrace情報と実行失敗したマシンの情報を見つけます。例えば、例のtrace情報は YFA00BA2D905-0005E5DEE6A2294E-0-0 で、実行失敗したマシンのIPアドレスは xx.xx.xx.9 です。

4. 実行失敗したマシンにログインし、取得したtrace情報に基づいてログが保存されているディレクトリに移動した後、さらにログを検索してエラー情報を確認します。

   grep "YFA00BA2D905-0005E5DEE6A2294E-0-0" observer.log
   

   注意

   observer.log 内で grep しても関連ログが見つからない場合、observer.log ファイルが切り替わっている可能性があります。grep "YFA00BA2D905-0005E5DEE6A2294E-0-0" observer.log.* を実行してください。

5. ログエラー情報を取得した後、技術サポート担当者に連絡して処理を依頼します。

質問4：ビューに表示される復元タスクのステータスがFAILEDになる

ALTER SYSTEM RESTORE ステートメントを実行して物理的復元を開始した後、ビュー CDB_OB_RESTORE_HISTORY を確認すると、復元タスクのステータスが FAILED であることがわかります。

以下の手順でトラブルシューティングを行うことができます：

1. root ユーザーでクラスタの sys テナントにログインします。

2. 再度ビュー CDB_OB_RESTORE_HISTORY を照会し、comment 列の情報を取得します。

   SELECT * FROM oceanbase.CDB_OB_RESTORE_HISTORY WHERE TENANT_ID=xxxx;
   

   comment 列には、復元タスクに関連するいくつかの情報が表示されており、OBServerノードのIPアドレス、ログストリームID、エラー発生モジュールの種類、および対応する trace_id が含まれます。

   ビュー CDB_OB_RESTORE_HISTORY の詳細については、CDB_OB_RESTORE_HISTORYを参照してください。

3. 取得したエラーコード情報と trace_id を使用して、該当するログを検索します。

   1. comment 情報に記載されているマシンにログインします。

   2. ログが保存されているディレクトリに移動します。

      cd /home/admin/oceanbase/log
      

   3. 以下のコマンドを実行して、復元タスクの失敗時点付近のログを検索します。

      • タスクを実行しているマシンのタイプがOBServerノード(comment 情報に(server)と表示されている場合)の場合、以下のコマンドを実行して、復元タスクの失敗時点付近のログを検索します。

        grep "trace_id"  observer.log | grep "WARN\|ERROR"
        

        ここで、trace_id は comment 列の trace_id 情報に置き換える必要があります。

        注意

        observer.logファイル内で関連ログを grep で検索できない場合は、observer.log ファイルが切り替わっている可能性があります。grep "trace_id" observer.log.* | grep "WARN\|ERROR" と入力してみてください。

      • タスクを実行しているマシンのタイプがROOT Service(comment 情報に(rootservice)と表示されている場合)の場合、以下のコマンドを実行して、復元タスクの失敗時点付近のログを検索します。

        grep "ob_restore_scheduler" rootservice.log | grep "WARN\|ERROR"
        

        注意

        rootservice.logファイル内で関連ログを grep で検索できない場合は、rootservice.log ファイルが切り替わっている可能性があります。grep "ob_restore_scheduler" rootservice.log.* | grep "WARN\|ERROR" と入力してみてください。

4. ログエラー情報を取得したら、技術サポート担当者に連絡して、問題の解決を依頼します。