テナントのクローン操作を使用すると、指定されたテナントに基づいて新しいテナントを作成できます。クローンされた新しいテナントのユニット数および各OBServerノード上のユニットの配置は、ソーステナントと一致します。
制限事項
スイッチオーバー中は、テナントのクローン操作を実行することはできません。
スイッチオーバーに関する操作の詳細については、Switchoverを参照してください。
LSの追加、削除、またはLS属性の変更プロセス中は、テナントクローン操作を実行できません。
システムテナント(
sysテナント)で以下のステートメントSELECT * FROM oceanbase.CDB_OB_BALANCE_JOBS WHERE tenant_id=XXX;を実行することで確認できます。Transferプロセス中は、テナントクローン操作を実行できません。
システムテナント(
sysテナント)で以下のステートメントSELECT * FROM oceanbase.CDB_OB_BALANCE_JOBS WHERE tenant_id=XXX;を実行し、進行中のTransferタスクがあるかどうかを確認できます。Unitの移行プロセス中は、テナントクローン操作を実行できません。
システムテナント(
sysテナント)で以下のステートメントSELECT * FROM oceanbase.DBA_OB_UNITS WHERE MIGRATE_FROM_SVR_PORT IS NOT NULL;を実行し、進行中のUnit移行タスクがあるかどうかを確認できます。リソースプール内の
UNIT_NUM数を減らしてテナントの縮小を行っている間は、テナントクローン操作を実行できません。ソーステナントのUnitが配置されているOBServerノードが使用不可である場合、テナントクローン操作はサポートされません。
ログストリームレプリカに災害復旧タスクが存在する場合、テナントクローン操作を実行できません。
現在のテナントのログストリームレプリカに災害復旧タスクがあるかどうかを確認する方法は以下の通りです。
システムテナント:現在のテナントの
tenant_idを指定してCDB_OB_LS_REPLICA_TASKSビューを照会します。問い合わせ結果が空でない場合は、そのテナントで災害復旧タスクが実行中であることを示します。ユーザーテナント:
DBA_OB_LS_REPLICA_TASKSを照会します。問い合わせ結果が空でない場合は、そのテナントで災害復旧タスクが実行中であることを示します。
アップグレードプロセス中は、テナントクローン操作を実行できません。
OceanBaseデータベースV4.3.0より前のバージョンのテナントに対しては、テナントクローン操作を実行できません。
注意事項
クローンされた新しいテナントとソーステナントの間には、厳密なデータ分離とリソース分離が存在します。新しいテナントのデータ変更はソーステナントに影響を与えず、同様にソーステナントのデータ変更も新しいテナントに影響を与えません。また、新しいテナントとソーステナントの間でCPUやメモリなどのリソースを相互に奪い合うことはありません。
ソーステナントとクローンされた新しいテナントは、初期状態では共有物理マクロブロックを使用します。その後、ソーステナントと新しいテナントのそれぞれのデータ書き込みに伴い、両テナントの共有マクロブロックは徐々に減少し、専用マクロブロックは徐々に増加し、ストレージ容量の占有も段階的に増加します。そのため、OBServerノード上のストレージ容量の占有状況には常に注意が必要です。
テナントクローンタスクの実行中は、以下の操作を行うことはできません:
ソーステナントに対してスイッチオーバー操作を実行する
ソーステナントの
UNIT_NUM数またはプライマリゾーンの第一優先順位を変更して、テナントのスケーリングアップ/ダウン操作を実行するソーステナントに対してレプリカの追加、削減、再配置などの操作を実行する
ソーステナントに対して手動でフォワードスルー操作を実行する
ソーステナントに対して手動でユニット移行操作を実行する
ソーステナントに対してアップグレード操作を実行する
上記の操作を実行しなければならない場合は、クローンタスクをキャンセルしてから再度実行してください。クローンタスクのキャンセルの詳細な操作については、テナントクローンのキャンセルを参照してください。
前提条件
テナントクローン機能はテナントのログアーカイブ機能に依存しています。テナントクローン操作を実行する前に、ソーステナントでログアーカイブモードが有効になっていることを確認する必要があります。また、テナントクローンの過程でソーステナントがログアーカイブモードを無効にすることはできません。ソーステナントにアーカイブ宛先を設定し、ログアーカイブモードを有効にする詳細な操作については、ログアーカイブの準備およびアーカイブモードの有効化を参照してください。
注意
テナントにアーカイブモードを有効にした後、即座にテナントのクローン操作を実行したい場合は、ALTER SYSTEM MINOR FREEZE TENANT = tenant_name;ステートメントを実行して、そのテナントに対してダンプを開始する必要があります。手動でダンプをトリガーする詳細な操作については、手動でダンプをトリガーするを参照してください。
背景
クローンテナント機能は多くのシナリオに適用でき、その一部を以下に示します:
あるオンラインテナントのデータを分析する必要があり、分析ステートメントがオンラインデータのTP負荷に影響を与えることを懸念している場合、そのテナントから新しいテナントをクローンして、新しいテナント上でオンラインデータ分析を実行できます。
自社アプリケーションバージョンを公開する前に、当該アプリケーションに関連する業務テナントを現在時点の小規模なテナントとしてクローンすることができます。新しく公開されたアプリケーションバージョンに問題が発生した場合、迅速にデータロールバックを実行できます。
アプリケーションのバージョンテスト検証を行う必要がある場合、オンラインテナントを基に迅速にテストテナントをクローンし、テストテナントを使用してアプリケーションのテスト検証を行うことができます。
データベースに対してDDLなどの比較的高リスクな操作を実行する必要がある場合、次のように対処できます:
オンラインテナントを基に迅速にテストテナントをクローンし、実行するDDLステートメントをテストテナント上で一度実行して、実行結果を検証します。
DDLステートメントを実行する前に、オンラインテナントを基に現在時点の小規模なテナントをクローンします。DDLステートメントの実行に問題が発見された場合、迅速にデータロールバックを実行できます。
操作手順
rootユーザーでクラスタのsysテナントにログインします。obclient -h172.30.xx.xx -P2883 -uroot@sys#cluster -p**** -A以下のステートメントを実行して、テナントをクローンします。
CREATE TENANT new_tenant_name FROM source_tenant_name WITH RESOURCE_POOL [=] resource_pool_name, UNIT [=] unit_config;関連パラメータの説明は以下のとおりです:
new_tenant_name:クローンされた新しいテナント名。一度に1つのテナントしかクローンできません。複数のテナントをクローンする必要がある場合は、そのクローンタスクが終了してから新しいテナントをクローンする必要があります。source_tenant_name:ソーステナント名。resource_pool_name:クローンされた新しいテナントのリソースプール名を指定します。テナントのクローン時、システムはソーステナントのリソース分布に基づいて、新しいテナント用に自動的にリソースプールを作成します。unit_config:クローンされた新しいテナントのユニット構成を指定します。必要に応じて、システム内に既存のユニット構成を使用することも、新しいユニット構成を作成することもできます。システム内に既存のユニットを照会する詳細な操作については、リソース仕様の確認を参照してください。
テナント
mysqlに基づいて新しいテナントclone_tntをクローンする例は以下のとおりです:obclient [oceanbase]> CREATE TENANT clone_tnt FROM mysql WITH RESOURCE_POOL = clone_tnt_pool, UNIT= S1_unit_config;この例では、クローンされた新しいテナントのリソースプールは
clone_tnt_pool、ユニット構成はS1_unit_configです。クローンされたテナントのユニット数および各OBServerノード上のユニットの配置は、ソーステナントと一致します。クローンタスクの実行中、ビューを使用してクローンタスクの状態を確認できます。
実行中のクローンタスクを確認する
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_CLONE_PROGRESS\Gクエリ結果は次のとおりです:
*************************** 1. row *************************** CLONE_JOB_ID: 1702211800546509768 TRACE_ID: YA4740B7C050F-00060C210F4A4848-0-0 SOURCE_TENANT_ID: 1004 SOURCE_TENANT_NAME: mysql CLONE_TENANT_ID: 1016 CLONE_TENANT_NAME: clone_tnt TENANT_SNAPSHOT_ID: 1702211800802135214 TENANT_SNAPSHOT_NAME: _inner_snapshot$1702211800702058206 RESOURCE_POOL_ID: 1008 RESOURCE_POOL_NAME: clone_tnt_pool UNIT_CONFIG_NAME: S1_unit_config RESTORE_SCN: 1702211802014048020 STATUS: CLONE_SYS_CREATE_TENANT CLONE_JOB_TYPE: FORK CLONE_START_TIME: 2023-12-10 20:36:40.551169 CLONE_FINISHED_TIME: NULL RET_CODE: NULL ERROR_MESSAGE: NULL 1 row in setクローンタスク履歴を確認する
obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_CLONE_HISTORY\Gクエリ結果は次のとおりです:
*************************** 1. row *************************** CLONE_JOB_ID: 1702211800546509768 TRACE_ID: YA4740B7C050F-00060C210F4A4848-0-0 SOURCE_TENANT_ID: 1004 SOURCE_TENANT_NAME: mysql CLONE_TENANT_ID: 1016 CLONE_TENANT_NAME: clone_tnt TENANT_SNAPSHOT_ID: 1702211800802135214 TENANT_SNAPSHOT_NAME: _inner_snapshot$1702211800702058206 RESOURCE_POOL_ID: 1008 RESOURCE_POOL_NAME: clone_tnt_pool UNIT_CONFIG_NAME: S1_unit_config RESTORE_SCN: 1702211802014048020 STATUS: CLONE_SYS_SUCCESS CLONE_JOB_TYPE: FORK CLONE_START_TIME: 2023-12-10 20:36:40.551169 CLONE_FINISHED_TIME: 2023-12-10 20:37:53.919247 RET_CODE: 0 ERROR_MESSAGE: NULL 1 row in set
次のステップ
テナントクローンタスクの実行が完了すると、クローンされた新しいテナントはスタンバイテナントになります。ユーザーはこの新しいテナントを引き続きスタンバイテナントとして関連サービスを提供することも、新しいテナントをメインテナントに切り替えてサービスを提供することもできます。スタンバイテナントをメインテナントに切り替える詳細な操作については、スタンバイテナントをメインテナントに切り替えるを参照してください。
アービトレーションサービスがデプロイされているシナリオでは、デフォルトではクローンされたテナントにアービトレーションサービスは有効になっていません。アービトレーションサービスを有効にする必要がある場合は、クローン後に新しいテナントにアービトレーションサービスを有効にすることができます。詳細な操作については、テナントにアービトレーションサービスを有効にするを参照してください。