Configurar la replicación CDC

Esta guía muestra cómo desplegar dos clústeres Milvus independientes con Milvus Operator y configurar la replicación CDC desde un clúster de origen a un clúster de destino.

Los ejemplos utilizan:

• source-cluster como clúster primario.
• target-cluster como clúster en espera.
• milvus como espacio de nombres para los clústeres Milvus.
• milvus-operator como espacio de nombres para Milvus Operator.

Antes de comenzar, lea Milvus CDC para comprender el modelo primario-standby y las opciones de conmutación por error.

Requisitos previos

• Milvus v2.6.16 o posterior.
• Milvus Operator v1.3.4 o posterior.
• Se dispone de un clúster Kubernetes.
• Los clústeres de origen y destino pueden conectarse entre sí a través de la red.
• Dispone de credenciales de administrador para ambos clústeres Milvus.
• Conoce el número de canales físicos de cada clúster.

Paso 1: Actualice Milvus Operator

Agregue el repositorio Milvus Operator Helm:

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/

Actualice el repositorio:

helm repo update zilliztech-milvus-operator

Instale o actualice Milvus Operator:

helm -n milvus-operator upgrade --install milvus-operator \
  zilliztech-milvus-operator/milvus-operator \
  --create-namespace

Compruebe que el pod de operador se está ejecutando:

kubectl get pods -n milvus-operator

Ejemplo de salida:

NAME                               READY   STATUS    RESTARTS   AGE
milvus-operator-6f7d8c9c7d-xm4tj   1/1     Running   0          54s

Paso 2: Despliegue del clúster de origen

Cree un archivo llamado 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

Aplique la configuración:

kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml

Compruebe que los pods del cluster de origen se están ejecutando:

kubectl get pods -n milvus

Ejemplo de salida:

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

Asegúrese de que el pod CDC, como source-cluster-milvus-cdc-..., está en el estado Running.

Paso 3: Despliegue del cluster de destino

Cree un archivo llamado 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

El componente CDC también está habilitado en el cluster de destino. Estará inactivo mientras el destino esté en espera, pero será necesario si el destino se convierte en el primario después de la conmutación.

Aplique la configuración:

kubectl apply -f milvus_target_cluster.yaml

Compruebe que los pods del cluster de destino se están ejecutando:

kubectl get pods -n milvus | grep -E 'NAME|target-cluster'

Ejemplo de salida:

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

Paso 4: Preparar la información del cluster

Obtenga las direcciones de servicio Milvus para ambos clusters:

kubectl get svc -n milvus | grep -E 'NAME|source-cluster|target-cluster'

Ejemplo de salida:

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

Prepare dos tipos de direcciones:

• Las direcciones de cluster se escriben en la configuración de replicación y son utilizadas por los componentes CDC. Estas direcciones deben ser accesibles desde los pods CDC.
• Las direcciones de cliente sólo las utiliza su cliente Python cuando llama a las API de Milvus. Si ejecuta el cliente Python fuera del clúster Kubernetes, exponga los servicios Milvus a través de su método de acceso normal, como un equilibrador de carga, ingress o port-forward.

Prepare la información de conexión y las listas pchannel para ambos clústeres:

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)
]

Sustituya las direcciones por las direcciones reales del servicio Milvus en su entorno. No establezca source_cluster_addr o target_cluster_addr en una dirección local de reenvío de puerto a menos que los pods CDC también puedan llegar a esa dirección. La lista pchannel debe coincidir con su despliegue de Milvus. No copie los valores de ejemplo sin comprobar la configuración de su cluster.

Paso 5: Crear la configuración de replicación

Cree una configuración de replicación de source-cluster a 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,
        }
    ],
}

Paso 6: Aplicar la configuración de replicación

Aplique la misma configuración a ambos clústeres:

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()

Para la automatización de la producción, utilice clientes separados de corta duración para esta operación del plano de control. Esto evita compartir el mismo canal gRPC con el tráfico DML de la aplicación mientras cambia el rol del clúster.

Una vez aplicada la configuración, los cambios escritos en source-cluster se replican en target-cluster.

Paso 7: Verificar la replicación de datos

Para verificar que la replicación funciona

1. Conéctese a source-cluster.
2. Cree una colección.
3. Inserte datos en la colección.
4. Cargue la colección y ejecute una consulta o búsqueda en source-cluster.
5. Conéctese a target-cluster.
6. Ejecute la misma consulta o búsqueda en target-cluster sin cargar manualmente la colección en el clúster en espera.
7. Confirme que los datos esperados son visibles en ambos clústeres.

El clúster de destino es un clúster en espera en esta topología. No ejecute operaciones DDL o DCL manuales, como load_collection, en el clúster en espera. Estas operaciones deben realizarse en el clúster de origen y replicarse en el clúster de destino.

El código de verificación exacto depende de su esquema de recopilación. Para obtener un flujo de trabajo de recopilación básico de Milvus, consulte la documentación de inicio rápido de Milvus.

Retraso de CDC

El retraso de CDC es la ventana de datos entre los clústeres primario y en espera. Debe supervisarlo continuamente después de configurar la replicación.

El retraso de CDC puede aumentar cuando:

• La tasa de escritura primaria es alta.
• La latencia de la red o la pérdida de paquetes aumenta entre clusters.
• El cluster en espera está sobrecargado.
• Los nodos CDC están sub-aprovisionados.
• Se ejecutan grandes operaciones DDL o de importación.

Utilice el retardo de CDC para orientar las decisiones operativas:

• Si el retraso es bajo, la conmutación debería completarse más rápido.
• Si el lag es alto, la conmutación por error puede perder más datos.

Puede estimar el retraso de CDC con la siguiente consulta PromQL:

clamp_min(
  max by (channel_name) (
    milvus_wal_last_confirmed_time_tick
  )
  -
  min by (channel_name) (
    milvus_cdc_last_replicated_time_tick
  ),
  0
)

El resultado está en segundos. Para cada canal fuente, la consulta compara el último timetick WAL confirmado con el último timetick replicado por CDC. Si un primario replica a varios clústeres en espera, la expresión min by (channel_name) informa del progreso de replicación más lento para ese canal.

Si Prometheus rastrea varios clústeres de Milvus, añada filtros de etiquetas que coincidan con su despliegue, como namespace o app_kubernetes_io_instance, para evitar mezclar métricas de diferentes clústeres.

PREGUNTAS FRECUENTES

¿Necesito llamar a update_replicate_configuration en ambos clústeres?

Sí. Aplique la misma topología a todos los clústeres participantes. Si un clúster no es primario en el momento de la llamada, espera hasta que se aplique la topología a través de CDC.

¿Cómo debo elegir cluster_id?

Utilice un ID estable y único para cada clúster. El ID también se utiliza en los nombres de pchannel y en las referencias de topología de replicación.

¿Puedo cambiar los pchannels una vez configurada la replicación?

Puede actualizar la topología, pero la lista de pchannel debe coincidir con la disposición del cluster. Trate los cambios de pchannel como una operación avanzada y verifique la replicación cuidadosamente después.