Commutazione

Lo switchover cambia la direzione primario-standby senza perdita di dati. Si usa quando il cluster primario attuale è ancora raggiungibile o quando è necessario spostare il traffico per la manutenzione.

Questa guida presuppone che la topologia corrente sia:

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

Dopo lo switchover, la topologia diventa:

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

Quando usare lo switchover

Usare lo switchover quando:

• Si sta eseguendo la manutenzione del primario corrente.
• Il primario è parzialmente degradato ma può ancora rispondere alle richieste.
• È necessario un RPO = 0 e non si può accettare una perdita di dati.

Non utilizzare lo switchover se il primario è completamente indisponibile. In tal caso, utilizzare il Failover.

Prima di iniziare

Prima di iniziare, verificare quanto segue:

• Entrambi i cluster sono raggiungibili.
• La replica CDC è sana.
• Il ritardo di CDC è sufficientemente basso per il tempo di ripristino desiderato.
• Le scritture delle applicazioni possono essere messe in pausa o ritentate durante il cambio di ruolo.
• È stata preparata la configurazione della nuova topologia.

Il passaggio al ruolo garantisce l'assenza di perdita di dati, ma il tempo di funzionamento dipende dalla quantità di dati ancora da replicare.

Creare la nuova topologia

Creare una configurazione di sostituzione completa in cui cluster-b diventa l'origine e cluster-a diventa la destinazione.

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

Applicare la nuova topologia

Applicare la stessa configurazione a entrambi i cluster. Inviare la richiesta prima al primario corrente e poi allo standby. Se in seguito si torna indietro, invertire l'ordine perché cluster-b è il primario corrente.

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

Il vecchio primario viene declassato a standby e rifiuta le nuove scritture. Il vecchio standby attende i dati replicati rimanenti, si promuove a primario e accetta le scritture.

Se la richiesta fallisce a causa di un errore transitorio di rete o di servizio, riprovare con la stessa configurazione.

Reindirizzare il traffico delle applicazioni

Dopo che cluster-b è diventato primario:

1. Indirizzare il traffico di scrittura su cluster-b.
2. Confermare che le letture e le scritture hanno successo su cluster-b.
3. Verificare che cluster-a non riceva più le scritture delle applicazioni.
4. Continuare a monitorare la replica da cluster-b a cluster-a.

Verifica del risultato

Verificare che cluster-b sia il nuovo primario e che i dati siano coerenti. I controlli più comuni includono:

• Confrontare i conteggi delle righe per le collezioni importanti.
• Eseguire una query sulle chiavi primarie note di entrambi i cluster.
• Eseguire una ricerca rappresentativa sul nuovo primario e sul vecchio standby.
• Eseguire una piccola scrittura su cluster-b e verificare che venga replicata su cluster-a.

Tornare indietro

Per tornare indietro in un secondo momento, applicare nuovamente la topologia originale:

cluster-a -> cluster-b

Utilizzare lo stesso flusso di switchover. Assicurarsi che il primario attuale sia raggiungibile e che la replica sia sana prima di tornare indietro.

DOMANDE FREQUENTI

Lo switchover fa perdere dati?

No. Lo switchover attende che i dati rimanenti siano replicati prima che lo standby diventi primario.

È necessario interrompere le scritture dell'applicazione?

Durante il cambio di ruolo è necessario sospendere le scritture o renderle ripetibili. Le scritture inviate al vecchio primario dopo il declassamento vengono rifiutate.

Perché lo switchover richiede più tempo del previsto?

Il motivo più comune è il ritardo del CDC. Il nuovo primario deve ricevere i dati rimanenti prima di poter subentrare con sicurezza con RPO = 0.

È possibile riprovare una richiesta di switchover fallita?

Sì. Riprovare con la stessa topologia di destinazione.

Cosa succede al vecchio primario?

Il vecchio primario diventa uno standby. Non dovrebbe più ricevere le scritture dell'applicazione.