本記事では、物理スタンバイデータベースの同期処理中にログ同期が停止した場合のトラブルシューティングおよび問題特定方法について説明します。
問題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はログストリームの同期状態が正常であることを意味します。他の状態の場合は異常を示します。ログ同期状態とその意味は以下の表のとおりです。
ログ同期状態意味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;問題のあるテナントが自身のテナントを確認する場合
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より大きく、かつ変化がない場合、テナントのログ同期進捗統計に問題があることを意味し、テナントのログ同期進捗統計の問題についてさらに調査する必要があります。
質問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を参照してください。