テナントのクローン操作により、指定したテナントを基に新しいテナントを作成できます。クローンされた新しいテナントのユニット数および各OBServerノード上のユニットの配置は、ソーステナントと完全に一致します。
使用制限
スイッチオーバー中は、テナントのクローン操作を実行することはできません。
スイッチオーバーに関する操作の詳細については、Switchoverを参照してください。
LSの追加、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数を減らしてテナントをスケールインする際は、テナントのクローン操作を実行することはできません。ソーステナント内のユニットが配置されているOBServerノードが利用不可な場合、テナントのクローン操作を実行することはサポートされません。
ログストリームレプリカにディザスタリカバリタスクが存在する場合は、テナントのクローン操作を実行することはできません。
現在のテナントのログストリームレプリカにディザスタリカバリタスクがあるかどうかを確認する方法は以下の通りです：
システムテナントは、現在のテナントの
tenant_idを指定してCDB_OB_LS_REPLICA_TASKSビューをクエリします。クエリ結果がNULLではない場合、そのテナントでディザスタリカバリタスクが実行中であることを意味します。ユーザーテナントは
DBA_OB_LS_REPLICA_TASKSをクエリします。クエリ結果がNULLではない場合、そのテナントでディザスタリカバリタスクが実行中であることを意味します。
アップグレード中は、テナントのクローン操作を実行することはできません。
OceanBaseデータベースV4.3.0以前のバージョンのテナントに対して、テナントのクローン操作を実行することはできません。
注意事項
クローンされた新しいテナントとソーステナントの間には、厳密なデータ分離とリソース分離があります。新しいテナントで行われるすべてのデータ変更はソーステナントに影響を与えず、同様にソーステナントで行われるすべてのデータ変更も新しいテナントに影響を与えません。新しいテナントとソーステナントは、CPUやメモリなどのリソースを互いに競合することはありません。
ソーステナントとクローンされた新しいテナントは、初期状態では共有物理マクロブロックを使用します。その後、ソーステナントと新しいテナントそれぞれでデータが書き込まれるにつれて、両テナントの共有マクロブロックは徐々に減少し、専用マクロブロックが徐々に増加します。これに伴い、ストレージ容量の使用量も段階的に増加するため、OBServerノード上のストレージ容量使用状況を適時確認する必要があります。
テナントのクローンタスクの実行中は、以下の操作を行うことはできません：
ソーステナントに対するスイッチオーバー操作の実行
ソーステナントの
UNIT_NUM数やプライマリゾーンの第一優先順位を変更することによるテナントのスケーリング操作の実行ソーステナントに対するレプリカの追加、削除、配置調整などの操作の実行
ソーステナントに対する手動Transfer操作の実行
ソーステナントに対する手動Unit移行操作の実行
ソーステナントに対するアップグレード操作の実行
上記の操作を実行する必要がある場合は、クローンタスクをキャンセルしてから実行できます。クローンタスクのキャンセル操作の詳細については、テナントクローンのキャンセルを参照してください。
前提条件
テナントのクローン機能は、テナントのログアーカイブ機能に依存しています。テナントのクローン操作を実行する前に、ソーステナントでログアーカイブモードが有効になっていることを確認し、テナントのクローン処理中はソーステナントのログアーカイブモードを無効にできないようにしてください。ソーステナントにアーカイブ先を設定し、ログアーカイブモードを有効にする詳細な操作については、ログアーカイブの準備およびアーカイブモードの有効化を参照してください。
注意
テナントのアーカイブモードを有効にした後、すぐにクローンテナント操作を実行したい場合は、ALTER SYSTEM MINOR FREEZE TENANT = tenant_name; ステートメントを実行して、そのテナントに対してダンプを発生させる必要があります。手動でダンプをトリガーする詳細な操作については、手動でダンプをトリガーするを参照してください。
背景
テナントのクローン機能は、多くのシナリオで利用できます。主なシナリオは以下の通りです：
アプリケーションのバージョンテストと検証を行う際、オンラインテナントを基に迅速にテストテナントをクローンし、そのテストテナントでアプリケーションのテストと検証を行えます。
データベースに対して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：クローンされる新しいテナントのUnit構成を指定します。必要に応じて、システム内に既存のUnit構成を使用するか、新しいUnit構成を作成することができます。システム内の既存Unitの詳細な操作については、リソース構成の確認を参照してください。
テナント
mysqlから新しいテナントclone_tntをクローンする例を以下に示します：obclient [oceanbase]> CREATE TENANT clone_tnt FROM mysql WITH RESOURCE_POOL = clone_tnt_pool, UNIT= S1_unit_config;この例では、クローンされた新しいテナントのリソースプールは
clone_tnt_pool、Unit構成はS1_unit_configです。クローンされたテナントのUnit数及び各OBServerノード上のUnitの配置は、ソーステナントと同一です。クローンタスクの実行中、ビューを通じてクローンタスクの状態を確認できます。
実行中のクローンタスクの確認
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
次のステップ
テナントクローンタスクの実行が完了すると、クローンされた新しいテナントはスタンバイテナントになります。ユーザーはこの新しいテナントを引き続きスタンバイテナントとして関連サービスを提供することも、新しいテナントをプライマリテナントに切り替えてサービスを提供することもできます。スタンバイテナントをプライマリテナントに切り替える詳細な操作については、スタンバイテナントをプライマリテナントに切り替えるを参照してください。
アービトレーションサービスがデプロイされているシナリオでは、デフォルトでクローンされたテナントのアービトレーションサービスは有効になっていません。アービトレーションサービスを有効にする必要がある場合は、クローン後に新しいテナントのアービトレーションサービスを有効にできます。詳細な操作については、テナントのアービトレーションサービスを有効にするを参照してください。