Zero Downtime Migration
Zero Downtime Migration は、既存データをコピーして増分変更をターゲットクラスターに同期している間も、ソースクラスターを利用可能な状態に保ちます。移行を完了するには、アプリケーションを切り替える前にソースサービスの停止とソースへの書き込みの停止が必要です。この移行は、次の各ステージで構成されます:
-
初期化: ソースデータベースと移行するコレクションを選択し、既存のターゲットクラスター内のデータベースを選択します。
-
移行: 既存データを移行し、増分データを同期します。
-
完了処理: ソースクラスターへのサービスと書き込みを停止し、同期ラグが 10 秒未満になったらデータ同期を停止します。移行の完了後、移行したコレクションを手動でロードし、アプリケーションをターゲットクラスターに切り替えます。
Zero Downtime Migration は Private Preview で提供されています。アクセスをリクエストするには、Zilliz Cloud サポート にお問い合わせください。ソースクラスターとターゲットクラスターでサポートされる Milvus のバージョン要件は ≥ 2.6.21 または ≥ 3.0.0 です。ターゲットクラスターのバージョンは、ソースクラスターのバージョンより低くしないでください。
移行機能
クラスターの互換性
次の表に、クラスター間で可能な移行と制約の概要を示します:
| ソースクラスター | ターゲットクラスター | 移行範囲 |
|---|---|---|
| Dedicated | Dedicated クラスター | ソースデータベースを選択し、すべてのコレクションまたは選択したコレクションを、既存のターゲット Dedicated クラスター内のデータベースに移行します。 |
| Serverless / Free | Dedicated クラスター | Serverless/Free クラスターにはデータベースが最大 1 つしか含まれないため、ソースクラスターから単一のデータベースを移行します。 |
移行範囲オプション
| 移行タイプ | 説明 | ユースケース |
|---|---|---|
| 同じプロジェクト内 | 同じ Zilliz Cloud プロジェクト内の既存クラスター間で移行します | クラスターのアップグレード、パフォーマンスの最適化、データの統合 |
| 同じ組織内のクロスプロジェクト | 同じ Zilliz Cloud 組織内の異なるプロジェクトにある既存クラスター間で移行します。組織間の移行は現在サポートされていません。 | 組織内のプロジェクト間でデータを移動します |
ダイレクトデータ転送
Zero Downtime Migration は、次の特性を持つ Zilliz Cloud クラスター間の直接データレプリケーションを実行します:
-
スキーマの保持: ソーススキーマを変更せずにターゲットクラスターへ転送
-
フィールド変換なし: 移行では、フィールド名の変更、データ型の変更、フィールド属性の変更は行いません。増分同期中に選択したコレクションのスキーマを変更しないでください。これらの変更はレプリケートされません。
-
自動インデックス作成: ターゲットクラスターのベクトルフィールド用に AUTOINDEX が自動的に作成されます
制限
-
増分同期中は、選択したソースコレクションに対する Delete、Insert、Upsert 操作のみがレプリケートされます。スキーマ変更や一括インポートなど、これらのコレクションに対するその他の変更はレプリケートされず、データの不整合を引き起こす可能性があるため、避けてください。
-
移行中のターゲットコレクションへの直接書き込みは、データの不整合を引き起こす可能性があるため、避けてください。
-
移行が完了するまでソースクラスターを保持してください。移行の進行中に削除すると、移行エラーが発生します。
-
AutoID が有効なソースコレクションでは、移行前に Allow Insert AutoID を有効にします。有効にしない場合、移行はディスパッチされません。
-
移行後のターゲットコレクションで
count(*)を実行した結果は、ネットワークの不安定さによる再試行のため、ソースコレクションの結果と異なる場合があります。
事前準備
Zero Downtime Migration を開始する前に、次の要件を満たしていることを確認してください:
一般要件
| 要件 | 詳細 |
|---|---|
| ユーザー権限 | ソースクラスターに対する SERVING_CLUSTER_DATA_READ、ターゲットクラスターに対する SERVING_CLUSTER_DATA_WRITE、および関連プロジェクトに対する OBSERVABILITY_MANAGE が必要です。権限設定を簡素化するには、Project Admin ロールを使用します。 |
| ソースクラスターへのアクセス | ソースクラスターへのパブリックインターネットアクセスを有効にする必要はありません。移行ではプライベートネットワーク接続が使用されます。 |
| ターゲットクラスターの容量 | ターゲットクラスターに、ソースデータを収容するための十分な CU 容量があることを確認します（CU 計算ツール を使用してください）。移行中に容量が不足した場合は、容量を増やし、移行の継続について支援を受けるために Zilliz Cloud サポート にお問い合わせください。 |
認証と AutoID の要件
コンソールでソースクラスターとターゲットクラスターを選択します。アクセスは現在の権限に基づいて確認されます。移行のためにソースのエンドポイント、API キー、またはクラスターのユーザー名とパスワードを入力する必要はありません。ソースとターゲットは同じ組織に属している必要があります。
AutoID が有効なコレクションでは、増分移行の前に allow_insert_auto_id を有効にする必要があります。
はじめに
Zero Downtime Migration のプロセスは、注意して操作する必要がある 3 つの主要フェーズで構成されます:
フェーズ 1: 初期化
ターゲットクラスターを含む組織とプロジェクトから開始します。次のデモでは、ソースデータとターゲットの場所を選択し、移行を開始する方法を示します:
-
ターゲットプロジェクトで、左側のナビゲーションから Migrations を選択します。Zilliz to Zilliz Migration で、Zero Downtime をクリックします。
-
Select Source Location をクリックし、ソースの Organization、Project、Cluster、データベース を選択します。ソースとターゲットは同じ組織に属している必要があります。
-
移行するコレクションを選択します。All コレクション を選択したままにすると、選択したデータベース内のすべてのコレクションが移行されます。個々のコレクションを選択することもできます。
-
Select Target Location をクリックし、ターゲットクラスターとデータベースを選択します。ターゲットの組織とプロジェクトは Current Location に設定されます。
-
ソースとターゲットの場所、および Selected Collections リストを確認してから、Migrate をクリックします。
移行中、ソースクラスターは Running 状態のままになり、ターゲットクラスターには Migrating と表示されます。移行が完了するまでソースクラスターを保持してください。移行中に削除すると、移行エラーが発生します。
フェーズ 2: 監視
ターゲットクラスターの詳細ページで、移行バナーにある View Progress をクリックし、Migration Progress ダイアログを開きます。このダイアログを使用して既存データの移行と増分データの同期を監視し、アプリケーションを切り替える準備ができたらデータ同期を停止します。
Jobs からジョブを監視することもできます。移行ジョブのアクションメニューを開き、View Details を選択して Data タブを選択すると、Rows Written、Sync Delay、Data Synced Through、Metrics Updated、およびソースからターゲットへのコレクションマッピングを表示できます。
ステージ 1: 既存データの移行
Migrate Existing Data ステージでは、選択したソースコレクションの既存データをターゲットデータベースにコピーします。所要時間は転送するデータ量によって異なり、大規模なデータセットの場合は数時間かかることがあります。
処理に時間がかかっている場合は、このページを離れて他のタスクを進めてかまいません。いつでも戻って、増分データの同期の進行状況の監視を続行できます。
ステージ 2: 増分データの同期
Sync incremental data の実行中、システムは選択したソースコレクションに対する Delete、Insert、Upsert 操作をターゲットクラスターに継続的にレプリケートします。ターゲットクラスターは Migrating 状態のままです。データの不整合を避けるため、選択したソースコレクションにその他の変更を加えたり、移行中のターゲットコレクションに直接書き込んだりしないでください。同期を完了するには、次の手順に従います:
-
同期ラグの監視
-
Lag Behind Source（ミリ秒または秒で表示）を追跡して、同期の進行状況を監視します。このインジケーターは、ソースクラスターとターゲットクラスターの最新データ間の時間差を示します。
-
Lag Behind Source が 10 秒未満になると、データ同期の停止に進めることを示すメール通知が届きます。
-
重要: 妥当な待機時間が経過しても同期ラグが 10 秒未満にならない場合は、Zilliz Cloud サポート にお問い合わせください。
-
-
データ同期の停止
-
ソースクラスターへのサービスとすべての書き込みを停止します。データ同期を停止してアプリケーションをターゲットクラスターに切り替える間も、書き込みを停止したままにしてください。
-
Lag Behind Source が 10 秒未満 で、ソースへの書き込みが停止している場合は、I confirm that I have stopped writes to the source cluster を選択してから、Stop Data Sync をクリックします。これが通常の切り替え手順です。完了すると、移行ジョブに Success と表示されます。
Notes増分同期は 最大 7 日間 サポートされます。この期間内に移行を完了するように計画してください。さらに時間が必要な場合は、Zilliz Cloud サポート にお問い合わせください。
-
フェーズ 3: 切り替え
Stop Data Sync をクリックした後、アプリケーションをターゲットクラスターに切り替える前に、移行が完了するまで待ちます。同期ラグが 10 秒未満になったというメール通知は、データ同期を停止する準備ができたことを示すものであり、移行が完了したことを意味するものではありません。
-
Migration Progress ダイアログで移行が完了するまで待ちます。完了した移行ジョブには Success と表示されます。
-
View Connection Details And Close Dialog をクリックして、ターゲットクラスターの接続情報を表示します。
-
以下で説明するように、検索またはクエリ操作の前に、移行したコレクションを手動でロードします。アプリケーションコードのエンドポイントと認証情報を更新してターゲットクラスターに接続し、アプリケーションがデータを読み書きできることを確認します。
クラスターへの接続方法については、Connect to Cluster を参照してください。
-
移行後、ソースクラスターは自動的に削除されません。手動で削除する前にデータの整合性を確認するため、一定期間保持することをお勧めします。
-
移行したコレクションは、検索またはクエリ操作にすぐには使用できません。Zilliz Cloud でコレクションを手動でロードして、検索およびクエリ機能を有効にする必要があります。詳細については、Load & Release を参照してください。
移行のキャンセル
移行を中止するには、Jobs を開き、移行ジョブを見つけて、使用可能な場合はそのアクションメニューから Cancel を選択します。キャンセルすると同期が停止し、ジョブのステータスが Canceled に変わります。ターゲットに既に同期されたデータは自動的には削除されません。必要に応じてそのデータを確認して処理してください。
アプリケーションを切り替える前に移行を完了するには、Migration Progress ダイアログで Stop Data Sync を使用します。完了したジョブには Success と表示されます。移行を中止するには Cancel を使用します。ジョブには Canceled と表示されます。