Transferência em caso de falha

O Failover promove um cluster em espera para um primário autónomo quando o primário original está completamente indisponível. É uma operação que prioriza a disponibilidade e pode perder dados que não foram replicados antes da falha.

Este guia pressupõe que a topologia original é:

cluster-a (primary)  ->  cluster-b (standby)

Após o failover, cluster-b torna-se um primário autónomo:

cluster-b (primary)

Quando usar o failover

Use o failover somente quando:

• O primário original não puder responder às solicitações.
• O primário não pode ser recuperado dentro de um tempo aceitável.
• A restauração da disponibilidade de gravação é mais importante do que esperar pelo primário antigo.

Se o primário ainda estiver acessível, use o Switchover. O Switchover evita a perda de dados.

Risco de perda de dados

O Failover não espera pelo primário original. Quaisquer dados gravados no primário antigo, mas ainda não replicados para o standby, podem ser perdidos.

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

Antes de executar o failover, entenda a compensação:

Objetivo	Comutação	Transferência em caso de falha
Restaurar gravações enquanto o primário está inacessível	Não	Sim
Evitar a perda de dados	Sim	Não garantido
Requer que o primário antigo responda	Sim	Não

Antes de começar

Confirme o seguinte:

• O primário original não está disponível.
• Você decidiu não esperar pela recuperação do primário.
• O tráfego de aplicações pode ser redireccionado para o standby.
• A automação de tráfego não enviará gravações de volta para o primário antigo se ele se recuperar.
• Você tem o ID do cluster em espera, o endereço, o token e os canais p.

O requisito de segurança mais importante é evitar o split brain. Após o failover, apenas o standby promovido deve aceitar gravações de aplicativos.

Criar a configuração de failover

Crie uma configuração que contenha apenas o cluster em espera e nenhuma topologia de replicação. Defina force_promote=True.

# If you followed Set Up CDC Replication, cluster B is the original target cluster.
cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

failover_config = {
    "clusters": [
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        }
    ],
    "cross_cluster_topology": [],
    "force_promote": True,
}

Promover o standby

Envie a solicitação para o cluster em espera.

from pymilvus import MilvusClient

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.update_replicate_configuration(**failover_config)
finally:
    client_b.close()

Se a solicitação for bem-sucedida, cluster-b se tornará um primário autônomo e poderá aceitar gravações.

Redirecionar o tráfego de aplicações

Após a promoção:

1. Redirecionar o tráfego de escrita para cluster-b.
2. Remova cluster-a dos pontos de extremidade de escrita, balanceadores de carga, registos DNS e automação.
3. Verifique se cluster-b aceita gravações.
4. Mantenha o cluster-a isolado até ser desativado ou explicitamente reconstruído.

Exemplo de verificação de escrita:

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.insert(
        collection_name="test_collection",
        data=[{"id": 1, "vector": [0.1] * 128}],
    )
finally:
    client_b.close()

Ajuste o nome da coleção e os campos do esquema para corresponder à sua implementação.

Verificar o resultado

Verifique diretamente o cluster promovido:

• As gravações são bem-sucedidas em cluster-b.
• As leituras retornam os dados esperados.
• Nenhum componente de aplicativo grava em cluster-a.

Manipulando o antigo primário

Após o failover, trate o cluster-a como obsoleto. Não envie gravações de aplicações para ele se ele se tornar acessível novamente. Ele pode conter dados que nunca foram replicados para cluster-b, e cluster-b pode já conter novas gravações após o failover.

Não reconecte cluster-a à topologia antiga automaticamente. A reintrodução do antigo primário é uma tarefa de recuperação separada que deve ser planeada cuidadosamente.

Minimização da perda de dados

Não é possível remover todos os riscos de perda de dados do failover, mas é possível reduzi-los:

• Monitorizar continuamente o atraso do CDC.
• Manter os clusters em espera provisionados para lidar com a taxa de gravação primária.
• Manter baixa a latência da rede entre clusters e a perda de pacotes.
• Tornar as gravações de aplicativos idempotentes.
• Repetir as gravações cujo sucesso é incerto após o failover.
• Preferir a transição sempre que o primário ainda puder responder.

PERGUNTAS FREQUENTES

O failover sempre perde dados?

Não, mas pode acontecer. Se todas as gravações já foram replicadas antes da falha do primário, nenhum dado é perdido. Se existir um atraso de CDC, os dados atrasados podem perder-se.

Quanto tempo é que a ativação pós-falha demora?

Normalmente, é concluído em segundos, dependendo do estado do cluster e da disponibilidade do plano de controlo no standby.

Posso executar o failover no primário?

Não. O failover destina-se a um cluster em espera. Se o primário atual estiver disponível, utilize o switchover.

O primário antigo pode voltar a juntar-se automaticamente?

Não. Após a ativação pós-falha, o primário antigo tem de ser tratado como obsoleto e desativado ou reconstruído antes de poder voltar a participar na replicação.

Como é que evito o split brain?

Certifique-se de que apenas o cluster promovido recebe gravações. Remova o primário antigo de todos os caminhos de gravação antes que ele possa se recuperar e aceitar tráfego.