テナントのためにアービトレーションサービスを有効にする

テナント作成時にアービトレーションサービスを有効にすることも、テナント作成後に有効にすることもできます。テナント作成およびアービトレーションサービスの有効化に関する操作については、テナントの作成を参照してください。アービトレーションサービスが有効でない場合でも、テナント作成後に有効にすることが可能です。このセクションでは、既存のテナントのためにアービトレーションサービスを有効にする方法について説明します。

前提条件

• 現在のクラスタにアービトレーションサービスがデプロイ済みであることを確認してください。アービトレーションサービスのデプロイ手順の詳細については、2レプリカ + アービトレーションサービスのOceanBaseクラスタのデプロイを参照してください。

• アービトレーションサービスを有効にする前に、アービトレーションサービスを有効にするテナントのLocalityが2Fまたは4Fであることを確認してください。現在、Localityが2Fまたは4Fのテナントのみがアービトレーションサービスを有効にできます。

  説明

  アービトレーションサービスを有効にする際は、テナントのLocality内のFレプリカの数にのみ要件があり、Rレプリカの数に制限はありません。例えば、テナントのLocalityがF@z1,F@z2またはF@z1,F@z2,R@z3の場合、どちらもアービトレーションサービスを有効にできます。

手順

1. rootユーザーでクラスタのsysテナントにログインします。

   接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
   

   より詳細なデータベース接続操作の手順については、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。

2. 以下のコマンドを実行し、クラスタ内の各ノードの接続状態を確認します。

   obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_ARBITRATION_SERVICE_STATUS;
   

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

   +----------------+----------+-----------------------------+----------+
   | SVR_IP         | SVR_PORT | ARBITRATION_SERVICE_ADDRESS | STATUS   |
   +----------------+----------+-----------------------------+----------+
   | xx.xx.xx.197   |     2882 | xx.xx.xx.192:2882           | ACTIVE   |
   | xx.xx.xx.194   |     2882 | xx.xx.xx.192:2882           | ACTIVE   |
   +----------------+----------+-----------------------------+----------+
   2 rows in set
   

   クエリ結果のSTATUSフィールドの値に基づいて、各ノードとアービトレーションサービスとの接続状態を判断します：

   • ACTIVE：アービトレーションサービスがそのノードと正常に通信していることを示します。すべてのノードが正常に通信している場合にのみ、テナントのためにアービトレーションサービスを有効にできます。
   • INACTIVE：アービトレーションサービスがそのノードと通信できないことを示します。テナントのためにアービトレーションサービスを有効にすることはできません。ノードとアービトレーションサービス間のネットワーク通信状況を調査する必要があります。

3. 以下のコマンドを実行して、テナントのアービトレーションサービスの状態を確認します。

obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANTS WHERE tenant_name = 'oracle001'\G

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

*************************** 1. row ***************************
                 TENANT_ID: 1004
               TENANT_NAME: oracle001
               TENANT_TYPE: USER
               CREATE_TIME: 2026-01-26 19:40:21.457857
               MODIFY_TIME: 2026-01-27 13:51:47.053502
              PRIMARY_ZONE: zone1;zone2
                  LOCALITY: FULL{1}@zone1, FULL{1}@zone2
         PREVIOUS_LOCALITY: NULL
        COMPATIBILITY_MODE: ORACLE
                    STATUS: NORMAL
             IN_RECYCLEBIN: NO
                    LOCKED: NO
               TENANT_ROLE: PRIMARY
         SWITCHOVER_STATUS: NORMAL
          SWITCHOVER_EPOCH: 0
                  SYNC_SCN: 1687845116605766616
            REPLAYABLE_SCN: 1687845116605766616
              READABLE_SCN: 1687845116605766616
        RECOVERY_UNTIL_SCN: 4611686018427387903
                  LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: DISABLED
                  UNIT_NUM: 1
        ZONE_UNIT_NUM_LIST: zone1:1,zone2:1
                COMPATIBLE: 4.4.2.1
                 MAX_LS_ID: 1002
         RESTORE_DATA_MODE: NORMAL
         FLASHBACK_LOG_SCN: NULL
                   COMMENT:
           PROTECTION_MODE: MAXIMUM PERFORMANCE
          PROTECTION_LEVEL: MAXIMUM PERFORMANCE
1 row in set

テナントのアービトレーションサービスには、主に以下のような状態があります：

• ENABLED：テナントでアービトレーションサービスが有効であることを示します。

• DISABLED：テナントでアービトレーションサービスが無効であることを示します。

• ENABLING：テナントでアービトレーションサービスが有効になっていることを示します。

• DISABLING：テナントでアービトレーションサービスが無効になっていることを示します。

クエリ結果によると、ARBITRATION_SERVICE_STATUS列の値はDISABLEDであり、このテナントでアービトレーションサービスが無効であることを示しています。

DBA_OB_TENANTSビューの詳細については、DBA_OB_TENANTSを参照してください。

4. 以下のコマンドを実行して、テナントのアービトレーションサービスを有効にします。

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

ALTER TENANT tenant_name [SET] ENABLE_ARBITRATION_SERVICE = true;

ここで、tenant_nameはアービトレーションサービスを有効にするテナント名です。SETキーワードはオプションです。

テナントoracle001のアービトレーションサービスを有効にする例は以下のとおりです：

obclient(root@sys)[oceanbase]> ALTER TENANT oracle001 ENABLE_ARBITRATION_SERVICE = true;

5. コマンドの実行が成功した後、再度DBA_OB_TENANTSビューをクエリして、テナントのアービトレーションサービスが有効になっているかどうかを確認します。

obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANTS WHERE tenant_name = 'oracle001'\G

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

*************************** 1. row ***************************
                 TENANT_ID: 1004
               TENANT_NAME: oracle001
               TENANT_TYPE: USER
               CREATE_TIME: 2026-01-26 19:40:21.457857
               MODIFY_TIME: 2026-01-27 13:54:29.486203
              PRIMARY_ZONE: zone1;zone2
                  LOCALITY: FULL{1}@zone1, FULL{1}@zone2
         PREVIOUS_LOCALITY: NULL
        COMPATIBILITY_MODE: ORACLE
                    STATUS: NORMAL
             IN_RECYCLEBIN: NO
                    LOCKED: NO
               TENANT_ROLE: PRIMARY
         SWITCHOVER_STATUS: NORMAL
          SWITCHOVER_EPOCH: 0
                  SYNC_SCN: 1687845307275557916
            REPLAYABLE_SCN: 1687845307275557916
              READABLE_SCN: 1687845307131393135
        RECOVERY_UNTIL_SCN: 4611686018427387903
                  LOG_MODE: NOARCHIVELOG
ARBITRATION_SERVICE_STATUS: ENABLED
                  UNIT_NUM: 1
        ZONE_UNIT_NUM_LIST: zone1:1,zone2:1
                COMPATIBLE: 4.4.2.1
                 MAX_LS_ID: 1002
         RESTORE_DATA_MODE: NORMAL
         FLASHBACK_LOG_SCN: NULL
                   COMMENT:
           PROTECTION_MODE: MAXIMUM PERFORMANCE
          PROTECTION_LEVEL: MAXIMUM PERFORMANCE
1 row in set

クエリ結果によると、ARBITRATION_SERVICE_STATUS列の値はENABLEDであり、このテナントでアービトレーションサービスが有効であることを示しています。

6. アービトレーションサービスを有効にした後でも、テナントにはアービトレーションメンバーが欠けているログストリームが存在する可能性があります。このようなログストリームでは、昇格・降格操作を正常に実行できません。以下の手順で確認できます。

テナントのアービトレーションサービスが正常に有効になったことは、有効化時点で作成されたすべてのログストリームがアービトレーションサービスを利用できることを意味します。しかし、アービトレーションサービスを有効にした後に新規作成されるログストリームは、アービトレーションメンバーが欠けている可能性があります。これは、ログストリームの作成が非厳密モードで実行されるため、アービトレーションメンバーが必ず作成されるとは限らないからです。この場合、以下のステートメントを使用して、当該テナントのすべてのログストリームにアービトレーションメンバーが存在するかどうかを確認できます。

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

(SELECT distinct ls_id FROM GV$OB_LOG_STAT WHERE tenant_id = tenantid) EXCEPT
(SELECT ls_id FROM GV$OB_LOG_STAT WHERE tenant_id = tenantid AND role = 'LEADER' AND arbitration_member = 'arb_server_ip:arb_server_port');

関連パラメータの説明は以下のとおりです：

• tenantid：アービトレーションサービスを有効にしたテナントのテナントIDを表します。

• arb_server_ip：アービトレーションサービスのIPアドレスを表します。

• arb_server_port：アービトレーションサービスのRPCポートを表します。デフォルトは2882です。

例：

obclient(root@sys)[oceanbase]> (SELECT distinct ls_id FROM GV$OB_LOG_STAT WHERE tenant_id = 1004) EXCEPT
(SELECT ls_id FROM GV$OB_LOG_STAT where tenant_id = 1004 and role = 'LEADER' and arbitration_member = '100.xx.xx.xx:2882');

クエリ結果が空の場合、すべてのログストリームにアービトレーションメンバーが存在し、アービトレーションサービスが利用可能であることを意味します。クエリ結果が空でない場合、Root Serviceがバックグラウンドでこれらのログストリームのためにアービトレーションメンバーを追加します。CDB_OB_LS_ARB_REPLICA_TASKS ビューで、アービトレーションメンバーの追加タスクが実行中かどうかを確認できます。アービトレーションメンバーの追加タスクが存在し実行中である場合は、タスクの実行完了を待機する必要があります。

アービトレーションメンバーの追加タスクの実行が完了したら、CDB_OB_LS_ARB_REPLICA_TASK_HISTORY ビューでタスクの実行結果を確認できます。タスクが正常に実行された場合、ログストリームのアービトレーションメンバーの追加が成功し、アービトレーションサービスが利用可能であることを意味します。タスクの実行に失敗した場合は、テクニカルサポートにお問い合わせください。

`GV$OB_LOG_STAT` ビューのフィールドの詳細については、[GV$OB_LOG_STAT](../../../700.reference/700.system-views/400.system-view-of-mysql-mode/300.performance-view-of-mysql-mode/1300.gv-ob_log_stat-of-mysql-mode.md)を参照してください。

関連ドキュメント

アービトレーションサービスに関するその他の操作については、以下の情報を参照してください：

• 2レプリカ + アービトレーションサービスをデプロイするOceanBaseクラスタ

• テナントのアービトレーションサービスを無効にする

• ログストリームの降格制御時間を変更する

• クラスタのアービトレーションサービスを置き換える

• クラスタのアービトレーションサービスを削除する