Comutação

O Switchover altera a direção primária-em espera sem perda de dados. Utilize-o quando o cluster primário atual ainda estiver acessível ou quando precisar de mover o tráfego para manutenção.

Este guia assume que a topologia atual é:

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

Após o switchover, a topologia torna-se:

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

Quando usar o switchover

Use o switchover quando:

• Você está fazendo manutenção no primário atual.
• O primário está parcialmente degradado, mas ainda pode responder às solicitações.
• É necessário RPO = 0 e não é possível aceitar a perda de dados.

Não utilize o switchover se o primário estiver completamente indisponível. Nesse caso, use o Failover.

Antes de começar

Verifique o seguinte antes de começar:

• Ambos os clusters estão acessíveis.
• A replicação do CDC está íntegra.
• O atraso do CDC é baixo o suficiente para sua meta de tempo de recuperação.
• As gravações de aplicativos podem ser pausadas ou tentadas novamente durante a mudança de função.
• Você preparou a nova configuração de topologia.

A alternância não garante perda de dados, mas o tempo de operação depende da quantidade de dados que ainda precisam ser replicados.

Criar a nova topologia

Crie uma configuração de substituição completa em que cluster-b se torna a origem e cluster-a se torna o destino.

# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels

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

switchover_config = {
    "clusters": [
        {
            "cluster_id": cluster_a_id,
            "connection_param": {
                "uri": cluster_a_addr,
                "token": cluster_a_token,
            },
            "pchannels": cluster_a_pchannels,
        },
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": cluster_b_id,
            "target_cluster_id": cluster_a_id,
        }
    ],
}

Aplicar a nova topologia

Aplique a mesma configuração aos dois clusters. Envie a solicitação para o primário atual primeiro e, em seguida, envie-a para o standby. Se, mais tarde, você voltar, inverta a ordem, pois cluster-b é o primário atual.

from pymilvus import MilvusClient

client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_a.update_replicate_configuration(**switchover_config)
    client_b.update_replicate_configuration(**switchover_config)
finally:
    client_a.close()
    client_b.close()

O primário antigo é despromovido a standby e rejeita novas gravações. O standby antigo aguarda os dados replicados restantes, promove-se a primário e, em seguida, aceita gravações.

Se o pedido falhar devido a um erro transitório de rede ou de serviço, tente novamente com a mesma configuração.

Redirecionar o tráfego de aplicações

Depois que cluster-b se tornar primário:

1. Aponte o tráfego de gravação para cluster-b.
2. Confirme se as leituras e gravações são bem-sucedidas em cluster-b.
3. Confirme que cluster-a já não está a receber escritas de aplicações.
4. Continue a monitorizar a replicação de cluster-b para cluster-a.

Verificar o resultado

Verifique se cluster-b está servindo como o novo primário e se os dados permanecem consistentes. As verificações comuns incluem:

• Comparar a contagem de linhas para coleções importantes.
• Consultar chaves primárias conhecidas de ambos os clusters.
• Executar uma pesquisa representativa no novo primário e no antigo standby.
• Executar uma pequena gravação em cluster-b e confirmar que ela é replicada para cluster-a.

Voltar atrás

Para voltar a alternar mais tarde, aplique a topologia original novamente:

cluster-a -> cluster-b

Use o mesmo fluxo de comutação. Certifique-se de que o primário atual está acessível e que a replicação é saudável antes de voltar atrás.

PERGUNTAS FREQUENTES

O switchover perde dados?

Não. O switchover aguarda que os dados restantes sejam replicados antes que o standby se torne primário.

Preciso de parar as gravações da aplicação?

Você deve pausar as gravações ou fazer com que elas possam ser tentadas novamente durante a mudança de função. As gravações enviadas para o antigo primário depois de este ser despromovido são rejeitadas.

Por que é que a transição demora mais tempo do que o esperado?

A razão mais comum é o atraso do CDC. O novo primário deve receber os dados restantes antes de poder assumir o controlo com segurança com RPO = 0.

Posso tentar novamente um pedido de comutação falhado?

Sim. Tente novamente com a mesma topologia de destino.

O que acontece com o primário antigo?

O primário antigo torna-se um standby. Ele não deve mais receber gravações de aplicativos.