本記事では、物理スタンバイデータベースの同期処理中にログ同期が停止する問題のトラブルシューティングおよび原因特定方法について説明します。
質問1：RECOVERコマンドを実行していない場合、RECOVER コマンドで指定された終点まで復元する場合、または ALTER SYSTEM RECOVER xxx CANCEL コマンドを実行した場合
現象
- ユーザーが物理復元によりスタンバイテナントを復元した後、
RECOVERコマンドを実行して新しいスタンバイテナントの復元終点を変更せず、ログストリームが特定の終点に復元されると、スタンバイテナントのログ同期が停止します。 - ユーザーが物理復元によりスタンバイテナントを復元した後、
RECOVERコマンドを実行して指定された終点まで復元しますが、ログストリームが特定の終点に復元されると、スタンバイテナントのログ同期が停止します。 - ユーザーが物理復元によりスタンバイテナントを復元し、
RECOVERコマンドを実行した後、ALTER SYSTEM RECOVER xxx CANCELコマンドを実行すると、ログストリームが特定の終点に復元されると、スタンバイテナントのログ同期が停止します。
原因
通常、物理復元によりスタンバイテナントを復元した後、RECOVER コマンドを実行しない場合、または RECOVER コマンドを実行して指定された終点まで復元した場合、スタンバイテナントのログ同期は指定された復元終点で停止します。さらに、スタンバイテナントで RECOVER コマンドを実行した後、ALTER SYSTEM RECOVER xxx CANCEL コマンドを実行すると、スタンバイテナントのログ同期も特定の復元終点で停止します。
以下の例では、テナント restore_oracle_tenant のテナントロールは STANDBY であり、その同期進捗が特定の固定時刻で停止しています。この現象が発生する原因は、ユーザーが RECOVER コマンドを実行していないか、RECOVER コマンドを実行して指定された終点まで復元したか、または RECOVER コマンドを実行した後に ALTER SYSTEM RECOVER xxx CANCEL コマンドを実行したためです。テナントの同期位置 SYNC_SCN が復元可能な位置 RECOVERY_UNTIL_SCN と一致すると、スタンバイテナントはそれ以上のログを同期する必要がなくなります。
*************************** 1. row ***************************
TENANT_ID: 1002
TENANT_NAME: restore_oracle_tenant
TENANT_ROLE: STANDBY
STATUS: NORMAL
SWITCHOVER_STATUS: NORMAL
SYNC_SCN: 1690425747241344851
REPLAYABLE_SCN: 1690425747241344851
READABLE_SCN: 1690425747241344851
RECOVERY_UNTIL_SCN: 1690425747241344851
1 row in set
トラブルシューティングの手順
DBA_OB_TENANTS ビューで同期ポイント情報を確認できます。
テナント管理者が問題のテナントまたはそのテナントが存在するクラスタの
sysテナントにログインします。テナントの
TENANT_IDまたはTENANT_NAMEに基づいて、問題のテナントの基本状態情報（テナントロール、同期ポイントなど）を照会します。システムテナントから指定したテナントを確認する場合
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;問題のテナントが自身のテナントを照会する場合
MySQLモードOracleモードステートメントは次のとおりです：
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;ステートメントは以下のとおりです：
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
クエリ結果では、以下の列の値に特に注意してください：
TENANT_ROLE：STANDBYはスタンバイテナントを表し、PRIMARYはプライマリテナントを表します。SYNC_SCN：テナントの同期ポイントを表します。REPLAYABLE_SCN：テナントの再生可能なポイントを表します。このポイントより大きいSCNのログは再生できません。RECOVERY_UNTIL_SCN：テナントが復元できる終点を表します。値が4611686018427387903の場合、無限に復元されることを意味します。
ビュー
DBA_OB_TENANTSの詳細については、DBA_OB_TENANTS を参照してください。
質問2：テナントのログ復元ソースが設定されていない、またはログ復元ソースが空、またはログ復元ソースが破損しています
現象
BACKUP DATABASE PLUS ARCHIVELOGコマンドでスタンバイテナントを作成した後、ログ復元ソースを設定しなかったり、設定したログ復元ソースが空（ALTER SYSTEM SET log_restore_source = '';）になっている場合。- スタンバイテナントのログ復元ソースがクリアされたことがある場合。
- プライマリテナントがSwitchoverコマンドでスタンバイテナントに切り替わった後、ログ復元ソースを設定しなかった場合。
原因
OceanBaseデータベースでは、スタンバイテナントはログ復元ソースから上流のログを取得します。物理バックアップ・リストア機能で作成されたスタンバイテナントは、ユーザーが RECOVER コマンドを実行すると、デフォルトでリストア時に指定されたアーカイブディレクトリからログの復元を続けます。CREATE STANDBY TENANT コマンドで作成されたスタンバイテナントは、デフォルトでネットワークを介してプライマリテナントから直接ログを同期します。一方、BACKUP DATABASE PLUS ARCHIVELOG コマンドで作成されたスタンバイテナントはログ復元ソースが指定されていないため、ログの継続的な同期を直接開始することができません。
さらに、スタンバイテナントのログ復元ソースが空、または設定されたログ復元ソースが破損した場合も、同様にスタンバイテナントが停止することがあります。例えば、ネットワークベースの物理スタンバイデータベースでは、プライマリテナントが削除されたり、プライマリテナントにアクセスするためのレプリケーション専用アカウントのパスワードが変更されたりすると、アーカイブベースの物理スタンバイデータベースでは、ログ復元に使用されるアーカイブディレクトリが削除されたりすると、スタンバイテナントが停止します。
トラブルシューティングの手順
CDB_OB_LOG_RESTORE_SOURCEまたはDBA_OB_LOG_RESTORE_SOURCEビューを使用して、問題のテナントにログ復元ソースが設定されているかどうかを確認できます。
テナント管理者として、問題のテナント、または問題のテナントが存在するクラスタの
sysテナントにログインします。問題のテナントにログ復元ソースが設定されているかどうかを確認します。
システムテナントから指定したテナントを確認する場合
SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE TENANT_ID=1xxx;問題のテナントから自身を確認する場合
MySQLモードOracleモードステートメントは以下のとおりです：
SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE;ステートメントは以下のとおりです：
SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE;
クエリ結果では、以下の列の値に注目します：
TYPE：値がLOCATIONの場合、現在のテナントがアーカイブログからソーステナントからログを同期していることを意味し、アーカイブベースの物理スタンバイデータベースに属します。値がSERVICEの場合、現在のテナントがネットワークを介してプライマリテナントから直接ログを同期していることを意味し、ネットワークベースの物理スタンバイデータベースに属します。ALTER SYSTEM SET log_restore_sourceコマンドを実行することで、スタンバイテナントのログ同期ソースを切り替えることができます。VALUE：その値はTYPEの値に対応しており、それぞれソーステナントのアーカイブディレクトリとプライマリテナントのAccess Pointです。
以下のクエリ結果に示すように、テナント
restore_oracle_tenantのログ復元ソースのクエリ結果が空の場合、そのテナントにログ復元ソースが設定されていないことを意味し、スタンバイテナントのログ同期は自然と停止します。クエリ結果の値がアーカイブディレクトリの場合、アーカイブディレクトリがプライマリ・スタンバイテナントのすべてのマシンからアクセス可能かどうかを確認する必要があります。値がプライマリテナントのAccess Pointの場合、IPリスト、USER、PASSWORDなどが正しく設定されているかどうかを確認する必要があります。*************************** 1. row *************************** tenant_id: 1002 type: LOCATION value: file:///data/1 recovery_until_scn: 4611686018427387903 1 row in setビュー
CDB_OB_LOG_RESTORE_SOURCEおよびビューDBA_OB_LOG_RESTORE_SOURCEの詳細については、CDB_OB_LOG_RESTORE_SOURCEおよびDBA_OB_LOG_RESTORE_SOURCEを参照してください。
質問3：スタンバイデータベースのログ同期状態が異常です
現象
問題1および問題2のいずれも該当しない場合でも、スタンバイテナントのログ同期に異常が発生する。
原因
ログ同期プロセスにおいて、プライマリテナントのログストリーム回収やネットワーク障害などにより、スタンバイテナントが遅延したり、停止したりする可能性があります。
トラブルシューティングの手順
ビュー V$OB_LS_LOG_RESTORE_STATUS は、すべてのログストリームの同期状態を集計しており、このビューを使用してテナント内のすべてのログストリームの同期状態を確認できます。
注意
ビュー V$OB_LS_LOG_RESTORE_STATUS はログストリームのリーダーに関する同期状態情報のみを表示します。そのため、スタンバイテナントでログストリームがリーダーを持たない場合、このビューでは確認できません。その場合は、リーダー不在の問題を調査する必要があります。
テナント管理者として、問題のあるテナントまたはそのテナントが存在するクラスタの
sysテナントにログインします。問題のあるテナントのすべてのログストリームのリーダーの同期状態を確認します。
システムテナントから指定したテナントを確認する場合
SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID=1xxx;問題のあるテナントから自身のテナントを確認する場合
MySQLモードOracleモードステートメントは以下のとおりです：
SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS;ステートメントは以下のとおりです：
SELECT * FROM SYS.V$OB_LS_LOG_RESTORE_STATUS;クエリ結果では、以下の列の値に注目します：
SYNC_SCN：このログストリームの同期シーンを表します。SYNC_STATUS：このログストリームの同期状態を表します。ここで、NORMALはログストリームの同期状態が正常であることを意味し、他の状態の場合は異常を示します。ログ同期状態とその意味は以下の表のとおりです。
ビュー
V$OB_LS_LOG_RESTORE_STATUSの詳細については、V$OB_LS_LOG_RESTORE_STATUSを参照してください。
ログ同期状態意味NORMAL 正常に同期中 SOURCE HAS A GAP スタンバイテナントとソース側のログにギャップがあり、プライマリテナントのログがスタンバイテナントに同期される前に回収された STANDBY LOG NOT MATCH 復元ログとスタンバイテナントで競合が発生しています。デュアルプライマリやログ復元ソースの設定ミスが原因の可能性があります CHECK USER OR PASSWORD コピー対象のアカウント名またはパスワードが間違っており、元のプライマリテナントにアクセスできません CHECK NETWORK プライマリテナントが到達不能です。ネットワーク異常を確認する必要があります RESTORE SUSPEND スタンバイテナントは指定したポイントまで復元されています STANDBY NEED UPGRADE スタンバイテナントのBinaryバージョンが古く、アップグレードが必要です 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 その他の異常によりログ同期が利用できません
質問4：スタンバイテナントの同期ポイントが進まなくなった
現象
スタンバイテナントが上記の問題1、問題2、問題3などに該当する問題が発生していないにもかかわらず、依然としてフリーズしてしまう場合、スタンバイテナントの同期シーンの進行が停止している可能性があります。その分析を試みることができます。
原因
スタンバイテナントはログ同期プロセスにおいて、すべてのログストリームが同時に進む戦略に従います。そのため、各ログストリームはテナントの SYNC_SCN を考慮し、一定のポリシーに基づいてログを先行取得します。テナントの SYNC_SCN が進まない場合、ログ同期も停止し、テナントの SYNC_SCN が回復して初めてログ同期が再開されます。
トラブルシューティングの手順
テナント管理者が問題のテナント、または問題のテナントが存在するクラスタの
sysテナントにログインします。ビュー
DBA_OB_TENANTSを使用して、テナントの同期ポイントSYNC_SCNを確認します。テナントの
TENANT_IDまたはTENANT_NAMEに基づいて、問題のテナントのSYNC_SCNを照会できます。システムテナントが指定されたテナントの
SYNC_SCNを確認する場合SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;問題のテナントが自身の
SYNC_SCNを確認する場合MySQLモードOracleモードステートメントは以下のとおりです：
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM oceanbase.DBA_OB_TENANTS;ステートメントは以下のとおりです：
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS, SWITCHOVER_STATUS, SYNC_SCN, REPLAYABLE_SCN,READABLE_SCN, RECOVERY_UNTIL_SCN FROM SYS.DBA_OB_TENANTS;
クエリ結果では、以下の列の値に注目します：
TENANT_ROLE：STANDBYはスタンバイテナントを表し、PRIMARYはプライマリテナントを表します。SYNC_SCN：テナントの同期ポイントを表します。
V$OB_LS_LOG_RESTORE_STATUSビューを使用して、すべてのログストリームリーダーのSYNC_SCNを照会します。システムテナントが指定されたテナントを確認する場合
SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID=1xxx;問題のテナントが自身のテナントを確認する場合
MySQLモードOracleモードステートメントは以下のとおりです：
SELECT * FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS;ステートメントは次のとおりです：
SELECT * FROM SYS.V$OB_LS_LOG_RESTORE_STATUS;クエリ結果では、ログストリームの同期ポイントを表す
SYNC_SCN列に注目します。2回のクエリ結果を比較し、すべてのログストリームの
SYNC_SCNとテナントのSYNC_SCNを比較します。すべてのログストリームのSYNC_SCNがテナントのSYNC_SCNより大きく、かつ変更がない場合、テナントのログ同期進捗統計に問題があることを意味し、テナントのログ同期進捗統計の問題についてさらに調査する必要があります。ビュー
V$OB_LS_LOG_RESTORE_STATUSの詳細については、V$OB_LS_LOG_RESTORE_STATUSを参照してください。
質問5：スタンバイデータベースにログストリームはあるがリーダーが存在しない
現象
上記の問題をすべて除外した後も、スタンバイテナントのログ同期が停止したままになる場合は、スタンバイテナントのログストリームにヘッドが存在しないか確認してみてください。
原因
スタンバイテナントは、プライマリテナントまたはアーカイブメディアからログを同期する際、ログストリームのリーダーが処理を実行した後、他のレプリカに同期します。スタンバイテナント上でログストリームのヘッドが存在しない場合、そのログストリームはログを同期できず、テナントレベルの SYNC_SCN の進行も停止し、結果としてすべてのログストリームの同期が停止します。
トラブルシューティングの手順
GV$OB_LOG_STAT ビューを使用して、テナント上で主が存在しないログストリームがあるかどうかを確認できます。
テナント管理者は、問題のテナントまたは問題のテナントが存在するクラスタの
sysテナントにログインします。GV$OB_LOG_STATビューを使用して、テナントのすべてのログストリームの状態情報を照会します。システムテナントから指定したテナントを参照する場合
SELECT TENANT_ID, LS_ID, ROLE FROM oceanbase.GV$OB_LOG_STAT WHERE TENANT_ID=1xxx;問題のテナントから自身を参照する場合
MySQLモードOracleモードステートメントは以下のとおりです：
SELECT TENANT_ID, LS_ID, ROLE FROM oceanbase.GV$OB_LOG_STAT;または、以下のステートメントを使用して、所有者のいないすべてのログストリームを直接取得することもできます。
SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE ROLE='LEADER');ステートメントは以下のとおりです：
SELECT TENANT_ID, LS_ID, ROLE FROM SYS.GV$OB_LOG_STAT;または、以下のステートメントを使用して、すべてのホストレスログストリームを直接取得することもできます。
SELECT DISTINCT TENANT_ID, LS_ID FROM SYS.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM SYS.GV$OB_LOG_STAT WHERE ROLE='LEADER');
クエリ結果では：
TENANT_ID：テナントIDを表します。LS_ID：ログストリームIDを表します。ROLE：ログストリームのロールを表します。LEADERはレプリカロールがリーダーを意味し、FOLLOWERはレプリカロールがフォロワーを意味します。ログストリームのすべてのレプリカが
FOLLOWERの場合、そのログストリームには主が存在しません。
また、以下のステートメントを使用して、すべての主のないログストリームを直接取得することもできます。
システムテナントから指定したテナントを参照する場合
SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE ROLE='LEADER');問題のテナントから自身を参照する場合
MySQLモードOracleモードステートメントは以下のとおりです：
SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM oceanbase.GV$OB_LOG_STAT WHERE ROLE='LEADER');ステートメントは以下のとおりです：
SELECT DISTINCT TENANT_ID, LS_ID FROM SYS.GV$OB_LOG_STAT WHERE (TENANT_ID, LS_ID) NOT IN (SELECT DISTINCT TENANT_ID, LS_ID FROM SYS.GV$OB_LOG_STAT WHERE ROLE='LEADER');
ビュー
GV$OB_LOG_STATの詳細については、GV$OB_LOG_STATを参照してください。クエリ結果に基づき、スタンバイテナントのログストリームに主が存在することを確認した後、同じ方法を使用してプライマリテナントのログストリームに主が存在しないかどうかを確認できます。プライマリテナントのログストリームに主が存在しない場合、それは間接的にスタンバイテナントのログストリームの同期が停止する原因となります。
課題6：プライマリ・スタンバイテナントのロールがどちらも STANDBY になる
現象
カスケードスタンバイがないシナリオでは、プライマリ・スタンバイ関係のテナントには少なくとも1つのプライマリテナント（テナントロールが PRIMARY）が必要です。そうでない場合、両テナントのログ同期の進捗が進まなくなります。
原因
プライマリテナントでSwitchoverによるプライマリ→スタンバイの切り替えを実行した後、元のプライマリ・スタンバイテナントのロールがどちらも STANDBY になると、この現象が発生します。
解決手順
DBA_OB_TENANTS ビューを使用して、プライマリ・スタンバイテナントのロールを個別に確認し、両テナントのロールがどちらも STANDBY であるかを確認します。
テナント管理者がプライマリ・スタンバイテナント、またはそれぞれのクラスタの
sysテナントにログインします。以下のステートメントを実行して、プライマリ・スタンバイテナントのロールを確認します。
システムテナントからプライマリまたはスタンバイテナントを確認する場合
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM oceanbase.DBA_OB_TENANTS;プライマリまたはスタンバイテナントから自身のテナントを確認する場合
MySQLモードOracleモードステートメントは以下のとおりです：
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM oceanbase.DBA_OB_TENANTS;ステートメントは以下のとおりです：
SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, STATUS FROM SYS.DBA_OB_TENANTS;
クエリ結果には以下の項目が含まれます：
TENANT_ID：テナントIDを表します。TENANT_NAME：テナント名を表します。TENANT_ROLE：テナントロールを表します。PRIMARYはプライマリテナントを、STANDBYはスタンバイテナントを表します。
クエリ結果に基づき、プライマリ・スタンバイテナントのロールがどちらも
STANDBYになっていないか確認します。ビュー
DBA_OB_TENANTSの詳細については、DBA_OB_TENANTS を参照してください。