サービスの作成

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 を照会します。

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

   ステートメントの例：

   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';
   

   テナントロールとクエリ結果を照らし合わせ、作成予定のサービスにおいてプライマリテナントが最大1つであることをご自身で保証してください。

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

関連ドキュメント

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