物理復元失敗

このセクションでは、物理復元が失敗した場合の問題のトラブルシューティングおよび特定方法について説明します。

物理復元機能はデータバックアップおよびログアーカイブ機能に強く依存しています。つまり、物理復元を開始する前に、少なくとも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"
      

      注意

      grep で rootservice.log 内に関連ログが見つからない場合は、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はLeaderレプリカを表し、外部メディアからデータを復元する役割を担います。2はFollowerレプリカを表し、Leaderレプリカからデータを取得して復元する役割を担います。
   • 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]
      

      検索されたログから、対応するトレース情報と実行失敗したマシンの情報を特定します。例えば、この例のトレース情報は YFA00BA2D905-0005E5DEE6A2294E-0-0、実行失敗したマシンのIPアドレスは xx.xx.xx.9 です。

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

   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. ログのエラー情報を取得したら、テクニカルサポートに連絡し、対応を依頼します。