CDC 복제 설정
이 가이드는 Milvus Operator를 사용하여 두 개의 독립 실행형 Milvus 클러스터를 배포하고 소스 클러스터에서 대상 클러스터로 CDC 복제를 구성하는 방법을 보여줍니다.
예제에서는
source-cluster를 기본 클러스터로target-cluster를 대기 클러스터로.milvus를 Milvus 클러스터의 네임스페이스로.milvus-operator를 Milvus 오퍼레이터의 네임스페이스로 사용합니다.
시작하기 전에 Milvus CDC를 읽고 기본-대기 모델과 장애 조치 옵션을 이해하세요.
전제 조건
- Milvus v2.6.16 이상.
- Milvus Operator v1.3.4 이상.
- Kubernetes 클러스터를 사용할 수 있습니다.
- 소스 및 대상 클러스터는 네트워크를 통해 서로 연결할 수 있습니다.
- 두 Milvus 클러스터에 대한 관리자 자격 증명이 있습니다.
- 각 클러스터의 물리적 채널 수를 알고 있습니다.
1단계: Milvus 운영자 업그레이드하기
Milvus Operator 헬름 리포지토리를 추가합니다:
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
오퍼레이터 파드가 실행 중인지 확인합니다:
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
두 가지 유형의 주소를 준비합니다:
- 클러스터 주소는 복제 구성에 기록되고 CDC 구성 요소에서 사용됩니다. 이 주소는 CDC 포드에서 연결할 수 있어야 합니다.
- 클라이언트 주소는 Milvus API를 호출할 때 Python 클라이언트에서만 사용됩니다. 쿠버네티스 클러스터 외부에서 Python 클라이언트를 실행하는 경우, 로드 밸런서, 인그레스 또는 포트 포워드와 같은 일반적인 액세스 방법을 통해 Milvus 서비스를 노출하세요.
두 클러스터에 대한 연결 정보 및 p채널 목록을 준비합니다:
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 을 로컬 포트 포워드 주소로 설정하지 마세요. p채널 목록은 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 과 같이 배포에 맞는 라벨 필터를 추가하여 다른 클러스터의 메트릭이 혼합되지 않도록 하세요.
FAQ
두 클러스터에서 모두 update_replicate_configuration 으로 전화해야 하나요?
예. 모든 참여 클러스터에 동일한 토폴로지를 적용하세요. 호출 시점에 한 클러스터가 기본 클러스터가 아닌 경우 CDC를 통해 토폴로지가 적용될 때까지 기다립니다.
cluster_id 을 어떻게 선택해야 하나요?
각 클러스터에 대해 안정적이고 고유한 ID를 사용합니다. 이 ID는 p채널 이름과 복제 토폴로지 참조에도 사용됩니다.
복제를 구성한 후에 p채널을 변경할 수 있나요?
토폴로지를 업데이트할 수 있지만 p채널 목록이 클러스터 레이아웃과 일치해야 합니다. p채널 변경은 고급 작업으로 취급하고 나중에 신중하게 복제를 확인하세요.