スイッチオーバーまたはフェイルオーバー関連の問題

SWITCHOVER TO STANDBY VERIFY/SWITCHOVER TO STANDBY、SWITCHOVER TO PRIMARY VERIFY/SWITCHOVER TO PRIMARY、および ACTIVATE STANDBY VERIFY/ACTIVATE STANDBY などのコマンドを実行してプライマリからスタンバイへ、またはスタンバイからプライマリへの切り替えを行う際、システムがエラーメッセージを表示する場合があります。このエラーメッセージは、切り替えコマンドを正常に実行できない理由を示しています。この記事では、これらのエラーメッセージが表示された場合のトラブルシューティングと解決方法について説明します。

エラーメッセージ1

• ERROR HY000: log restore source is primary, switchover to primary is not allowed

• ERROR HY000: log restore source is not in normal switchover status, switchover to primary is not allowed

• ERROR HY000: log restore source is not in normal status, switchover to primary is not allowed

エラーの原因

スイッチオーバーを実行してスタンバイテナントをプライマリテナントに切り替える際、ログ復元ソースとなるテナントが以下の条件を満たしている必要があります：

1. テナントロール TENANT_ROLE が PRIMARY であること。

2. テナントステータス STATUS が NORMAL であること。

3. テナントの SWITCHOVER_STATUS が NORMAL であること。

上記のいずれかの条件を満たしていない場合、ネットワークベースのフィジカル・スタンバイ・データベースシナリオでは上記のエラーが発生する可能性があります。

対処方法

1. 復元ソースまたはアーカイブソースが存在するクラスタにログインし、復元ソースまたはアーカイブソースに対応するテナントのステータスを照会します。

   システムテナント

   ユーザーテナント

   システムテナントでは、以下のSQLを使用して復元ソースまたはアーカイブソースに対応するテナントの状態を確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, STATUS, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'tenant_name';
   

   ここで、tenant_name は復元ソースまたはアーカイブソースに対応するテナントのテナント名に置き換える必要があります。

   MySQLモードのテナントでは、以下のSQLを使用して現在のテナント（復旧ソースまたはアーカイブソースに対応するテナント）の状態を確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, STATUS, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
   

   Oracleモードのテナントでは、以下のSQLを使用して現在のテナント（復旧ソースまたはアーカイブソースに対応するテナント）の状態を確認します。

   obclient [SYS]> SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, STATUS, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
   

2. 照会結果に基づき、テナントのステータスが要件を満たしていないことが確認された場合は、ログ復元ソースまたはアーカイブソースに対応するテナントにログインしてプライマリからスタンバイへの切り替え操作を実行し、その後、現在のスタンバイからプライマリへの切り替え操作を再度実行します。

3. それでも問題が解決しない場合は、技術サポート担当者に連絡して支援を受けてください。

エラーメッセージ2

• ERROR HY000: tenant status is not normal, switchover to primary is not allowed

• ERROR HY000: tenant status is not normal, failover to primary is not allowed

• ERROR HY000: tenant status is not normal, switchover to standby is not allowed

エラーの原因

テナントのロール切り替え操作を実行する際、テナントのSTATUSがNORMAL状態であることが求められます。その状態にない場合、上記のエラーが発生する可能性があります。

対処方法

1. 以下のSQLを実行して、現在のテナントのステータスを確認します。

   システムテナント

   ユーザーテナント

   システムテナントでは、以下のSQLを使用して指定されたテナントの状態を確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, STATUS FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'tenant_name';
   

   ここで、tenant_name はロール切り替えコマンドを実行する対象のテナント名に置き換える必要があります。

   MySQLモードでは、次のSQLを使用して現在のテナントの状態を確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, STATUS FROM oceanbase.DBA_OB_TENANTS;
   

   Oracleモードでは、次のSQLを使用して現在のテナントの状態を確認します。

   obclient [SYS]> SELECT TENANT_NAME, STATUS FROM SYS.DBA_OB_TENANTS;
   

2. クエリ結果に基づき、テナントのステータスがNORMALでないことを確認した後、テナントのステータスがNORMALでない原因を調査します。テナントはまだ作成中または復旧中である可能性があります。テナントの作成または復旧が完了するまで待つか、技術サポート担当者に連絡して支援を受けることができます。

エラーメッセージ3

• ERROR HY000: switchover status not match, switchover to primary is not allowed

• ERROR HY000: switchover status not match, failover to primary is not allowed

• ERROR HY000: switchover status not match, switchover to standby is not allowed

エラーの原因

テナントのロール切り替え操作を実行する際、現在のテナントがマッチしない中間ロール切り替え状態にある場合、SWITCHOVER STATUS の状態が予想と異なるため、上記のエラーが発生します。

例えば、以下の2つのシナリオでは、テナントはマッチしない中間ロール切り替え状態にあります：

• 現在のテナントでプライマリからスタンバイへの切り替え操作を実行する必要がありますが、テナントは以前に一度失敗したスタンバイからプライマリへの切り替え操作があったため、その結果、SWITCHOVER STATUS が SWITCHING TO PRIMARY または他のスタンバイからプライマリへの中間状態になっています。

• 現在のテナントでスタンバイからプライマリへの切り替え操作を実行する必要がありますが、テナントは以前に一度失敗したプライマリからスタンバイへの切り替え操作があったため、その結果、SWITCHOVER STATUS が SWITCHING TO STANDBY または他のプライマリからスタンバイへの中間状態になっています。

対処方法

1. 以下のSQLを実行して、現在のテナントの SWITCHOVER_STATUS の状態を照会します。

   システムテナント

   ユーザーテナント

   システムテナントでは、以下のSQLを使用して指定されたテナントのSWITCHOVER_STATUSの状態を確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'tenant_name';
   

   ここで、tenant_nameはロール切り替えコマンドを実行する対象のテナント名に置き換える必要があります。

   MySQLモードでは、次のSQLを使用して現在のテナントのSWITCHOVER_STATUSのステータスを確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
   

   Oracleモードでは、次のSQLを使用して現在のテナントのSWITCHOVER_STATUSのステータスを確認します。

   obclient [SYS]> SELECT TENANT_NAME, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
   

   SWITCHOVER_STATUS フィールドの各ステータスの詳細については、DBA_OB_TENANTSを参照してください。

2. クエリしたテナントの SWITCHOVER_STATUS の状態に基づいて、現在のテナントで進行中のロール切り替えプロセスを確認し、対応するロール切り替えコマンドを再度実行します。

3. 問題が解決されない場合は、技術サポート担当者に連絡して支援を依頼してください。

エラーメッセージ4

ERROR HY000: Tenant name argument is incorrect. Only a user tenant is supported

エラーの原因

テナントロール切り替え操作を実行する際、現在のテナントのテナントタイプはユーザーテナントである必要があります。ユーザーテナントでない場合、上記のエラーが発生します。

対処方法

1. 以下のSQLを実行して、現在のテナントのテナントタイプを確認します。

   システムテナント

   ユーザーテナント

   システムテナントでは、以下のSQLを使用して指定されたテナントのテナントタイプを確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, TENANT_TYPE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'tenant_name';
   

   ここで、tenant_name はロール切り替えコマンドを実行する対象のテナント名に置き換える必要があります。

   MySQLモードでは、次のSQLを使用して現在のテナントのテナントタイプを確認します。

   obclient [oceanbase]> SELECT TENANT_NAME, TENANT_TYPE FROM oceanbase.DBA_OB_TENANTS;
   

   Oracleモードでは、次のSQLを使用して現在のテナントのテナントタイプを確認します。

   obclient [SYS]> SELECT TENANT_NAME, TENANT_TYPE FROM SYS.DBA_OB_TENANTS;
   

   クエリ結果で、現在のテナントの TENANT_TYPE を確認します。正しい TENANT_TYPE は USER である必要があります。

2. 現在のテナントのテナントタイプが USER でない場合は、条件に合致するユーザーテナントを選択し、再度テナントロール切り替えコマンドを実行してください。

エラーメッセージ5

ERROR HY000: Incorrect arguments to tenant name, please don't specify tenant name

エラーの原因

ログインユーザーテナントがテナントロール切り替え操作を実行する際、コマンド内でテナント名を指定することはできません。デフォルトでは現在のユーザーテナントになります。コマンド内でテナント名が指定されている場合、上記のエラーが発生します。

対処方法

コマンド内の TENANT tenant_name を削除し、再度切り替えコマンドを実行してください。

エラーメッセージ6

• ERROR HY000: the tenant has LS replicas without leader, switchover to primary is not allowed

• ERROR HY000: the tenant has LS replicas without leader, failover to primary is not allowed

エラーの原因

スタンバイからプライマリへの切り替え操作を実行する際、現在のテナントにリーダーのないログストリームが存在している場合は許可されません。現在のテナントにリーダーのないログストリームがあると、上記のエラーが発生します。

対処方法

1. 現在のテナントが属するクラスタのsysテナントにログインし、以下のSQLを実行して、リーダーのないログストリームの一覧を取得します。

   obclient [oceanbase]> SELECT DISTINCT A.TENANT_ID, A.LS_ID
   FROM CDB_OB_LS A LEFT JOIN oceanbase.GV$OB_LOG_STAT B ON A.LS_ID = B.LS_ID
   AND A.TENANT_ID = B.TENANT_ID AND B.ROLE='LEADER'
   WHERE B.LS_ID IS NULL
     AND A.STATUS NOT IN ('CREATING',
                         'CREATED',
                         'TENANT_DROPPING',
                         'CREATE_ABORT',
                         'PRE_TENANT_DROPPING')
     AND A.TENANT_ID IN (user_tenant_id, user_tenant_id - 1);
   

   ここで、user_tenant_idは対象テナントのTENANT_IDに置き換える必要があります。

   クエリ結果が空ではない場合、テナントにリーダーのないログストリームが存在することを意味します。

2. クエリ結果に基づいて、テナントにリーダーのないログストリームが存在することを確認したら、技術サポート担当者に連絡し、対応を依頼してください。

エラーメッセージ7

• ERROR HY000: the tenant has units on temporary offline servers, switchover to primary is not allowed

• ERROR HY000: the tenant has units on temporary offline servers, failover to primary is not allowed

エラーの原因

スタンバイからプライマリへの切り替え操作を実行する際、デフォルトではテナントが存在するマシンがすべてオンラインであることが求められます。もしマシンがオフライン状態、例えばダウンやネットワーク障害などにより、そのマシンが一時的または永続的にオフラインであり、かつそのマシン上に合法的なレプリカが存在しない場合、Switchover to PrimaryまたはFailover to Primaryの実行は許可されません。

上記のエラーは、テナントが存在するマシンの一部が一時的にオフライン状態であり、Switchover to PrimaryまたはFailover to Primaryの実行が許可されないことを示しています。

対処方法

1. スタンバイテナントが存在するクラスタのsysテナントにログインします。

2. テナントユニットを持つ一時的にオフラインになったマシンを照会し、マシンのLAST_OFFLINE_TIMEを取得します。

   obclient [oceanbase]> SELECT SVR_IP, SVR_PORT, LAST_OFFLINE_TIME, NOW() FROM oceanbase.DBA_OB_SERVERS WHERE LAST_OFFLINE_TIME IS NOT NULL AND (SVR_IP, SVR_PORT) IN ( SELECT DISTINCT SVR_IP, SVR_PORT FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = user_tenant_id);
   

   ここで、user_tenant_idはターゲットテナントのTENANT_IDに置き換える必要があります。

   クエリ結果の例：

   +----------------+----------+----------------------------+---------------------+
   | SVR_IP         | SVR_PORT | LAST_OFFLINE_TIME          | NOW()               |
   +----------------+----------+----------------------------+---------------------+
   | xxx.xx.xxx.212 |    13326 | 2023-12-07 10:44:53.928742 | 2023-12-07 15:58:26 |
   +----------------+----------+----------------------------+---------------------+
   

3. パラメータserver_permanent_offline_timeの値を照会し、取得したLAST_OFFLINE_TIMEとパラメータの値に基づいて、マシンの永続的なオフライン時間を判断します。

   クラスタレベルのパラメータserver_permanent_offline_timeは、ノードのハートビートが途絶えた後、どの程度の時間が経過すると永続的にオフラインとみなされるかを設定します。永続的にオフラインになったノード上のデータレプリカは自動的に補完する必要があります。この構成パラメータの詳細については、server_permanent_offline_timeを参照してください。

   obclient [oceanbase]> SHOW PARAMETERS LIKE 'server_permanent_offline_time';
   

   クエリ結果に基づいて、LAST_OFFLINE_TIME + server_permanent_offline_timeがNOW()以下であれば、マシンは永続的にオフラインになっています。そうでない場合は、マシンは一時的にオフラインです。

4. マシンが一時的にオフラインになる場合は、以下の手順を参照して対処できます。

   1. そのマシン上のobserverプロセスがまだ存在するかどうかを確認します。存在しない場合は、手動でobserverプロセスを起動し、再度スタンバイからプライマリへの切り替え操作を実行します。

      それでも成功しない場合は、次のステップを実行する必要があります。

   2. パラメータserver_permanent_offline_timeの値を小さくして、一時的にオフラインになったマシンが永続的なオフライン条件を満たすようにし、再度スタンバイからプライマリへの切り替え操作を実行します。

      パラメータserver_permanent_offline_timeの値を変更する際は、あまりにも小さく設定しないように注意してください。少なくとも20秒以上に設定することを推奨します。例：

      obclient [oceanbase]> ALTER SYSTEM SET server_permanent_offline_time = '30s';
      

      再度スタンバイからプライマリへの切り替え操作を実行した後、操作が失敗し、永続的にオフラインになったマシン上にレプリカがあるというメッセージが表示された場合は、本記事のエラーメッセージ8を参照してさらに処理を進めてください。その他の問題については、テクニカルサポートに連絡して支援を受けてください。

エラーメッセージ8

• ERROR HY000: the tenant has LS replicas on at least one of the permanent offline servers, switchover to primary is not allowed

• ERROR HY000: the tenant has LS replicas on at least one of the permanent offline servers, failover to primary is not allowed

エラーの原因

スタンバイからプライマリへの切り替え操作を実行する際、デフォルトではテナントが存在するマシンがすべてオンラインであることが求められます。もしマシンがオフライン状態、例えばダウンまたはネットワーク障害によりオフラインになっている場合、そのマシンは永続的にオフラインであり、かつ合法的なレプリカがそのマシン上に存在しない必要があります。

上記のエラーは、テナントのレプリカが永続的にオフラインのマシン上に存在しているため、Switchover to PrimaryまたはFailover to Primaryの実行が許可されないことを示しています。

対処方法

1. スタンバイテナントが存在するクラスタのsysテナントにログインします。

2. テナント内で永続的にオフラインになったマシンの情報を確認します。

   1. オフラインになったマシンのIPアドレスとLAST_OFFLINE_TIMEを照会します。

      obclient [oceanbase]> SELECT SVR_IP, SVR_PORT, LAST_OFFLINE_TIME, NOW() FROM oceanbase.DBA_OB_SERVERS WHERE LAST_OFFLINE_TIME IS NOT NULL AND (SVR_IP, SVR_PORT) IN ( SELECT DISTINCT SVR_IP, SVR_PORT FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = user_tenant_id);
      

      ここで、user_tenant_idはスタンバイテナントのTENANT_IDに置き換える必要があります。

   2. 構成パラメータserver_permanent_offline_timeの値を照会し、取得したLAST_OFFLINE_TIMEと構成パラメータの値に基づいて、マシンの永続的なオフライン時間を判断します。

      クラスタレベルの構成パラメータserver_permanent_offline_timeは、ノードのハートビートが途絶えた後、どの程度の時間が経つとノードが永続的にオフラインと見なされるかを設定するために使用されます。永続的にオフラインになったノード上のデータレプリカは自動的に補完する必要があります。この構成パラメータの詳細については、server_permanent_offline_timeを参照してください。

      obclient [oceanbase]> SHOW PARAMETERS LIKE 'server_permanent_offline_time';
      

   3. 2回の照会結果に基づいて、LAST_OFFLINE_TIME + server_permanent_offline_timeがNOW()以下であれば、マシンは永続的にオフラインになっています。

3. レプリカを削除するまでの時間間隔を照会します。

   obclient [oceanbase]> SHOW PARAMETERS LIKE '%balancer_idle_time%';
   

   取得したレプリカを削除するまでの時間間隔と前のステップで取得したLAST_OFFLINE_TIME + server_permanent_offline_timeに基づいて、現在の時間がLAST_OFFLINE_TIME + server_permanent_offline_timeよりも少なくとも2倍のbalancer_idle_time以上経過するまで待機し、その後次のステップを実行します。

4. ビューCDB_OB_LS_LOCATIONSを照会し、各ログストリームリーダーレプリカのMEMBER_LIST情報を確認して、永続的にオフラインになったマシンが存在するかどうかを確認します。

   obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = user_tenant_id AND ROLE = 'LEADER' AND MEMBER_LIST LIKE "%permanent_offline_server_ip:permanent_offline_server_port%";
   

   ここで：

   • user_tenant_idはターゲットテナントのTENANT_IDに置き換える必要があります。
   • permanent_offline_server_ipは永続的にオフラインになったマシンのIPアドレスに置き換える必要があります。
   • permanent_offline_server_portは永続的にオフラインになったマシンのRPCポート番号に置き換える必要があります。

   照会結果に基づいて、次のように判断します：

   • 照会結果が空でない場合、以下の操作を実行して、永続的にオフラインになったマシンをログストリームリーダーレプリカのMEMBER_LISTから削除するタスクが開始されているかどうかを確認する必要があります。

     obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE MODULE = 'disaster_recovery' AND EVENT LIKE "%remove_ls_paxos_replica%" ORDER BY TIMESTAMP DESC;
     

     照会結果に基づいて、検出された各ログストリームには、永続的にオフラインになったマシンをログストリームリーダーレプリカのMEMBER_LISTから削除する対応するタスクが存在するはずです。ログストリームでこのタスクが開始されていない、またはタスクが完了していない場合は、技術サポート担当者に連絡して支援を依頼してください。

   • 照会結果が空の場合、テナントのすべてのログストリームリーダーレプリカのMEMBER_LIST情報に永続的にオフラインになったマシンが存在しないことを意味します。次のステップに進み、各ログストリームリーダーレプリカのLEARNER_LIST情報を確認する必要があります。

5. ビューCDB_OB_LS_LOCATIONSを照会し、各ログストリームリーダーレプリカのLEARNER_LIST情報を確認して、永続的にオフラインになったマシンが存在するかどうかを確認します。

   obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = user_tenant_id AND ROLE = 'LEADER' AND LEARNER_LIST LIKE "%permanent_offline_server_ip:permanent_offline_server_port%";
   

   ここで：

   • user_tenant_idはターゲットテナントのTENANT_IDに置き換える必要があります。
   • permanent_offline_server_ipは永続的にオフラインになったマシンのIPアドレスに置き換える必要があります。
   • permanent_offline_server_portは永続的にオフラインになったマシンのRPCポート番号に置き換える必要があります。

   照会結果に基づいて、次のように判断します：

   • 照会結果が空でない場合、以下の操作を実行して、永続的にオフラインになったマシンをログストリームリーダーレプリカのLEARNER_LISTから削除するタスクが開始されているかどうかを確認する必要があります。

     obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE MODULE = 'disaster_recovery' AND EVENT LIKE "%remove_ls_non_paxos_replica%" ORDER BY TIMESTAMP DESC;
     

     照会結果では、検出された各ログストリームには、永続的にオフラインになったマシンをログストリームリーダーレプリカのLEADER_LISTから削除する対応するタスクが存在するはずです。ログストリームでこのタスクが開始されていない、またはタスクが完了していない場合は、技術サポート担当者に連絡して支援を依頼してください。

   • 照会結果が依然として空の場合、テナントのすべてのログストリームリーダーレプリカのLEARNER_LIST情報にも永続的にオフラインになったマシンが存在しないことを意味します。次のステップに進み、テナントに永続的にオフラインになったマシン上に余分なレプリカが残っているかどうかを確認する必要があります。

6. テナントのすべてのログストリームのLEADERレプリカのMEMBER_LISTおよびLEARNER_LIST情報に永続的にオフラインになったマシンが存在しない場合、少々待ってから、次のコマンドを実行して、テナントに永続的にオフラインになったマシン上に余分なレプリカが残っているかどうかを確認します。

   obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = user_tenant_id AND SVR_IP = 'permanent_offline_server_ip' AND SVR_PORT = permanent_offline_server_port;
   

   ここで：

   • user_tenant_idはターゲットテナントのTENANT_IDに置き換える必要があります。
   • permanent_offline_server_ipは永続的にオフラインになったマシンのIPアドレスに置き換える必要があります。
   • permanent_offline_server_portは永続的にオフラインになったマシンのRPCポート番号に置き換える必要があります。

   照会結果が空の場合、テナントに永続的にオフラインになったマシン上に余分なレプリカが残っていないことを意味します。その場合は、スタンバイ切り替え操作を再試行してください。それでも成功しない場合は、技術サポートに連絡して支援を依頼してください。

   照会結果が空でない場合、テナントに永続的にオフラインになったマシン上に余分なレプリカが残っていることを意味します。その場合は、一定時間待機してから、再度永続的にオフラインになったマシン上に余分なレプリカが残っているかどうかを確認する必要があります。もし永続的にオフラインになったマシン上にレプリカが残っていない場合は、スタンバイ切り替え操作を再試行してください。テナントにまだレプリカが残っている場合は、技術サポート担当者に連絡して支援を依頼してください。

7. 他に問題がある場合は、技術サポート担当者に連絡して支援を依頼してください。

エラーメッセージ9

ERROR HY000: wait tenant sync to latest failed(original error code: -4012), switchover to primary is not allowed

エラーの原因

スイッチオーバーを実行してスタンバイテナントをプライマリテナントに切り替える際、そのスタンバイテナントが復旧元とのログストリームと同期している必要があります。ログストリームが同期していない場合、上記のエラーが発生します。

対処方法

• ネットワークに基づくフィジカル・スタンバイ・データベース

  1. プライマリテナントとスタンバイテナント間のネットワーク接続状態を確認します。

     ネットワーク接続に問題がないことを確認したら、次のステップに進みます。

  2. スタンバイテナントが属するクラスタのsysテナントにログインし、スタンバイテナントの復旧状態を確認します。

     obclient [oceanbase]> SELECT LS_ID, SYNC_SCN, SYNC_STATUS, ERR_CODE, COMMENT FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID = user_tenant_id;
     

     ここで、user_tenant_idはスタンバイテナントのTENANT_IDに置き換える必要があります。

     クエリ結果に基づいて、SYNC_STATUSがNORMALの場合、SYNC_SCNが増加し続けているかどうかを確認します。増加していない場合、またはSYNC_STATUSが他の状態の場合は、技術サポート担当者に連絡して対応を依頼してください。

• ログアーカイブに基づくフィジカル・スタンバイ・データベース

  1. ログアーカイブに対応するテナントのテナントロールがSTANDBYであるかどうかを確認します。

     システムテナント

     ユーザーテナント

     システムテナントの状態は、以下のSQLを実行して確認します。

     obclient [oceanbase]> SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, STATUS, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'tenant_name';
     

     ここで、tenant_name は復旧元またはアーカイブ元の対応するテナント名に置き換える必要があります。

     MySQLモードのテナントでは、次のSQLを使用して現在のテナントの状態を確認します。

     obclient [oceanbase]> SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, STATUS, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
     

     Oracleモードのテナントでは、次のSQLを使用して現在のテナントの状態を確認します。

     obclient [SYS]> SELECT TENANT_NAME, TENANT_ID, TENANT_ROLE, STATUS, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
     

     クエリ結果に基づいて、現在のテナントのTENANT_ROLEがSTANDBYでない場合は、まずそのテナントをスタンバイテナントに切り替える必要があります。

     クエリ結果が以下のようになっている場合、テナントの状態は正常であり、次のステップに進むことができます。

     +-------------+--------+-------------------+
     | TENANT_ROLE | STATUS | SWITCHOVER_STATUS |
     +-------------+--------+-------------------+
     | STANDBY     | NORMAL | NORMAL            |
     +-------------+--------+-------------------+
     

  2. スタンバイテナントが属するクラスタのsysテナントにログインし、スタンバイテナントの復旧状態を確認します。

     obclient [oceanbase]> SELECT LS_ID, SYNC_SCN, SYNC_STATUS, ERR_CODE, COMMENT FROM oceanbase.V$OB_LS_LOG_RESTORE_STATUS WHERE TENANT_ID = user_tenant_id;
     

     ここで、user_tenant_idはスタンバイテナントのTENANT_IDに置き換える必要があります。

     クエリ結果に基づいて、SYNC_STATUSがNORMALの場合、SYNC_SCNが増加し続けているかどうかを確認します。増加していない場合、またはSYNC_STATUSが他の状態の場合は、技術サポート担当者に連絡して対応を依頼してください。

エラーメッセージ10

ERROR HY000: log restore source LS state not match, switchover to primary not allowed

エラーの原因

ネットワークに基づくフィジカル・スタンバイ・データベースのシナリオでは、スタンバイテナントをプライマリテナントに切り替えるSwitchover操作を実行する場合、ログ復元ソースとなるテナントのログストリームのACCESS_MODEがすべてRAW_WRITEである必要があります。この条件を満たしていない場合、上記のエラーが発生する可能性があります。

対処方法

1. ログ復元ソースとなるテナントが属するクラスタのsysテナントにログインします。

2. そのテナントのログストリームのACCESS_MODEを確認します。

   obclient [oceanbase]> SELECT LS_ID, ACCESS_MODE FROM oceanbase.GV$OB_LOG_STAT WHERE TENANT_ID = user_tenant_id AND ROLE = 'LEADER';
   

   ここで、user_tenant_idはログ復元ソースとなるテナントのTENANT_IDに置き換える必要があります。

   クエリ結果によると、ログストリームのACCESS_MODEがRAW_WRITE以外のものがある場合、一部のログストリームがガベージコレクションを待機している可能性があります。ログストリームが回収された後、再度Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替えてください。それでも成功しない場合は、技術サポート担当者までお問い合わせください。

エラーメッセージ11

ERROR HY000: query primary failed(original error code: -2002), switchover to primary is not allowed

エラーの原因

ネットワークに基づくフィジカル・スタンバイ・データベースのシナリオでは、スイッチオーバー操作を実行してスタンバイテナントをプライマリテナントに切り替えるためには、現在のスタンバイテナントがログ復旧元テナントに接続できること、およびそのテナント内の一部の必要なシステムビューに対するクエリ権限を持っていることが求められます。

上記のエラーは、ログ復旧元テナントが存在するサーバーが停止したか、またはネットワークが不通であることを示しています。

対処方法

1. ログ復旧元テナントの関連情報を取得します。

   1. 現在のスタンバイテナント、またはスタンバイテナントが属するクラスタのsysテナントにログインします。

   2. 以下のコマンドを実行して、ログ復旧元テナントの関連情報を取得します。

      • システムテナントからのクエリ

        obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE tenant_id = xxxx\G
        

        ここで、tenant_idは現在のスタンバイテナントのtenant_idに置き換える必要があります。

      • ユーザーテナントからのクエリ

        MySQLモード

        Oracleモード

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

        obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE\G
        

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

        obclient [oracle]> SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE\G
        

      クエリ結果の例：

      *************************** 1. row ***************************
               TENANT_ID: 1004
                      ID: 1
                    TYPE: SERVICE
                   VALUE: IP_LIST=100.xx.xx.xxx:13359;100.xx.xxx.xxx:13361,USER=mytest@backup_mysql_tenant,PASSWORD=*********************************************,TENANT_ID=1002,CLUSTER_ID=1,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
      RECOVERY_UNTIL_SCN: 4611686018427387903
      1 row in set
      

      クエリ結果において、VALUEフィールドのIP_LIST=xxxx属性は、ログ復旧元テナントが存在するサーバーのIPアドレスとポート番号を示しています。

2. ログ復旧元テナントが存在するサーバーのネットワーク接続性を確認するか、手動でobserverプロセスを起動した後、再度Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替えます。再実行後も成功しない場合は、技術サポート担当者に連絡し、対応を依頼してください。

エラーメッセージ12

エラーの原因

ネットワークに基づくフィジカル・スタンバイ・データベースのシナリオでは、スイッチオーバー操作を実行してスタンバイテナントをプライマリテナントに切り替えるためには、現在のスタンバイテナントがログ復旧元テナントに接続できること、およびそのテナント内の一部の必要なシステムビューに対するクエリ権限を持っていることが求められます。

上記のエラーは、ログ復旧元に接続するユーザー（ログ復旧元を設定する際に指定された専用ユーザー）がシステムビューのクエリ権限を持っていない、または一部のシステムビューに対するクエリ権限が不足していることを示しています。

対処方法

1. ログ復旧ソーステナントに関する情報を取得します。

   1. 現在のスタンバイテナント、またはスタンバイテナントが属するクラスタのsysテナントにログインします。

   2. 以下のコマンドを実行して、ログ復旧ソーステナントに関する情報を取得します。

      • システムテナントでのクエリ

        obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE tenant_id = xxxx\G
        

        ここで、tenant_idは現在のスタンバイテナントのtenant_idに置き換える必要があります。

      • ユーザーテナントでのクエリ

        MySQLモード

        Oracleモード

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

        obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE\G
        

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

        obclient [oracle]> SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE\G
        

      クエリ結果の例：

      *************************** 1. row ***************************
               TENANT_ID: 1004
                      ID: 1
                    TYPE: SERVICE
                   VALUE: IP_LIST=100.xx.xx.xxx:13359;100.xx.xxx.xxx:13361,USER=mytest@backup_mysql_tenant,PASSWORD=*********************************************,TENANT_ID=1002,CLUSTER_ID=1,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
      RECOVERY_UNTIL_SCN: 4611686018427387903
      1 row in set
      

      クエリ結果において、VALUEフィールドのUSER=xxxプロパティに対応する情報が、ログ復旧ソーステナントに関する情報です。この例では、mytestはログ復旧ソースを設定する際に指定した専用ユーザー名であり、ログ復旧ソースに接続するユーザーを指します。backup_mysql_tenantはログ復旧ソーステナントに対応するテナント名です。

2. 復旧ソースを設定する際に指定した専用ユーザーで現在のスタンバイテナントにログインします。

3. 現在のユーザーが保有する権限を確認し、ログ復旧ソーステナント内の一部の必要なシステムビューへのクエリ権限を持っているかどうかを確認します。

   • MySQLモードのテナントで現在のユーザーが保有する権限の詳細な操作については、ユーザー権限の確認を参照してください。

   • Oracleモードのテナントで現在のユーザーが保有する権限の詳細な操作については、ユーザー権限の確認を参照してください。

   ネットワークベースのフィジカル・スタンバイ・データベースの場合、ビューにアクセスするための専用ユーザーに必要なユーザー権限については、ログ復旧ソースの設定を参照してください。クエリ結果に基づき、現在のユーザーがドキュメントで要求される権限を持っていない場合は、現在のユーザーに対して該当する権限を付与してください。

4. 権限付与が完了したら、再度Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替えます。再度実行しても成功しない場合は、技術サポート担当者に連絡して支援を依頼してください。

エラーメッセージ13

ERROR HY000: query primary failed(original error code: -1045), switchover to primary is not allowed

エラーの原因

ネットワークベースのフィジカル・スタンバイ・データベースシナリオにおいて、スイッチオーバー操作を実行してスタンバイテナントをプライマリテナントに切り替える場合、現在のスタンバイテナントはログ復旧ソーステナントに接続できる必要があり、そのテナント内の一部の必要なシステムビューに対するクエリ権限を持っている必要があります。

上記のエラーは、ログ復旧ソースに接続するユーザー（ログ復旧ソースを設定した際に指定された専用ユーザー）のユーザー名またはパスワードが誤っていることを示しています。

対処方法

1. ログ復旧ソーステナントの関連情報を取得します。

   1. 現在のスタンバイテナント、またはスタンバイテナントが属するクラスタのsysテナントにログインします。

   2. 以下のコマンドを実行して、ログ復旧ソーステナントの関連情報を取得します。

      • システムテナントでのクエリ

        obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE tenant_id = xxxx\G
        

        ここで、tenant_idは現在のスタンバイテナントのtenant_idに置き換える必要があります。

      • ユーザーテナントでのクエリ

        MySQLモード

        Oracleモード

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

        obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE\G
        

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

        obclient [oracle]> SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE\G
        

      クエリ結果の例は次のとおりです：

      *************************** 1. row ***************************
               TENANT_ID: 1004
                      ID: 1
                    TYPE: SERVICE
                   VALUE: IP_LIST=100.xx.xx.xxx:13359;100.xx.xxx.xxx:13361,USER=mytest@backup_mysql_tenant,PASSWORD=*********************************************,TENANT_ID=1002,CLUSTER_ID=1,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
      RECOVERY_UNTIL_SCN: 4611686018427387903
      1 row in set
      

      クエリ結果において、VALUEフィールドのUSER=xxx属性に対応する情報がログ復旧ソーステナントの関連情報です。この例では、mytestはログ復旧ソースを設定した際に指定された専用ユーザー名、つまりログ復旧ソースに接続するユーザーです。backup_mysql_tenantはログ復旧ソーステナントに対応するテナント名です。

2. クエリ結果に基づいて、ログ復旧ソースに接続するユーザーのユーザー名とパスワードが正しいかどうか確認してください。

   ユーザー名とパスワードがどちらも正しい場合は、技術サポート担当者に連絡して対応を依頼してください。

エラーメッセージ14

query primary failed(original error code: -xxxx), switchover to primary is not allowed

ネットワークベースのフィジカル・スタンバイ・データベースシナリオにおいて、Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替える際に、上記のようなエラーメッセージが表示され、かつエラーコードが本記事で説明されていない他のエラーコードである場合は、以下の方法で対処してください。

1. ログ復旧元となるソーステナントに関する情報を取得します。

   1. 現在のスタンバイテナント、またはそのスタンバイテナントが属するクラスタのsysテナントにログインします。

   2. 以下のコマンドを実行して、ログ復旧元となるソーステナントに関する情報を取得します。

      • システムテナントからのクエリ

        obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE tenant_id = xxxx\G
        

        ここで、tenant_idは現在のスタンバイテナントのtenant_idに置き換える必要があります。

      • ユーザーテナントからのクエリ

        MySQLモード

        Oracleモード

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

        obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE\G
        

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

        obclient [oracle]> SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE\G
        

      クエリ結果の例：

      *************************** 1. row ***************************
               TENANT_ID: 1004
                      ID: 1
                    TYPE: SERVICE
                   VALUE: IP_LIST=100.xx.xx.xxx:13359;100.xx.xxx.xxx:13361,USER=mytest@backup_mysql_tenant,PASSWORD=*********************************************,TENANT_ID=1002,CLUSTER_ID=1,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
      RECOVERY_UNTIL_SCN: 4611686018427387903
      1 row in set
      

      クエリ結果において、VALUEフィールドのIP_LIST=xxxx属性は、ログ復旧元となるソーステナントが存在するサーバーのIPアドレスとポート番号を示しています。

2. 復旧元となるソーステナントが存在するサーバーがすべてサービスを提供できるかどうか確認します。

   サーバーのうちサービスを提供できないものがある場合は、しばらく待ってサーバーがサービスを提供できるようになったら、再度Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替えてください。再度実行しても成功しない場合は、技術サポート担当者までご連絡ください。

   すべてのサーバーがサービスを提供できる場合は、技術サポート担当者までご連絡ください。

エラーメッセージ15

ERROR HY000: primary tenant's user account is locked, switchover to primary is not allowed

エラーの原因

ネットワークベースのフィジカル・スタンバイ・データベースシナリオにおいて、Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替える場合、ログ復旧ソースに接続するユーザー（ログ復旧ソース設定時に指定した専用ユーザー）がロックされていないことが求められます。ログ復旧ソースに接続するユーザーがロックされていると、上記のエラーが発生する可能性があります。

対処方法

1. ログ復元ソーステナントに関する情報を取得します。

   1. 現在のスタンバイテナント、またはスタンバイテナントが属するクラスタのsysテナントにログインします。

   2. 以下のコマンドを実行して、ログ復元ソーステナントに関する情報を取得します。

      • システムテナントでのクエリ

        obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE tenant_id = xxxx\G
        

        ここで、tenant_idは現在のスタンバイテナントのtenant_idに置き換える必要があります。

      • ユーザーテナントでのクエリ

        MySQLモード

        Oracleモード

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

        obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE\G
        

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

        obclient [oracle]> SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE\G
        

      クエリ結果の例は次のとおりです：

      *************************** 1. row ***************************
               TENANT_ID: 1004
                      ID: 1
                    TYPE: SERVICE
                   VALUE: IP_LIST=100.xx.xx.xxx:13359;100.xx.xxx.xxx:13361,USER=mytest@backup_mysql_tenant,PASSWORD=*********************************************,TENANT_ID=1002,CLUSTER_ID=1,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
      RECOVERY_UNTIL_SCN: 4611686018427387903
      1 row in set
      

      クエリ結果において、VALUEフィールドのUSER=xxxプロパティに対応する情報がログ復元ソーステナントに関する情報です。この例では、mytestはログ復元ソースを設定する際に指定した専用ユーザー名、つまりログ復元ソースに接続するユーザーです。backup_mysql_tenantはログ復元ソーステナントに対応するテナント名です。

2. 管理者ユーザーとしてログ復元ソーステナントにログインします。

3. 以下のコマンドを実行して、ログ復元ソースに接続するユーザーがロック状態かどうかを確認します。

   MySQLモード

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

   obclient [oceanbase]> SELECT user_name,is_locked FROM oceanbase.DBA_OB_USERS WHERE user_name='mysql_tenant';
   

   tab Oracleモード

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

   obclient [SYS]> SELECT user_name,is_locked FROM SYS.ALL_VIRTUAL_USER_REAL_AGENT WHERE user_name='oracle_tenant';
   

   :::

   クエリ結果において、is_lockedの値がYESの場合、そのユーザーはロック状態であることを意味します。

4. 以下のコマンドを実行して、ユーザーのロックを解除します。

   obclient> ALTER USER user_name ACCOUNT UNLOCK;
   

   ここで、user_nameはログ復元ソースに接続するためのユーザー名に置き換える必要があります。

   ユーザーのロックとアンロックの詳細な操作および説明については、MySQLモードにおけるユーザーのロックとアンロックおよびOracleモードにおけるユーザーのロックとアンロックを参照してください。

5. ユーザーのロック解除操作が完了したら、再度Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替えます。再度実行しても成功しない場合は、技術サポート担当者に連絡し、対応を依頼してください。

エラーメッセージ16

ERROR HY000: primary tenant is locked, switchover to primary is not allowed

エラーの原因

ネットワークベースのフィジカル・スタンバイ・データベースシナリオにおいて、Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替える場合、ログ復旧元のソーステナントがロックされていないことが求められます。ログ復旧元のソーステナントがロックされていると、上記のエラーが発生する可能性があります。

対処方法

1. ログ復旧元のソーステナントに関する情報を取得します。

   1. 現在のスタンバイテナントまたはスタンバイテナントが属するクラスタのsysテナントにログインします。

   2. 以下のコマンドを実行して、ログ復旧元のソーステナントに関する情報を取得します。

      • システムテナントでのクエリ

        obclient [oceanbase]> SELECT * FROM oceanbase.CDB_OB_LOG_RESTORE_SOURCE WHERE tenant_id = xxxx\G
        

        ここで、tenant_idは現在のスタンバイテナントのtenant_idに置き換える必要があります。

      • ユーザーテナントでのクエリ

        MySQLモード

        Oracleモード

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

        obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_LOG_RESTORE_SOURCE\G
        

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

        obclient [oracle]> SELECT * FROM SYS.DBA_OB_LOG_RESTORE_SOURCE\G
        

      クエリ結果の例は次のとおりです：

      *************************** 1. row ***************************
               TENANT_ID: 1004
                      ID: 1
                    TYPE: SERVICE
                   VALUE: IP_LIST=100.xx.xx.xxx:13359;100.xx.xxx.xxx:13361,USER=mytest@backup_mysql_tenant,PASSWORD=*********************************************,TENANT_ID=1002,CLUSTER_ID=1,COMPATIBILITY_MODE=MYSQL,IS_ENCRYPTED=true
      RECOVERY_UNTIL_SCN: 4611686018427387903
      1 row in set
      

      クエリ結果において、VALUEフィールドのUSER=xxx属性に対応する情報がログ復旧元のソーステナントに関する情報です。この例では、mytestはログ復旧元を設定する際に指定した専用ユーザー名、つまりログ復旧元に接続するユーザーです。backup_mysql_tenantはログ復旧元テナントに対応するテナント名です。

2. ログ復旧元のソーステナントが属するクラスタのsysテナントにログインします。

3. 以下のコマンドを実行して、そのテナントがロックされているかどうかを確認します。

   obclient [oceanbase]> SELECT LOCKED FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_ID = user_tenant_id;
   

   ここで、user_tenant_idはログ復旧元テナントのTENANT_IDに置き換える必要があります。

   クエリ結果において、該当するテナントのLOCKEDフィールドの値がYESである場合、そのテナントはすでにロックされています。

4. 以下のコマンドを実行して、テナントのロックを解除します。

   obclient [oceanbase]> ALTER TENANT tenant_name UNLOCK;
   

   ここで、tenant_nameはログ復旧元テナントのテナント名に置き換える必要があります。

   テナントのロック解除の詳細な操作と説明については、テナントのロックとロック解除を参照してください。

5. テナントのロック解除操作が完了したら、再度Switchover操作を実行してスタンバイテナントをプライマリテナントに切り替えます。再度実行しても成功しない場合は、技術サポート担当者に連絡して支援を依頼してください。