本記事では、フィジカル・スタンバイ・データベースの同期処理中にログ同期が停止した場合の問題のトラブルシューティングおよび特定方法について説明します。
質問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 スタンバイテナントのバイナリバージョンが古く、アップグレードが必要です 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;問題のあるテナントが自身の
SYNC_SCNを確認する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を参照してください。