Home
Blog
Alta disponibilidade da base de dados Vetor: como criar um cluster Milvus Standby com CDC

Alta disponibilidade da base de dados Vetor: como criar um cluster Milvus Standby com CDC

Tutorials

March 26, 2026

Cal Huang

Todas as bases de dados de produção precisam de um plano para quando as coisas correm mal. As bases de dados relacionais têm tido envio WAL, replicação binlog e failover automatizado há décadas. Mas as bases de dados vectoriais - apesar de se tornarem infra-estruturas essenciais para aplicações de IA - ainda estão a recuperar o atraso nesta frente. A maioria oferece redundância em nível de nó, na melhor das hipóteses. Se um cluster completo cair, você está restaurando a partir de backups e reconstruindo índices vetoriais do zero - um processo que pode levar horas e custar milhares em computação, porque regenerar embeddings por meio de seu pipeline de ML não é barato.

O Milvus adota uma abordagem diferente. Ele oferece alta disponibilidade em camadas: réplicas em nível de nó para failover rápido dentro de um cluster, replicação baseada em CDC para proteção em nível de cluster e entre regiões, e backup para recuperação de rede de segurança. Esse modelo em camadas é uma prática padrão em bancos de dados tradicionais - o Milvus é o primeiro grande banco de dados vetorial a trazê-lo para cargas de trabalho vetoriais.

Este guia cobre duas coisas: as estratégias de alta disponibilidade disponíveis para bancos de dados vetoriais (para que você possa avaliar o que "pronto para produção" realmente significa) e um tutorial prático para configurar a replicação primária-em espera do Milvus CDC a partir do zero.

Esta é a Parte 1 de uma série:

Parte 1 (este artigo): Configurando a replicação primária-em espera em novos clusters

Parte 2: Adicionar o CDC a um cluster existente que já tem dados, utilizando o Milvus Backup

Parte 3: Gerenciando o failover - promovendo o standby quando o primário cai

Porque é que a Alta Disponibilidade é mais importante para as Bases de Dados Vectoriais?

Quando uma base de dados SQL tradicional fica inoperacional, perde-se o acesso a registos estruturados - mas os dados em si podem normalmente ser reimportados a partir de fontes a montante. Quando uma base de dados vetorial falha, a recuperação é fundamentalmente mais difícil.

As bases de dados vectoriais armazenam embeddings - representações numéricas densas geradas por modelos de ML. Reconstruí-las significa executar novamente todo o conjunto de dados através do pipeline de incorporação: carregar documentos em bruto, dividi-los, chamar um modelo de incorporação e reindexar tudo. Para um conjunto de dados com centenas de milhões de vectores, isto pode demorar dias e custar milhares de dólares em computação GPU.

Entretanto, os sistemas que dependem da pesquisa vetorial estão frequentemente no caminho crítico:

Os pipelinesRAG que alimentam os chatbots e a pesquisa orientados para o cliente - se a base de dados de vectores estiver em baixo, a recuperação pára e a IA devolve respostas genéricas ou alucinadas.
Motores de recomendação que fornecem sugestões de produtos ou conteúdos em tempo real - tempo de inatividade significa perda de receitas.
Sistemasde deteção de fraudes e de monitorização de anomalias que dependem da pesquisa de semelhanças para assinalar actividades suspeitas - uma lacuna na cobertura cria uma janela de vulnerabilidade.
Sistemas de agentes autónomos que utilizam armazéns vectoriais para recuperação de memória e de ferramentas - os agentes falham ou entram em loop sem a sua base de conhecimentos.

Se estiver a avaliar as bases de dados de vectores para qualquer um destes casos de utilização, a alta disponibilidade não é uma caraterística agradável de ter para verificar mais tarde. Ela deve ser uma das primeiras coisas a serem observadas.

Como é a HA de nível de produção para uma base de dados vetorial?

Nem toda alta disponibilidade é igual. Um banco de dados vetorial que só lida com falhas de nós em um único cluster não é "altamente disponível" da maneira que um sistema de produção exige. A HA real precisa cobrir três camadas:

Camada	Contra o que ela protege	Como funciona	Tempo de recuperação	Perda de dados
Nível de nó (multi-replicação)	Uma falha de um único nó, falha de hardware, OOM kill, falha de AZ	Copia os mesmos segmentos de dados em vários nós; outros nós absorvem a carga	Instantâneo	Zero
Nível de cluster (replicação CDC)	Todo o cluster vai abaixo - má implementação do K8s, eliminação do namespace, corrupção do armazenamento	Transmite todas as escritas para um cluster em espera através do registo de escrita à cabeça; o cluster em espera está sempre segundos atrasado	Minutos	Segundos
Rede de segurança (cópia de segurança periódica)	Corrupção catastrófica de dados, ransomware, erro humano que se propaga através da replicação	Tira instantâneos periódicos e armazena-os numa localização separada	Horas	Horas (desde o último backup)

Estas camadas são complementares, não alternativas. Uma implantação de produção deve empilhá-las:

Multi-replicaprimeiro - lida com a falha mais comum (falhas de nó, falhas de AZ) com tempo de inatividade zero e perda de dados zero.
CDC em seguida - protege contra falhas que a multi-replicação não consegue: interrupções em todo o cluster, erro humano catastrófico. O cluster em espera está num domínio de falha diferente.
Backups periódicos sempre - sua rede de segurança de último recurso. Nem mesmo o CDC o pode salvar se os dados corrompidos forem replicados para o standby antes de o apanhar.

Ao avaliar as bases de dados vectoriais, pergunte: qual destas três camadas é efetivamente suportada pelo produto? Atualmente, a maioria das bases de dados vectoriais apenas oferece a primeira. O Milvus suporta as três, sendo o CDC uma funcionalidade incorporada - e não um complemento de terceiros.

O que é o Milvus CDC e como funciona?

O Milvus CDC (Change Data Capture) é um recurso de replicação integrado que lê o Write-Ahead Log (WAL) do cluster primário e transmite cada entrada para um cluster standby separado. O standby repete as entradas e acaba com os mesmos dados, normalmente com segundos de atraso.

O padrão está bem estabelecido no mundo das bases de dados. O MySQL tem a replicação binlog. O PostgreSQL tem o envio WAL. O MongoDB tem replicação baseada em oplog. Essas são técnicas comprovadas que mantiveram bancos de dados relacionais e de documentos funcionando em produção por décadas. O Milvus traz a mesma abordagem para cargas de trabalho vetoriais - é o primeiro grande banco de dados vetorial a oferecer replicação baseada em WAL como um recurso integrado.

Três propriedades tornam o CDC uma boa opção para a recuperação de desastres:

Sincronização de baixa latência. O CDC transmite as operações à medida que elas acontecem, não em lotes programados. O standby permanece segundos atrás do primário em condições normais.
Repetição ordenada. As operações chegam ao standby na mesma ordem em que foram gravadas. Os dados permanecem consistentes sem reconciliação.
Recuperação de ponto de verificação. Se o processo CDC falhar ou a rede cair, ele é retomado de onde parou. Nenhum dado é ignorado ou duplicado.

Como funciona a arquitetura do CDC?

Uma implantação do CDC tem três componentes:

CDC architecture showing Source Cluster with Streaming Nodes and CDC Nodes consuming the WAL, replicating data to the Target Cluster's Proxy layer, which forwards DDL/DCL/DML operations to Streaming Nodes and appends to WAL Arquitetura CDC mostrando o cluster de origem com nós de streaming e nós CDC consumindo o WAL, replicando dados para a camada proxy do cluster de destino, que encaminha operações DDL/DCL/DML para nós de streaming e anexa ao WAL

Componente	Função
Cluster primário	A instância de produção do Milvus. Todas as leituras e escritas são efectuadas aqui. Todas as escritas são registadas no WAL.
Nó CDC	Um processo em segundo plano ao lado do primário. Lê as entradas do WAL e encaminha-as para o standby. Funciona independentemente do caminho de leitura/escrita - sem impacto no desempenho da consulta ou da inserção.
Cluster em espera	Uma instância separada do Milvus que repete as entradas WAL encaminhadas. Mantém os mesmos dados que o primário, com segundos de atraso. Pode servir consultas de leitura mas não aceita escritas.

O fluxo: as escritas chegam ao primário → o Nó CDC copia-as para o standby → o standby repete-as. Nada mais fala com o caminho de escrita do standby. Se o primário cair, o standby já tem quase todos os dados e pode ser promovido.

Tutorial: Configurando um cluster Milvus CDC Standby

O restante deste artigo é um passo a passo prático. No final, você terá dois clusters Milvus em execução com replicação em tempo real entre eles.

Pré-requisitos

Antes de começar:

Milvus v2.6.6 ou posterior. O CDC requer esta versão. Recomendamos o patch mais recente da versão 2.6.x.
Milvus Operator v1.3.4 ou posterior. Este guia usa o Operator para gerenciamento de cluster no Kubernetes.
Um cluster Kubernetes em execução com kubectl e helm configurados.
Python com pymilvus para a etapa de configuração de replicação.

Duas limitações na versão atual:

Limitação	Detalhes
Réplica única do CDC	Uma réplica do CDC por cluster. O CDC distribuído está planeado para uma versão futura.
Sem BulkInsert	OBulkInsert não é suportado enquanto o CDC estiver ativado. Também planeado para uma versão futura.

Etapa 1: Atualizar o Milvus Operator

Atualize o Milvus Operator para a versão 1.3.4 ou posterior:

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
# "zilliztech-milvus-operator" has been added to your repositories
helm repo update zilliztech-milvus-operator
# Hang tight while we grab the latest from your chart repositories…
# …Successfully got an update from the “zilliztech-milvus-operator” chart repository
# Update Complete. ⎈Happy Helming!⎈
helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
# Release “milvus-operator” has been upgraded. Happy Helming!
# NAME: milvus-operator
# LAST DEPLOYED: Wed Dec  3 17:25:28 2025
# NAMESPACE: milvus-operator
# STATUS: deployed
# REVISION: 30
# TEST SUITE: None
# NOTES:
# Milvus Operator Is Starting, use kubectl get -n milvus-operator deploy/milvus-operator to check if its successfully installed
# Full Installation doc can be found in https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md
# Quick start with kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_minimum.yaml
# More samples can be found in https://github.com/zilliztech/milvus-operator/tree/main/config/samples
# CRD Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/CRD
# Administration Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/administration

Verifique se o pod do operador está em execução:

kubectl get pods -n milvus-operator
# NAME                             READY   STATUS    RESTARTS   AGE
# milvus-operator-9fc99f88-h2hwz   1/1     Running   0          54s

Passo 2: Implantar o cluster primário

Crie um ficheiro YAML para o cluster primário (fonte). A secção cdc em components diz ao Operador para implementar um Nó CDC juntamente com o cluster:

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
    cdc:
      replicas: 1  # Currently, CDC only supports 1 replica
  dependencies:
    msgStreamType: woodpecker

A configuração msgStreamType: woodpecker usa o Woodpecker WAL integrado do Milvus em vez de uma fila de mensagens externa como Kafka ou Pulsar. O Woodpecker é um log de gravação antecipada nativo da nuvem introduzido no Milvus 2.6 que remove a necessidade de infraestrutura de mensagens externas.

Aplique a configuração:

kubectl create namespace milvus
# namespace/milvus created
kubectl apply -f milvus_source_cluster.yaml
# milvus.milvus.io/source-cluster created

Aguarde até que todos os pods atinjam o status Em execução. Confirmar se o pod CDC está ativo:

kubectl get pods -n milvus
# Look for source-cluster-milvus-cdc-xxx in Running state
# NAME                                                READY   STATUS    RESTARTS   AGE
# source-cluster-milvus-cdc-66d64747bd-sckxj          1/1     Running   0          2m42s
# source-cluster-milvus-datanode-85f9f56fd-qgbzq       1/1     Running   0          2m42s
# ...

Etapa 3: implantar o cluster em espera

O cluster em espera (destino) usa a mesma versão do Milvus, mas não inclui um componente CDC - ele só recebe dados replicados:

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
  dependencies:
    msgStreamType: woodpecker

Aplicar:

kubectl apply -f milvus_target_cluster.yaml
# milvus.milvus.io/target-cluster created

Verifique se todos os pods estão em execução:

kubectl get pods -n milvus
# NAME                                                   READY   STATUS    RESTARTS   AGE
# ...
# target-cluster-milvus-datanode-7ffc8cdb6b-xhzcd        1/1     Running   0          104m
# target-cluster-milvus-mixcoord-8649b87c98-btk7m        1/1     Running   0          104m
# ...

Etapa 4: Configurar a relação de replicação

Com os dois clusters em execução, configure a topologia de replicação usando Python com pymilvus.

Defina os detalhes da conexão do cluster e os nomes do canal físico (pchannel):

source_cluster_addr = "http://10.98.124.90:19530" # example address — replace with your actual Milvus server address
target_cluster_addr = "http://10.109.234.172:19530"
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 = []
target_cluster_pchannels = []
for i in range(pchannel_num):
source_cluster_pchannels.append(f"{source_cluster_id}-rootcoord-dml_{i}")
target_cluster_pchannels.append(f"{target_cluster_id}-rootcoord-dml_{i}")

Crie a configuração de replicação:

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

Aplicar em ambos os clusters:

from pymilvus import MilvusClient
source_client = MilvusClient(uri=source_cluster_addr, token=source_cluster_token)
source_client.update_replicate_configuration(**config)
source_client.close()
target_client = MilvusClient(uri=target_cluster_addr, token=target_cluster_token)
target_client.update_replicate_configuration(**config)
target_client.close()

Quando isso for bem-sucedido, as alterações incrementais no primário começarão a ser replicadas automaticamente para o standby.

Etapa 5: verificar se a replicação funciona

Conecte-se ao primário e crie uma coleção, insira alguns vetores e carregue-a
Execute uma pesquisa no primário para confirmar que os dados estão lá
Conecte-se ao standby e execute a mesma pesquisa
Se o standby apresentar os mesmos resultados, a replicação está a funcionar

O Milvus Quickstart abrange a criação, inserção e pesquisa de colecções, caso necessite de uma referência.

Executando o CDC na produção

A configuração do CDC é a parte mais simples. Mantê-lo confiável ao longo do tempo requer atenção a algumas áreas operacionais.

Monitorar o atraso da replicação

O standby está sempre ligeiramente atrasado em relação ao primário - isso é inerente à replicação assíncrona. Sob carga normal, o atraso é de alguns segundos. Mas picos de escrita, congestionamento de rede ou pressão de recursos no standby podem fazer com que ele aumente.

Acompanhe o atraso como uma métrica e alerte sobre ele. Um atraso que cresce sem recuperação geralmente significa que o nó CDC não consegue acompanhar a taxa de transferência de gravação. Verifique primeiro a largura de banda da rede entre os clusters e, em seguida, considere se o standby precisa de mais recursos.

Usar o standby para escalonamento de leitura

O standby não é apenas um backup frio que fica ocioso até que ocorra um desastre. Aceita pedidos de pesquisa e consulta enquanto a replicação está ativa - apenas as escritas são bloqueadas. Isso abre possibilidades de uso prático:

Encaminhar cargas de trabalho de pesquisa ou análise por semelhança de lote para o standby
Dividir o tráfego de leitura durante as horas de pico para reduzir a pressão sobre o primário
Executar consultas dispendiosas (grandes top-K, pesquisas filtradas em grandes colecções) sem afetar a latência de escrita da produção

Isso transforma sua infraestrutura de DR em um ativo de desempenho. O standby ganha seu sustento mesmo quando nada está quebrado.

Dimensionar o standby corretamente

O standby repete cada gravação do primário, portanto, precisa de recursos de computação e memória semelhantes. Se também estiver a encaminhar leituras para ele, tenha em conta essa carga adicional. Os requisitos de armazenamento são idênticos - ele mantém os mesmos dados.

Teste o Failover antes de precisar dele

Não espere por uma falha real para descobrir que o seu processo de ativação pós-falha não funciona. Execute simulações periódicas:

Parar as gravações no primário
Aguardar que o standby recupere o atraso (atraso → 0)
Promover o standby
Verificar se as consultas retornam os resultados esperados
Reverter o processo

Medir o tempo que cada passo demora e documentá-lo. O objetivo é tornar a ativação pós-falha um procedimento de rotina com um calendário conhecido - e não uma improvisação stressante às 3 da manhã. A Parte 3 desta série aborda o processo de failover em detalhes.

Não quer gerir o CDC você mesmo? O Zilliz Cloud trata disso

Configurar e operar a replicação CDC do Milvus é poderoso, mas vem com uma sobrecarga operacional: você gerencia dois clusters, monitora a integridade da replicação, lida com runbooks de failover e mantém a infraestrutura em todas as regiões. Para as equipas que pretendem HA de nível de produção sem os encargos operacionais, o Zilliz Cloud (Milvus gerido) fornece-o de imediato.

O Global Cluster é o principal recurso do Zilliz Cloud. Permite-lhe executar uma implementação Milvus que abrange várias regiões - América do Norte, Europa, Ásia-Pacífico, entre outras - como um único cluster lógico. Nos bastidores, utiliza a mesma tecnologia de replicação CDC/WAL descrita neste artigo, mas totalmente gerida:

Capacidade	CDC autogerenciado (este artigo)	Cluster global do Zilliz Cloud
Replicação	Você configura e monitora	Pipeline CDC automatizado e assíncrono
Failover	Manual de execução	Automatizado - sem alterações de código, sem actualizações de cadeias de ligação
Auto-recuperação	Você provisiona novamente o cluster com falha	Automático: detecta o estado obsoleto, reinicia e reconstrói como um novo secundário
Entre regiões	Implementa e gere ambos os clusters	Multi-região incorporada com acesso de leitura local
RPO	Segundos (depende da sua monitorização)	Segundos (não planeado) / Zero (comutação planeada)
RTO	Minutos (depende do seu livro de execução)	Minutos (automatizado)

Para além do Global Cluster, o plano Business Critical inclui funcionalidades adicionais de DR:

Recuperação Point-in-Time (PITR) - reverter uma coleção para qualquer momento dentro da janela de retenção, útil para recuperar de eliminações acidentais ou corrupção de dados replicados para o standby.
Backup entre regiões - replicação de backup automatizada e contínua para uma região de destino. A restauração para novos clusters leva minutos.
SLA de 99,99% de tempo de atividade - apoiado por uma implementação multi-AZ com várias réplicas.

Se estiver a executar a pesquisa vetorial na produção e a DR for um requisito, vale a pena avaliar o Zilliz Cloud juntamente com a abordagem Milvus autogerida. Contacte a equipa Zilliz para obter mais informações.

O que vem a seguir

Este artigo cobriu o cenário de HA para bancos de dados vetoriais e percorreu a criação de um par primário-em espera do zero. A seguir:

Parte 2: Adicionando CDC a um cluster Milvus existente que já possui dados, usando o Milvus Backup para semear o standby antes de ativar a replicação
Parte 3: Gerir o failover - promover o standby, redirecionar o tráfego e recuperar o primário original

Fique atento.

Se estiver a executar o Milvus em produção e a pensar na recuperação de desastres, gostaríamos de ajudar:

Junte-se à comunidade Milvus Slack para fazer perguntas, compartilhar sua arquitetura HA e aprender com outras equipes que executam o Milvus em escala.
Reserve uma sessão gratuita de 20 minutos do Milvus Office Hours para percorrer a sua configuração de DR - quer se trate da configuração do CDC, do planeamento de failover ou da implementação em várias regiões.
Se preferir ignorar a configuração da infraestrutura e saltar diretamente para a HA pronta para produção, o Zilliz Cloud (Milvus gerido) oferece alta disponibilidade entre regiões através da sua funcionalidade Global Cluster - sem necessidade de configuração manual do CDC.

Algumas perguntas que surgem quando as equipas começam a configurar a alta disponibilidade da base de dados de vectores:

P: O CDC torna o cluster primário mais lento?

Não. O nó CDC lê os registos WAL de forma assíncrona, independentemente do caminho de leitura/escrita. Ele não compete com consultas ou inserções por recursos no primário. Não verá uma diferença de desempenho com o CDC ativado.

P: O CDC pode replicar dados que existiam antes de ser ativado?

Não - o CDC só captura alterações a partir do momento em que é ativado. Para trazer os dados existentes para o standby, utilize o Milvus Backup para semear o standby primeiro e, em seguida, active o CDC para replicação contínua. A Parte 2 desta série aborda este fluxo de trabalho.

P: Ainda preciso do CDC se já tiver a multi-replicação activada?

Eles protegem contra diferentes modos de falha. A multi-replicação mantém cópias dos mesmos segmentos em nós dentro de um cluster - ótimo para falhas de nós, inútil quando todo o cluster desaparece (má implantação, interrupção do AZ, exclusão de namespace). O CDC mantém um cluster separado em um domínio de falha diferente com dados quase em tempo real. Para qualquer coisa além de um ambiente de desenvolvimento, você quer ambos.

P: Como o Milvus CDC se compara à replicação em outros bancos de dados vetoriais?

Atualmente, a maioria das bases de dados vectoriais oferece redundância ao nível dos nós (equivalente a multi-replicação), mas não oferece replicação ao nível do cluster. O Milvus é atualmente a única grande base de dados vetorial com replicação CDC baseada em WAL incorporada - o mesmo padrão comprovado que as bases de dados relacionais como o PostgreSQL e o MySQL utilizam há décadas. Se o failover entre clusters ou entre regiões for um requisito, este é um diferenciador significativo a avaliar.