テナントのスムーズな拡張・縮小をさらに実現するため、OceanBaseデータベースはプリスケーリング機能を実装しています。この機能は、テナントの縮小から拡大に必要な拡大係数(ls_scale_out_factor)を設定し、事前に十分な数のログストリームを生成して、ログストリームの状態と位置が拡大後と一致するようにした上で、テナントの拡大または縮小操作を開始することで、スムーズな拡張・縮小を実現します。
背景
現在のバージョンでは、OceanBaseデータベースはテナントの同種ゾーンモードと異種ゾーンモードをサポートしています:
同種ゾーンモードでは、テナント内の各ゾーンの
UNIT_NUMが同じである必要があります。異種ゾーンモードでは、テナント内の各ゾーンの
UNIT_NUMは同じでも異なってもかまいませんが、一つのテナントの全ゾーンでUNIT_NUMの種類は最大2種類までとなります。
本記事では主に同種ゾーンモードのテナントを例に、テナントのプリスケーリング操作の手順を説明します。異種ゾーンモードのテナントについては、異種ゾーンの運用方法を利用してスムーズな拡張・縮小を実現することを推奨します。異種ゾーンを利用したスムーズな拡張・縮小のユースケースについては、スムーズな拡張・縮小のアプリケーションケースを参照してください。
拡大係数の紹介
以前のバージョンでは、一つのテナントが一つのノード上でサービスを提供するログストリームは一つだけでした。ノード内に十分な数のログストリームが存在すれば、拡大時に直接ログストリームの位置再配分をトリガーでき、Transferを通じてログストリームを分割する必要はありませんでした。
拡大前に十分な数のログストリームが存在することを定義するため、OceanBaseデータベースは拡大係数(ls_scale_out_factor)という概念を導入しました。拡大係数とは、後続の拡大要件を満たすために、一つのログストリームが分割する必要があるログストリームの数を定義します。
拡大係数の計算式
OceanBaseデータベースでは、テナントの通常のログストリーム数(システムログストリームとブロードキャストログストリームを除く)は次のとおりです:テナントのUNIT_NUMの数(U) × テナントのPRIAMRY_ZONE第一優先順位の数(P)。
拡大前のテナントのUNIT_NUMの数をU1、PRIAMRY_ZONE第一優先順位の数をP1、拡大後のテナントのUNIT_NUMの数をU2、PRIAMRY_ZONE第一優先順位の数をP2と仮定します。このとき、拡大係数(ls_scale_out_factor)の計算式は以下のとおりです:
ls_scale_out_factor = LCM(U1 * p1 , U2 * P2 ) / (U1 * P1)
つまり、(U1 * p1)と(U2 * P2)の二つの値の最小公倍数を(U1 * P1)で割ることで、そのテナントの拡大係数を求めることができます。
プリスケーリング
現在、テナントmq_t1があり、そのローカリティがF@zone1, F@zone2, F@zone3で、各ゾーンに1つのUnitがあり、PRIMARY_ZONEがzone1とzone2に分散していると仮定します。今後、テナントのUNIT_NUMを2に調整し、テナントのPRIMARY_ZONE第一優先順位の数を変更しないことを希望します。この場合、当該テナントに対するプリスケーリングの操作は以下のとおりです。
rootユーザーでクラスタのsysテナントにログインします。接続例:
obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -Aテナント
mq_t1のTENANT_ID、UNIT_NUM、PRIAMRY_ZONEなどの情報を確認します。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, UNIT_NUM FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME = 'mq_t1';クエリ結果は次のとおりです:
+-----------+-------------+-------------+-------------------+---------------------------------------------+----------+ | TENANT_ID | TENANT_NAME | TENANT_TYPE | PRIMARY_ZONE | LOCALITY | UNIT_NUM | +-----------+-------------+-------------+-------------------+---------------------------------------------+----------+ | 1002 | mq_t1 | USER | zone1,zone2;zone3 | FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3 | 1 | +-----------+-------------+-------------+-------------------+---------------------------------------------+----------+ 1 row in setスケールアウト係数
ls_scale_out_factorの値を計算し、テナントのスケールアウト係数を設定します。この例では、テナント
mq_t1のスケールアウト前のUNIT_NUMは1、PRIAMRY_ZONEの優先順位1の数は2です。スケールアウト後、テナントのUNIT_NUMは2、PRIMARY_ZONEの優先順位1の数は変わらず2のままです。スケールアウト係数の計算式によると、その値はLCM(2 * 1 , 2 * 2)/(2 * 1) = 2となります。計算したスケールアウト係数に基づき、パラメータ ls_scale_out_factor の値を設定します。
obclient(root@sys)[oceanbase]> ALTER SYSTEM SET ls_scale_out_factor = 2 TENANT = mq_t1;テナントレベルのパラメータ enable_rebalance と enable_transfer の値をどちらも有効(
True)に設定します。これにより、テナント内で十分な数のログストリームが生成されるようにします。obclient(root@sys)[oceanbase]> ALTER SYSTEM SET enable_rebalance = True TENANT = mq_t1;obclient(root@sys)[oceanbase]> ALTER SYSTEM SET enable_transfer = True TENANT = mq_t1;テナントが十分な数のログストリームを生成するのを待った後、現在のテナント内の
NORMAL状態のログストリームの数が期待通りかどうかを確認します。スケールアウト係数の公式によると、スケールアウト後の現在のテナント内の
NORMAL状態(システムログストリームとブロードキャストログストリームを除く)のログストリームの数は、スケールアウト前のテナントのUNIT_NUM数(U1)× スケールアウト前のテナントのPRIAMRY_ZONE優先順位1の数(P1)× スケールアウト係数(ls_scale_out_factor)となります。つまり、現在のテナント内のログストリームの数は1 * 2 * 2 = 4となるはずです。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, STATUS, COUNT(*) FROM oceanbase.CDB_OB_LS WHERE TENANT_ID = 1002 AND FLAG = '' AND LS_ID != 1 GROUP BY STATUS;クエリ結果の例は次のとおりです:
+-----------+--------+----------+ | TENANT_ID | STATUS | COUNT(*) | +-----------+--------+----------+ | 1002 | NORMAL | 4 | +-----------+--------+----------+ 1 row in setスケールアウト対象のテナントに負荷分散タスクがないことを確認します。
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.CDB_OB_BALANCE_JOBS WHERE TENANT_ID = 1002;クエリ結果が空の場合、今回のプレスケールアウト操作は完了です。
次のステップ
プレスケールアウト操作が完了したら、ビジネスニーズに応じて、想定されたスケールアウト計画に従ってスケールアウトまたはスケールイン操作を実行できます。