適用対象
この内容はOceanBaseデータベースEnterprise Editionにのみ適用されます。OceanBaseデータベースCommunity Editionは、現在アービトレーションサービス機能をサポートしていません。
テナント作成時にアービトレーションサービスを有効にすることも可能です。テナント作成およびアービトレーションサービスの有効化に関する操作については、テナントの作成を参照してください。アービトレーションサービスが有効になっていない場合でも、テナント作成後にアービトレーションサービスを有効にすることができます。この記事では、既存のテナントにアービトレーションサービスを有効にする方法について説明します。
前提条件
現在のクラスタにアービトレーションサービスがデプロイされていることを確認してください。アービトレーションサービスの詳細な操作については、2レプリカ+アービトレーションサービスのOceanBaseクラスタのデプロイを参照してください。
アービトレーションサービスを有効にする前に、アービトレーションサービスを有効にするテナントのローカリティが2Fまたは4Fであることを確認する必要があります。現在、ローカリティが2Fまたは4Fのテナントのみがアービトレーションサービスを有効にできます。
説明
アービトレーションサービスを有効にするには、テナントのローカリティ内のFレプリカ数に要件がありますが、Rレプリカ数に制限はありません。例えば、テナントのローカリティが
F@z1,F@z2またはF@z1,F@z2,R@z3の場合でも、アービトレーションサービスを有効にできます。
操作手順
rootユーザーでクラスタのsysテナントにログインします。接続例は以下のとおりです。データベースへの接続時は、実際の環境に基づいてください。
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -Aデータベースへの接続方法の詳細については、データベース接続の概要(MySQLモード)およびデータベース接続の概要(Oracleモード)を参照してください。
以下のコマンドを実行して、クラスタ内の各ノードの接続状態を確認します。
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：アービトレーションサービスがそのノードと通信できないことを示します。テナントでアービトレーションサービスを有効にすることはできません。ノードとアービトレーションサービス間のネットワーク通信状況を調査する必要があります。
以下のコマンドを実行して、テナントのアービトレーションサービスの状態を確認します。
SELECT * FROM oceanbase.DBA_OB_TENANTS WHERE tenant_name = 'oracle001'\Gクエリ結果は次のとおりです。
*************************** 1. row *************************** TENANT_ID: 1004 TENANT_NAME: oracle001 TENANT_TYPE: USER CREATE_TIME: 2023-06-26 19:40:21.457857 MODIFY_TIME: 2023-06-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 COMPATIBLE: 4.2.0.0 1 row in setテナントのアービトレーションサービスには、主に以下のような状態があります：
ENABLED：テナントでアービトレーションサービスが有効になっていることを示します。DISABLED：テナントでアービトレーションサービスが無効になっていることを示します。ENABLING：テナントでアービトレーションサービスが有効になっていることを示します。DISABLING：テナントでアービトレーションサービスが無効になっていることを示します。
クエリ結果によると、
ARBITRATION_SERVICE_STATUS列がDISABLEDであるため、このテナントではアービトレーションサービスが無効になっています。DBA_OB_TENANTSビューの詳細については、DBA_OB_TENANTSを参照してください。以下のコマンドを実行して、テナントでアービトレーションサービスを有効にします。
ステートメントは次のとおりです：
ALTER TENANT tenant_name [SET] ENABLE_ARBITRATION_SERVICE = true;ここで、
tenant_nameはアービトレーションサービスを有効にするテナント名です。SETキーワードはオプションです。テナント
oracle001でアービトレーションサービスを有効にする例は次のとおりです：ALTER TENANT oracle001 ENABLE_ARBITRATION_SERVICE = true;コマンドの実行が成功した後、再度
DBA_OB_TENANTSビューを照会して、テナントのアービトレーションサービスが有効になっているかどうかを確認します。SELECT * FROM oceanbase.DBA_OB_TENANTS WHERE tenant_name = 'oracle001'\Gクエリ結果は次のとおりです。
*************************** 1. row *************************** TENANT_ID: 1004 TENANT_NAME: oracle001 TENANT_TYPE: USER CREATE_TIME: 2023-06-26 19:40:21.457857 MODIFY_TIME: 2023-06-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 COMPATIBLE: 4.2.0.0 1 row in setクエリ結果によると、
ARBITRATION_SERVICE_STATUS列がENABLEDであるため、このテナントではアービトレーションサービスが有効になっています。アービトレーションサービスを正常に有効にした後でも、テナントにはアービトレーションメンバーが不足しているログストリームが存在する可能性があります。このようなログストリームでは、通常の昇格・降格操作を実行できません。次の手順で確認できます。
テナントのアービトレーションサービスが正常に有効になったことは、有効化時点で作成されたすべてのログストリームがアービトレーションサービスを使用できることを意味します。しかし、アービトレーションサービスを有効にした後に新しく作成されたログストリームには、アービトレーションメンバーが不足している可能性があります。これは、ログストリームの作成が非厳密モードで実行されるため、アービトレーションメンバーが必ず作成されるとは限らないためです。このような場合、次のステートメントを使用して、そのテナントのすべてのログストリームにアービトレーションメンバーが存在するかどうかを確認できます。
ステートメントは次のとおりです：
(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です。
例は次のとおりです：
(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を参照してください。
関連ドキュメント
アービトレーションサービスに関するその他の操作については、以下を参照してください：