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

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: Incorrect arguments to tenant name, only support operating user tenant

エラーの原因

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

解決策

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を実行することが許可されないことを示しています。

解決策

1. スタンバイテナントが配置されているクラスタのsysテナントにログインします。

2. テナントUnitがある一時的にオフラインのマシンを照会し、マシンの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. テナントのすべてのログストリームのリーダーレプリカの 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

エラーの原因

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

解決策

• ネットワークベースの物理スタンバイデータベース

  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
          RECOVERY_DELAY: 0
      1 row in set
      

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

2. ログ復元元のプライマリテナントが存在するサーバーのネットワーク接続状況を確認するか、手動でobserverプロセスを起動した後、再度スイッチオーバー操作を実行してスタンバイテナントをプライマリテナントに切り替えます。再度実行しても成功しない場合は、テクニカルサポートにお問い合わせください。

エラーメッセージ 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
          RECOVERY_DELAY: 0
      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

エラー原因

ネットワークベースの物理スタンバイデータベースシナリオにおいて、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
          RECOVERY_DELAY: 0
      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
          RECOVERY_DELAY: 0
      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

エラーの原因

ネットワークベースの物理スタンバイデータベースシナリオにおいて、スイッチオーバー操作を実行してスタンバイテナントをプライマリテナントに切り替える場合、ログ復元ソースに接続するユーザー（ログ復元ソース設定時に指定した専用ユーザー）がロックされていてはなりません。ログ復元ソースに接続するユーザーがロックされていると、上記のエラーが発生する可能性があります。

解決策

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
          RECOVERY_DELAY: 0
      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
          RECOVERY_DELAY: 0
      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操作を実行してスタンバイテナントをプライマリテナントに切り替えます。再度実行しても成功しない場合は、テクニカルサポートにお問い合わせください。