Milvus CDC

O Milvus CDC (Change Data Capture) replica as alterações de dados de um cluster Milvus para outro. É possível usar o CDC para criar uma topologia de recuperação de desastres primária-em espera para o Milvus.

Numa topologia primária-em espera, um cluster actua como primário e aceita gravações. Um ou mais clusters em espera recebem continuamente alterações do primário e podem servir o tráfego de leitura. Quando o cluster primário fica indisponível ou precisa de manutenção, é possível mudar o tráfego de serviço para um cluster em espera.

Arquitetura

Uma topologia típica contém:

• Cluster primário: O cluster de origem para replicação. Ele aceita leituras e gravações.
• Cluster em espera: Um cluster de destino para replicação. Recebe alterações do primário e é apenas de leitura enquanto permanece em espera.
• Nó CDC: Um componente Milvus que encaminha as alterações WAL do cluster primário atual para os clusters em espera. Implante o CDC em cada cluster que pode se tornar primário após a troca ou failover.
• Topologia de replicação: A relação configurada entre origem e destino, como cluster-a -> cluster-b. A seguir, uma ilustração da topologia. Fluxo de trabalho do CDC

Topologias suportadas

A implementação mais comum do CDC é um primário e um standby:

Application writes
      |
      v
Primary cluster A  -- CDC replication -->  Standby cluster B

O Milvus CDC também suporta uma topologia com uma única primária e várias em espera:

Primary cluster A  -- CDC replication -->  Standby cluster B
                  \-- CDC replication -->  Standby cluster C

O Milvus CDC não suporta implementações multi-primárias ou ativo-ativo, onde dois ou mais clusters aceitam tráfego de escrita ao mesmo tempo.

Comportamento primário e em espera

Função	Leituras	Escritas	Comportamento de replicação
Primário	Sim	Sim	Envia alterações para clusters em espera
Em espera	Sim	Não	Recebe alterações replicadas do primário

Um cluster em espera rejeita pedidos de escrita direta. Isso evita o split brain e mantém a topologia de replicação consistente.

Comutação planeada vs. Failover

O Milvus CDC fornece duas formas de mover o tráfego de serviço do atual cluster primário para um cluster em espera.

Operação	Usar quando	Perda de dados	Comportamento esperado
Comutação	O primário atual ainda está acessível ou está a ser feita uma manutenção planeada	RPO = 0	Aguarda os dados replicados restantes antes de mudar de função
Transferência em caso de falha	O primário atual não está disponível e não pode ser recuperado rapidamente	Possível	Promove o standby imediatamente para que as gravações possam ser retomadas

Use o switchover sempre que o primário atual ainda puder responder. Use o failover somente quando a restauração da disponibilidade for mais importante do que esperar pelo primário original.

Atraso do CDC e por que ele é importante

O atraso do CDC é a quantidade de dados que foi gravada no cluster primário, mas que ainda não foi aplicada a um cluster em espera.

O atraso do CDC afeta as duas opções de recuperação:

• Durante o switchover, um atraso menor do CDC geralmente significa que a operação é concluída mais rapidamente.
• Durante o failover, o atraso do CDC representa a janela de dados que pode ser perdida se o primário original não estiver disponível.

Você deve monitorar o atraso do CDC continuamente e mantê-lo o mais baixo possível. A página Configurar replicação do CDC inclui um exemplo do PromQL para estimar o atraso do CDC.

Limitações

Atualmente, o Milvus CDC tem os seguintes limites:

• Suporta apenas topologias primárias simples.
• Não suporta gravações activas-activas ou multi-primárias.
• Os clusters em espera podem servir o tráfego de leitura, mas rejeitam as escritas diretas enquanto permanecerem em espera.
• O failover pode perder dados que foram gravados no antigo primário, mas que ainda não foram replicados para o standby.
• O pchannels configurado deve corresponder ao layout real do canal de cada cluster.

PERGUNTAS FREQUENTES

Um cluster em espera pode servir consultas?

Sim. Um cluster em espera pode servir tráfego de leitura. Ele não pode aceitar gravações até que se torne o primário.

O Milvus CDC suporta gravações ativo-ativo?

Não. O Milvus CDC foi concebido para uma topologia primária única. Escrever em vários clusters ao mesmo tempo pode causar split brain e divergência de dados.

O switchover perde dados?

Não. A alternância aguarda que os dados restantes sejam replicados antes que o standby se torne primário.

O failover perde dados?

Pode. Quaisquer dados gravados no antigo primário, mas ainda não replicados no standby, podem perder-se.

Que quantidade de dados pode ser perdida durante a ativação pós-falha?

A potencial perda de dados é limitada pelo atraso do CDC no momento em que o primário ficou indisponível.