物理スタンバイデータベースのログ同期および再生異常の診断

物理スタンバイデータベースのログ同期および再生異常の診断

物理スタンバイデータベースのシナリオでは、ネットワーク、リソース、システム負荷、環境など、さまざまな要因の影響により、プライマリ/スタンバイテナント（プライマリ/スタンバイデータベース）間のログ同期または再生に異常が発生する可能性があります。

このドキュメントでは、診断プロセスと主要なシステムビューを提供し、異常の迅速な特定と解決を支援します。

診断の流れ

OceanBaseデータベースでは、プライマリテナントとスタンバイテナント間のログフローは、主に以下の3つの段階に分かれます：ログ転送 -> ログ受信 -> ログ再生。システムは以下のビューを提供し、各段階でのプライマリ・スタンバイテナントの同期状態を監視します。

プライマリ・スタンバイテナント間のログ同期に異常が発生した場合、以下の流れで診断できます：

1. 強力同期モードの場合、プライマリテナントでビューGV$OB_LS_LOG_TRANSPORT_STAT / V$OB_LS_LOG_TRANSPORT_STATを照会し、ログが正常に送信されているか、およびスタンバイテナントが確認しているかを確認します。

   注意

   ログ転送サービスは強力同期モードでのみ動作するため、この方法でプライマリテナントのログ転送状態を確認できるのは、プライマリテナントが強力同期モードの場合に限ります。非同期または弱力同期モードでは、スタンバイテナントがプライマリテナントからログをプルします。

2. スタンバイテナントでビューV$OB_LS_LOG_RESTORE_STATUSを照会し、ログのプルまたは受信が正常かどうかを確認します。

3. スタンバイテナントでビューGV$OB_LS_LOG_REPLAY_STAT / V$OB_LS_LOG_REPLAY_STATを照会し、ログ再生が正常かどうか、また停止や再生の遅延がないかを確認します。

診断プロセス

ログ転送フェーズ

強力同期モードでは、ログ転送フェーズにおいて、主にビュー GV$OB_LS_LOG_TRANSPORT_STAT / V$OB_LS_LOG_TRANSPORT_STAT の以下のフィールドを確認してログの転送状態を把握します：

• end_lsn：Palf上の実際のポイントを示します。マスターデータベースはPalf上からログを読み取り、スタンバイデータベースに送信します。

• last_sent_lsn：マスターデータベースが最後に読み取った最大ポイントを示します。

• standby_end_lsn：スタンバイデータベースに永続化されたポイントを示します。スタンバイデータベースは、マスターデータベースから送信されたログを受信すると、自身のPalfにログを永続化します。

手順は以下のとおりです：

1. マスターテナントのすべてのノードのログストリーム転送状態を確認します。

   • マスターテナントが存在するクラスタのsysテナントで、以下のステートメントを実行します。

     obclient(root@sys)[(none)]> SELECT tenant_id, svr_ip, svr_port, ls_id, role, enabled,
                   end_lsn, last_sent_lsn, standby_end_lsn,
                   standby_addr
               FROM oceanbase.GV$OB_LS_LOG_TRANSPORT_STAT
               WHERE tenant_id= xxx AND role = 'LEADER';
     

   • マスターテナントで、以下のステートメントを実行します。

     MySQLモード

     Oracleモード

     ステートメントは以下のとおりです：

     obclient(root@mysql001)[(none)]> SELECT svr_ip, svr_port, ls_id, role, enabled,
                   end_lsn, last_sent_lsn, standby_end_lsn,
                   standby_addr
               FROM oceanbase.GV$OB_LS_LOG_TRANSPORT_STAT
               WHERE role = 'LEADER';
     

     ステートメントは以下のとおりです：

     obclient(sys@oracle001)[(none)]> SELECT svr_ip, svr_port, ls_id, role, enabled,
                   end_lsn, last_sent_lsn, standby_end_lsn,
                   standby_addr
               FROM SYS.GV$OB_LS_LOG_TRANSPORT_STAT
               WHERE role = 'LEADER';
     

2. 転送遅延を確認します。

   • マスターテナントが存在するクラスタのsysテナントで、以下のステートメントを実行します。

     obclient(root@sys)[(none)]> SELECT tenant_id, ls_id,
                end_lsn - last_sent_lsn AS read_lag,
                last_sent_lsn - standby_end_lsn AS network_lag
            FROM oceanbase.GV$OB_LS_LOG_TRANSPORT_STAT
            WHERE tenant_id = xxx AND role = 'LEADER' AND enabled = 1;
     

   • マスターテナントで、以下のステートメントを実行します。

     MySQLモード

     Oracleモード

     ステートメントは以下のとおりです：

     obclient(root@mysql001)[(none)]> SELECT ls_id,
                end_lsn - last_sent_lsn AS read_lag,
                last_sent_lsn - standby_end_lsn AS network_lag
            FROM oceanbase.GV$OB_LS_LOG_TRANSPORT_STAT
            WHERE role = 'LEADER' AND enabled = 1;
     

     ステートメントは以下のとおりです：

     obclient(sys@oracle001)[SYS]> SELECT ls_id,
                end_lsn - last_sent_lsn AS read_lag,
                last_sent_lsn - standby_end_lsn AS network_lag
            FROM SYS.GV$OB_LS_LOG_TRANSPORT_STAT
            WHERE role = 'LEADER' AND enabled = 1;
     

     ここで：

     • read_lag：end_lsn - last_sent_lsn の値で、プライマリテナントからスタンバイテナントへのログ送信の遅延量を示します。

     • network_lag：last_sent_lsn - standby_end_lsn の値で、スタンバイテナントによるログ受信の遅延量を示します。

2回のクエリ結果に基づき、次の表を参照して問題を診断します：

ログ受信段階

ログ受信段階では、テナントが強同期モードにあるかどうかに関係なく、ビュー V$OB_LS_LOG_RESTORE_STATUS を使用してログストリームのログ受信状況を確認できます。

方法は以下のとおりです：

• スタンバイテナントが存在するクラスタの sys テナントで、以下のステートメントを実行します。

  obclient(root@sys)[(none)]> SELECT tenant_id, ls_id, sync_lsn, sync_scn, sync_status, err_code
                 FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE tenant_id = xxx;
  

• スタンバイテナントで、以下のステートメントを実行します。

  MySQLモード

  Oracleモード

  ステートメントは以下のとおりです：

  obclient(root@mysql001)[(none)]> SELECT ls_id, sync_lsn, sync_scn, sync_status, err_code
                 FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS;
  

  ステートメントは以下のとおりです：

  obclient(sys@oracle001)[SYS]> SELECT ls_id, sync_lsn, sync_scn, sync_status, err_code
                 FROM SYS.V$OB_LS_LOG_RESTORE_STATUS;
  

ここで：

• sync_scn：このログストリームの同期スナップショットを示します。

• sync_status：このログストリームの同期状態を示します。NORMAL はログストリームのログ同期状態が正常であることを示し、他の状態の場合は異常を示します。ログ同期状態とその意味は以下の表のとおりです。

  ログ同期状態	診断結果
  NORMAL	正常に同期中
  SOURCE HAS A GAP	スタンバイテナントとソース側のログにギャップがあり、プライマリテナントのログがスタンバイテナントに同期される前に回収されたため、復旧にはスタンバイテナントの再構築が必要です。
  STANDBY LOG NOT MATCH	復元ログとスタンバイテナントが競合しています。デュアルプライマリやログ復元ソースの設定ミスが原因の可能性があります。スタンバイテナントのログ復元ソースを再設定する必要があります。
  CHECK USER OR PASSWORD	コピー対象のアカウント名またはパスワードが間違っており、元のプライマリテナントにアクセスできません。スタンバイテナントのログ復元ソースを再設定する必要があります。
  CHECK NETWORK	プライマリテナントが到達不能です。ネットワークに異常がないか確認する必要があります
  RESTORE SUSPEND	スタンバイテナントは指定したポイントまで復元されています
  STANDBY NEED UPGRADE	スタンバイテナントのバイナリバージョンが古く、アップグレードが必要です
  PRIMARY TENANT DROPPED	プライマリテナントは削除されました
  FETCH LOG TIMEOUT	同期ログがタイムアウトしました。ネットワークの健全性を調査するか、スタンバイテナントのログ同期タイムアウトに関するテナントレベルのパラメータ standby_db_fetch_log_rpc_timeout を増量してください。standby_db_fetch_log_rpc_timeout の詳細については、standby_db_fetch_log_rpc_timeout を参照してください。
  STANDBY IN THROTTLING	スタンバイテナントの書き込みがスロットリング中です
  STANDBY LOG DISK IS FULL	スタンバイテナントのディスク容量が不足しています
  WAIT LOG STREAM CREATED	スタンバイテナントのログストリーム作成完了を待機中
  NOT AVAILABLE	その他の異常によりログ同期が利用できません

ログ再生段階

ログ再生段階では、主にビュー GV$OB_LS_LOG_REPLAY_STAT / V$OB_LS_LOG_REPLAY_STAT の以下のフィールドを確認することで、ログ再生の進捗状況および再生遅延を把握します：

• end_lsn：Palfが永続化したポイントを示します。

• unsubmitted_lsn：再生キューに次にコミットされるログのポイントを示します。

• min_unreplayed_lsn：再生キュー内で最も小さい未再生ログのポイントを示します。

• pending_cnt：再生を待機しているタスク数を示します。

方法は以下の通りです：

1. テナントのすべてのノードの再生進捗状況を確認します。

   • スタンバイテナントが存在するクラスタの sys テナントで、以下のステートメントを実行します。

     obclient(root@sys)[(none)]> SELECT tenant_id, svr_ip, svr_port, ls_id, role, enabled,
       end_lsn, unsubmitted_lsn, min_unreplayed_lsn,
       pending_cnt
     FROM oceanbase.GV$OB_LS_LOG_REPLAY_STAT WHERE tenant_id = xxx;
     

   • スタンバイテナントで、以下のステートメントを実行します。

     MySQLモード

     Oracleモード

     ステートメントは以下のとおりです：

     obclient(root@mysql001)[(none)]> SELECT svr_ip, svr_port, ls_id, role, enabled,
       end_lsn, unsubmitted_lsn, min_unreplayed_lsn,
       pending_cnt
     FROM oceanbase.GV$OB_LS_LOG_REPLAY_STAT;
     

     ステートメントは以下のとおりです：

     obclient(sys@oracle001)[SYS]> SELECT svr_ip, svr_port, ls_id, role, enabled,
       end_lsn, unsubmitted_lsn, min_unreplayed_lsn,
       pending_cnt
     FROM SYS.GV$OB_LS_LOG_REPLAY_STAT;
     

2. 再生遅延を確認します。

   • スタンバイテナントが存在するクラスタの sys テナントで、以下のステートメントを実行します。

     obclient(root@sys)[(none)]> SELECT tenant_id, ls_id,
       end_lsn - unsubmitted_lsn AS submit_lag,
       unsubmitted_lsn - min_unreplayed_lsn AS replay_lag,
       pending_cnt
      FROM oceanbase.GV$OB_LS_LOG_REPLAY_STAT
      WHERE tenant_id = xxx AND role = 'FOLLOWER';
     

   • スタンバイテナントで、以下のステートメントを実行します。

     MySQLモード

     Oracleモード

     ステートメントは以下のとおりです：

     obclient(root@mysql001)[(none)]> SELECT ls_id,
       end_lsn - unsubmitted_lsn AS submit_lag,
       unsubmitted_lsn - min_unreplayed_lsn AS replay_lag,
       pending_cnt
      FROM oceanbase.GV$OB_LS_LOG_REPLAY_STAT
      WHERE role = 'FOLLOWER';
     

     ステートメントは以下のとおりです：

     obclient(sys@oracle001)[SYS]> SELECT ls_id,
       end_lsn - unsubmitted_lsn AS submit_lag,
       unsubmitted_lsn - min_unreplayed_lsn AS replay_lag,
       pending_cnt
      FROM SYS.GV$OB_LS_LOG_REPLAY_STAT
      WHERE role = 'FOLLOWER';
     

2回のクエリ結果に基づき、次の表を参照して診断します：