サービスの作成|V4.3.5|OceanBaseデータベース|OceanBaseデータベースドキュメント|分散データベース

サービスの作成

最終更新日：2026-04-09 02:53:56 更新

OceanBaseデータベースは、OCPまたはコマンドラインを使用してCREATE SERVICEコマンドを実行し、ユーザーテナント用のサービスを作成できます。この記事では主にコマンドラインを使用したサービスの作成方法について説明します。サービスの作成と管理には、OCPの使用を推奨します。OCPを使用したサービスの作成方法の詳細については、テナント詳細ページの概要およびサービス名の管理を参照してください。

背景

OceanBaseデータベースV2.xまたはV3.xバージョンでは、フィジカル・スタンバイ・データベースのプロダクト形態はクラスタレベルのプライマリ/スタンバイであり、相互にプライマリ/スタンバイ関係にあるクラスタのクラスタ名および対応するテナント名はすべて同一でした。また、異なるプライマリ/スタンバイデータベースクラスタ間では、クラスタ名も異なるため、クラスタ名をプライマリ/スタンバイクラスタの一意の識別子とすることができました。ユーザーはODPを使用してデータベースに接続する際、指定されたクラスタ名を使用して接続を自動的にプライマリクラスタにルーティングすることができました。

V4.1.0バージョン以降では、フィジカル・スタンバイ・データベースのプロダクト形態がテナントレベルのプライマリ/スタンバイに変更されました。プライマリ/スタンバイテナントが属するクラスタは必ずしも同一ではなく、プライマリ/スタンバイテナント間には相互認識がなく、つまりプライマリテナントはスタンバイテナントの情報を記録せず、スタンバイテナントもプライマリテナントの情報を記録しません。テナントレベルのプライマリ/スタンバイの自動ルーティングを実現するため、OceanBaseデータベースはサービスという概念を導入しました。1つのサービス内には、同一クラスタまたはクラスタ間の複数のテナントを含むことができます。ユーザーはODPを使用してデータベースに接続する際、指定されたサービス名を使用して接続を自動的にプライマリテナントにルーティングすることができます。

制限事項

sys テナントまたはMetaテナントにサービスを作成することはサポートされていません。
1人のユーザーテナントは最大で1つのサービスしか作成できません。
サービス名によって確立されたセッション内で CREATE SERVICE コマンドを実行することは許可されていません。
この機能の使用は、OCPやODPなどのプロダクトに依存します。関連プロダクトのバージョン要件は以下のとおりです：
- ODP：V4.3.1以降のバージョン
- OCP：V4.3.1以降のバージョン

注意事項

テナントにサービスを作成する際、1つのサービス内には最大でも1つのプライマリテナントしか存在しないようにする必要があります。プライマリ/スタンバイ関係の維持およびサービス管理には、OCPを使用することを推奨します。OCPを使用したプライマリ/スタンバイテナント管理の詳細および操作については、OCP公式ドキュメントを参照してください。

前提条件

CREATE SERVICE コマンドを実行するには、ユーザーに ALTER SYSTEM 権限が付与されている必要があります。
テナント用のサービスを作成する際には、まずテナントのユニット内に一時的にオフライン状態のマシンが存在しないか確認する必要があります。もし一時的にオフライン状態のマシンがある場合、CREATE SERVICE コマンドを実行した後、一部のマシンがそのサービス名を介してサービスを提供できなくなる可能性があります。そのため、一時的にオフライン状態のマシンが復旧するか、または永続的にオフライン状態になってから CREATE SERVICE コマンドを実行することを推奨します。または、ユーザーはまず CREATE SERVICE コマンドを実行し、一時的にオフライン状態のマシンが復旧するか、または永続的にオフライン状態になってから START SERVICE コマンドを実行してサービスを起動することもできます。

テナントのユニット内に一時的にオフライン状態のマシンが存在するかどうかを確認する詳細な手順は以下のとおりです：
1. root ユーザーで現在のテナントが属するクラスタの 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 に置き換える必要があります。
  
  クエリ結果が空の場合、一時的にオフライン状態のマシンは存在しません。クエリ結果が空でない場合、マシンが一時的にオフライン状態になっているかどうかをさらに判断する必要があります。
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() 以下であれば、マシンはすでに永続的にオフライン状態であることを意味し、そうでなければマシンは一時的にオフライン状態です。
テナント用のサービスを作成する際には、テナントの SWITCHOVER_STATUS が NORMAL であることが求められます。これは、テナントがプライマリ/スタンバイロール切り替えの中間状態にないことを保証するためです。

テナントの TENANT_ROLE と SWITCHOVER_STATUS を照会する方法は以下のとおりです：
- システムテナントから指定されたテナントの TENANT_ROLE および SWITCHOVER_STATUS を照会します。
```
obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = mysql_tenant;
```
- ユーザーテナントから自身の TENANT_ROLE および SWITCHOVER_STATUS を照会します。
```
obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
```
```
obclient [SYS]> SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
```

操作手順

テナントにサービスを作成する際、プライマリとスタンバイの関係にあるテナントでは、プライマリテナントとスタンバイテナントにそれぞれ同名のサービスを作成する必要があります。

テナント管理者は、クラスタのユーザーテナントまたはsysテナントにログインします。
指定されたテナントのTENANT_ROLEを照会します。

一つのサービスには最大で一つのプライマリテナントしか存在しないため、サービスを作成する前に、現在のテナントのロールを確認する必要があります。

ステートメントの例は以下のとおりです：
```
obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = mysql_tenant;
```
作成予定のサービスの下にあるテナントの状況を照会します。

注意

以下のステートメントは、現在のクラスタ内で指定されたサービス名を持つすべてのプライマリおよびスタンバイテナントの名前とそのテナントIDのみを照会できます。クラスタ間の物理スタンバイ構成の場合は、対応するクラスタも照会する必要があります。

ステートメントの例は以下のとおりです：
```
obclient [oceanbase]> SELECT t.tenant_id, t.tenant_name, t.tenant_role
FROM oceanbase.CDB_OB_SERVICES AS s JOIN oceanbase.DBA_OB_TENANTS AS t
ON s.tenant_id = t.tenant_id
WHERE s.service_name = 's_hz';
```
テナントのロールと照会結果を組み合わせて、作成予定のサービスにプライマリテナントが最大で一つしか存在しないことをご自身で保証してください。
テナントにサービスを作成します。

ステートメントは以下のとおりです：
```
ALTER SYSTEM CREATE SERVICE service_name [TENANT [=] tenant_name];
```
ステートメント内：
- service_name：作成予定のサービス名を指定します。
- TENANT [=] tenant_name：作成予定のサービスのテナント名を指定します。テナントを指定できるのはsysテナントのみであり、ユーザーテナントはテナントを指定できません。
例：
- システムテナントがテナントmysql_tenantにs_hzという名前のサービスを作成します。
```
obclient [oceanbase]> ALTER SYSTEM CREATE SERVICE s_hz TENANT = mysql_tenant;
```
- ユーザーテナントが自テナントにs_hzという名前のサービスを作成します。
```
obclient > ALTER SYSTEM CREATE SERVICE s_hz;
```
コマンド実行後、Query OKが返された場合、テナントのUnit内で永続的にオフラインのマシンを除くすべてのマシンが、指定されたサービス名を使用して接続を確立できることを意味します。OB_SERVICE_NOT_FULLY_STARTEDが返された場合、テナントのUnit内で永続的にオフラインのマシンを除く他のマシンのうち、一部のマシンのみが指定されたサービス名を使用して接続を確立できることを意味します。具体的にどのマシンがサービス名を指定してデータベースに接続できるかを確認するには、システムテナントのCDB_OB_TENANT_EVENT_HISTORYビュー、またはユーザーテナントのDBA_OB_TENANT_EVENT_HISTORY(MySQLモード)およびDBA_OB_TENANT_EVENT_HISTORY(Oracleモード)ビューを参照してください。

次のステップ

プライマリおよびスタンバイテナントの同名サービスがすべて正常に作成され、かつプライマリおよびスタンバイテナントが属するクラスタがOCPによって管理され、さらに両テナントのクラスタが同一のODP（OBProxy）クラスタに関連付けられた後、ユーザーはサービス名を指定することでデータベースに接続し、プライマリとスタンバイテナント間の自動ルーティングを実現できます。接続文字列は以下のとおりです：

obclient -hip -Pport -uuser_name@SERVICE:service_name

その中で：

ip：ODPのIPアドレス。
port：ODPのポート番号。
user_name：ログイン対象のテナントのユーザー名。
service_name：ログイン対象のテナントのサービス名。

接続例は以下のとおりです：

obclient -h10.xx.xx.xx -P2883 -uuser1@SERVICE:s_hz

その他の接続方法の詳細については、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。

顧客事例