CDCレプリケーションの設定
このガイドでは、Milvus Operatorを使用して2つのスタンドアロンMilvusクラスタをデプロイし、ソースクラスタからターゲットクラスタへのCDCレプリケーションを設定する方法を示します。
例では
source-clusterをプライマリクラスタとして使用します。target-clusterスタンバイクラスタとしてmilvusMilvusクラスタの名前空間として使用します。milvus-operatorMilvus Operatorのネームスペースとして使用します。
始める前に、Milvus CDCを読んで、プライマリ-スタンバイ・モデルとフェイルオーバー・オプションを理解してください。
前提条件
- Milvus v2.6.16以降。
- Milvus Operator v1.3.4以降。
- Kubernetesクラスタが利用可能である。
- ソースクラスタとターゲットクラスタがネットワークを介して互いに接続できる。
- 両方のMilvusクラスタの管理者認証情報を持っている。
- 各クラスタの物理チャネル数がわかっている。
ステップ1: Milvus Operatorのアップグレード
Milvus Operator Helmリポジトリを追加します:
helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
リポジトリを更新します:
helm repo update zilliztech-milvus-operator
Milvus Operatorをインストールまたはアップグレードします:
helm -n milvus-operator upgrade --install milvus-operator \
zilliztech-milvus-operator/milvus-operator \
--create-namespace
Operator podが実行されていることを確認します:
kubectl get pods -n milvus-operator
出力例
NAME READY STATUS RESTARTS AGE
milvus-operator-6f7d8c9c7d-xm4tj 1/1 Running 0 54s
ステップ2: ソースクラスタのデプロイ
milvus_source_cluster.yaml という名前のファイルを作成します:
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: source-cluster
namespace: milvus
labels:
app: milvus
spec:
mode: standalone
components:
image: milvusdb/milvus:v2.6.16
cdc:
replicas: 1
dependencies:
msgStreamType: woodpecker
設定を適用します:
kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml
ソース・クラスター・ポッドが実行されていることを確認します:
kubectl get pods -n milvus
出力例:
NAME READY STATUS RESTARTS AGE
source-cluster-etcd-0 1/1 Running 0 3m
source-cluster-minio-6d8f7d9b9f-9t7j2 1/1 Running 0 3m
source-cluster-milvus-standalone-7f8d9c8f6d-r2m5x 1/1 Running 0 2m
source-cluster-milvus-cdc-66d64747bd-sckxj 1/1 Running 0 2m
source-cluster-milvus-cdc-... などのCDCポッドがRunning の状態になっていることを確認します。
ステップ3: ターゲット・クラスタのデプロイ
milvus_target_cluster.yaml という名前のファイルを作成します:
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
name: target-cluster
namespace: milvus
labels:
app: milvus
spec:
mode: standalone
components:
image: milvusdb/milvus:v2.6.16
cdc:
replicas: 1
dependencies:
msgStreamType: woodpecker
ターゲットクラスタでもCDCコンポーネントが有効になっています。ターゲットがスタンバイの間はアイドル状態ですが、切り替え後にターゲットがプライマリになる場合は必要です。
設定を適用します:
kubectl apply -f milvus_target_cluster.yaml
ターゲット・クラスタのポッドが起動していることを確認します:
kubectl get pods -n milvus | grep -E 'NAME|target-cluster'
出力例:
NAME READY STATUS RESTARTS AGE
target-cluster-etcd-0 1/1 Running 0 3m
target-cluster-minio-5f7c8d9b6f-k8s2q 1/1 Running 0 3m
target-cluster-milvus-standalone-66dc8d9f7f-5n6bp 1/1 Running 0 2m
target-cluster-milvus-cdc-7f8c9d6b8c-q4t9m 1/1 Running 0 2m
ステップ4: クラスタ情報の準備
両方のクラスタのMilvusサービスアドレスを取得します:
kubectl get svc -n milvus | grep -E 'NAME|source-cluster|target-cluster'
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
source-cluster-milvus ClusterIP 10.98.124.90 <none> 19530/TCP,9091/TCP 8m
target-cluster-milvus ClusterIP 10.109.234.172 <none> 19530/TCP,9091/TCP 3m
2種類のアドレスを準備します:
- クラスタアドレスはレプリケーション構成に書き込まれ、CDCコンポーネントによって使用されます。これらのアドレスはCDCポッドから到達可能でなければなりません。
- クライアントアドレスはPythonクライアントがMilvus APIを呼び出すときにのみ使用されます。Kubernetesクラスタ外でPythonクライアントを実行する場合は、ロードバランサ、イングレス、ポートフォワードなど、通常のアクセス方法でMilvusサービスを公開します。
両方のクラスタの接続情報とpchannelリストを準備します:
source_cluster_addr = "http://source-cluster-milvus.milvus.svc.cluster.local:19530"
target_cluster_addr = "http://target-cluster-milvus.milvus.svc.cluster.local:19530"
source_client_addr = source_cluster_addr
target_client_addr = target_cluster_addr
# If your Python client runs outside the Kubernetes cluster, replace only
# source_client_addr and target_client_addr with externally reachable addresses.
# Keep source_cluster_addr and target_cluster_addr reachable from CDC pods.
# For example:
# source_client_addr = "http://127.0.0.1:19530"
# target_client_addr = "http://127.0.0.1:19531"
source_cluster_token = "root:Milvus"
target_cluster_token = "root:Milvus"
source_cluster_id = "source-cluster"
target_cluster_id = "target-cluster"
pchannel_num = 16
source_cluster_pchannels = [
f"{source_cluster_id}-rootcoord-dml_{i}"
for i in range(pchannel_num)
]
target_cluster_pchannels = [
f"{target_cluster_id}-rootcoord-dml_{i}"
for i in range(pchannel_num)
]
アドレスを実際のMilvusサービスのアドレスに置き換えてください。CDCポッドもそのアドレスに到達できる場合を除き、source_cluster_addr またはtarget_cluster_addr をローカルのポートフォワードアドレスに設定しないでください。pchannelリストはMilvusの展開と一致している必要があります。クラスタ構成を確認せずに例の値をコピーしないでください。
ステップ5: レプリケーション構成の作成
source-cluster からtarget-cluster へのレプリケーション構成を作成します:
replicate_config = {
"clusters": [
{
"cluster_id": source_cluster_id,
"connection_param": {
"uri": source_cluster_addr,
"token": source_cluster_token,
},
"pchannels": source_cluster_pchannels,
},
{
"cluster_id": target_cluster_id,
"connection_param": {
"uri": target_cluster_addr,
"token": target_cluster_token,
},
"pchannels": target_cluster_pchannels,
},
],
"cross_cluster_topology": [
{
"source_cluster_id": source_cluster_id,
"target_cluster_id": target_cluster_id,
}
],
}
ステップ6: レプリケーション構成の適用
両方のクラスタに同じ構成を適用します:
from pymilvus import MilvusClient
source_client = MilvusClient(
uri=source_client_addr,
token=source_cluster_token,
)
target_client = MilvusClient(
uri=target_client_addr,
token=target_cluster_token,
)
try:
source_client.update_replicate_configuration(**replicate_config)
target_client.update_replicate_configuration(**replicate_config)
finally:
source_client.close()
target_client.close()
プロダクション・オートメーションでは、このコントロール・プレーン操作に別々の短命クライアントを使用します。これにより、クラスタ・ロールの変更中にアプリケーションDMLトラフィックと同じgRPCチャネルを共有することを回避できます。
構成が適用されると、source-cluster に書き込まれた変更がtarget-cluster にレプリケートされます。
ステップ7:データ・レプリケーションの検証
レプリケーションが機能することを確認します:
source-clusterに接続します。- コレクションを作成します。
- コレクションにデータを挿入する。
- コレクションをロードし、
source-clusterでクエリまたは検索を実行する。 target-clusterに接続する。- スタンバイ・クラスタでコレクションを手動でロードせずに、
target-clusterで同じクエリまたは検索を実行します。 - 期待されるデータが両方のクラスタで表示されていることを確認します。
ターゲット・クラスタは、このトポロジではスタンバイ・クラスタです。load_collection などの手動DDLまたはDCL操作をスタンバイ・クラスタで実行しないでください。これらの操作はソース・クラスタで実行し、ターゲット・クラスタにレプリケートする必要があります。
正確な検証コードはコレクションスキーマに依存します。基本的なMilvusコレクションワークフローについては、Milvusクイックスタートドキュメントを参照してください。
CDCラグ
CDCラグはプライマリクラスタとスタンバイクラスタ間のデータウィンドウです。レプリケーションが構成された後、継続的に監視する必要があります。
CDCラグは以下の場合に増加する可能性があります:
- プライマリの書き込みレートが高い。
- クラスタ間のネットワーク遅延またはパケットロスが増加した場合。
- スタンバイ・クラスタが過負荷になっている。
- CDCノードのプロビジョニングが不足している。
- 大規模なDDLまたはインポート処理が実行されている。
CDCのラグを使用して運用上の決定を導きます:
- ラグが小さい場合、切り替えはより速く完了するはずです。
- ラグが小さい場合、切り替えはより速く完了するはずです。ラグが大きい場合、フェイルオーバーにより多くのデータが失われる可能性があります。
以下のPromQLクエリでCDCラグを見積もることができます:
clamp_min(
max by (channel_name) (
milvus_wal_last_confirmed_time_tick
)
-
min by (channel_name) (
milvus_cdc_last_replicated_time_tick
),
0
)
結果は秒単位です。各ソース・チャネルについて、このクエリは確認された最新のWALタイムティックとCDCによってレプリケートされた最後のタイムティックを比較します。プライマリが複数のスタンバイ・クラスタにレプリケートする場合、min by (channel_name) 式はそのチャネルの最も遅いレプリケーション進捗を報告します。
Prometheusが複数のMilvusクラスタをスクレイピングする場合は、namespace やapp_kubernetes_io_instance など、デプロイメントにマッチするラベルフィルタを追加して、異なるクラスタのメトリクスが混在しないようにしてください。
よくある質問
両方のクラスタでupdate_replicate_configuration を呼び出す必要がありますか?
はい。参加するすべてのクラスタに同じトポロジを適用します。呼び出し時に一方のクラスタがプライマリでない場合は、CDCを介してトポロジが適用されるまで待機します。
cluster_id はどのように選択すればよいですか?
各クラスタに安定した一意のIDを使用します。このIDはpchannel名やレプリケーション・トポロジーの参照にも使用されます。
レプリケーション設定後にpchannelを変更できますか?
トポロジーを更新することはできますが、pchannelリストはクラスタ・レイアウトと一致している必要があります。pchannelの変更は高度な操作として扱い、その後レプリケーションを慎重に検証してください。