サービスの作成

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

背景

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

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

制限事項

• sys テナントまたは Meta テナントにはサービスの作成をサポートしていません。

• 一つのユーザーテナントは最大で一つのサービスしか作成できません。

• サービス名で確立されたセッション内で CREATE SERVICE コマンドを実行することは許可されていません。

• この機能の使用は OCP や ODP などの製品に依存します。関連製品のバージョン要件は以下のとおりです：

  • ODP：V4.3.1 以降のバージョン

  • OCP：V4.3.1 以降のバージョン

注意事項

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

前提条件

• CREATE SERVICE コマンドを実行するには、ユーザーに ALTER SYSTEM 権限が付与されている必要があります。

• テナントのサービスを作成する際には、まずテナントのUnit内に一時的にオフラインとなっているマシンがないか確認する必要があります。一時的にオフラインとなっているマシンがある場合、CREATE SERVICE コマンドを実行した後、そのサービス名でサービスを提供できないマシンが一時的に発生する可能性があります。そのため、一時的にオフラインとなったマシンが復旧するか、完全にオフラインになってから CREATE SERVICE コマンドを再実行することを推奨します。または、ユーザーはまず CREATE SERVICE コマンドを実行し、一時的にオフラインとなったマシンが復旧または完全にオフラインになった後、START SERVICE コマンドを実行してサービスを起動することもできます。

  テナントのUnit内に一時的にオフラインとなっているマシンがないか確認する手順は以下の通りです：

  1. root ユーザーで、現在のテナントが存在するクラスタの 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 に置き換える必要があります。

     クエリ結果が空の場合、一時的にオフラインとなっているマシンはないことを意味します。クエリ結果が空ではない場合、マシンが一時的にオフラインとなっているかどうかをさらに判断する必要があります。

  3. テナントのUnit内にオフラインとなっているマシンがあることが確認された場合、パラメータ 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;
    

手順

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

1. テナント管理者がクラスタのユーザーテナントまたはsysテナントにログインします。

2. 指定したテナントのTENANT_ROLEを確認します。

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

   ステートメントの例：

   obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_ROLE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = mysql_tenant;
   

3. 作成予定のサービス下のテナント状況を確認します。

   注意

   以下のステートメントは、現在のクラスタ内で指定されたサービス名を持つすべてのプライマリ/スタンバイテナントの名前とそのテナント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';
   

   テナントのロールと照会結果を組み合わせて、作成予定のサービス下にプライマリテナントが最大一つしか存在しないことをご自身で保証してください。

4. テナントにサービスを作成します。

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

   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モード）を参照してください。

関連ドキュメント

• サービス状態の確認
• サービスの起動
• サービスの一時停止
• サービスの削除