Failover

Il failover promuove un cluster standby a un primario autonomo quando il primario originale è completamente indisponibile. È un'operazione che privilegia la disponibilità e può comportare la perdita di dati non replicati prima del guasto.

Questa guida presuppone la topologia originale:

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

Dopo il failover, cluster-b diventa un primario autonomo:

cluster-b (primary)

Quando usare il failover

Utilizzare il failover solo quando:

• Il primario originale non può rispondere alle richieste.
• Il primario non può essere ripristinato entro un tempo accettabile.
• Il ripristino della disponibilità di scrittura è più importante dell'attesa del vecchio primario.

Se il primario è ancora raggiungibile, utilizzare lo switchover. Lo switchover evita la perdita di dati.

Rischio di perdita di dati

Il Failover non attende il primario originale. Tutti i dati scritti sul vecchio primario ma non ancora replicati sullo standby possono andare persi.

La possibile perdita di dati è determinata dal ritardo del CDC nel momento in cui il primario è diventato non disponibile.

Prima di eseguire il failover, è necessario comprendere il compromesso:

Obiettivo	Commutazione	Failover
Ripristinare le scritture mentre il primario non è raggiungibile	No	Sì
Evitare la perdita di dati	Sì	Non garantito
Richiede la risposta del vecchio primario	Sì	No

Prima di iniziare

Confermare quanto segue:

• Il primario originale non è disponibile.
• Si è deciso di non attendere il ripristino del primario.
• Il traffico delle applicazioni può essere reindirizzato allo standby.
• L'automazione del traffico non invierà le scritture al vecchio primario se questo si ripristina.
• Si dispone dell'ID, dell'indirizzo, del token e dei pchannels del cluster standby.

Il requisito di sicurezza più importante è evitare lo split brain. Dopo il failover, solo lo standby promosso deve accettare le scritture delle applicazioni.

Creare la configurazione di failover

Creare una configurazione che contenga solo il cluster standby e nessuna topologia di replica. Impostare 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,
}

Promuovere lo standby

Inviare la richiesta al cluster standby.

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 la richiesta ha successo, cluster-b diventa un primario autonomo e può accettare scritture.

Reindirizzare il traffico delle applicazioni

Dopo la promozione:

1. Reindirizzare il traffico di scrittura su cluster-b.
2. Rimuovere cluster-a dagli endpoint di scrittura, dai bilanciatori di carico, dai record DNS e dall'automazione.
3. Verificare che cluster-b accetti le scritture.
4. Mantenere cluster-a isolato finché non viene dismesso o ricostruito esplicitamente.

Esempio di verifica della scrittura:

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

Regolare i campi del nome della raccolta e dello schema per adattarli alla propria distribuzione.

Verifica del risultato

Verificare direttamente il cluster promosso:

• Le scritture hanno successo su cluster-b.
• Le letture restituiscono i dati attesi.
• Nessun componente dell'applicazione scrive su cluster-a.

Gestione del vecchio primario

Dopo il failover, trattare cluster-a come stantio. Non inviare le scritture delle applicazioni a se diventa nuovamente raggiungibile. Potrebbe contenere dati che non sono mai stati replicati su cluster-b e cluster-b potrebbe già contenere nuove scritture dopo il failover.

Non ricollegare automaticamente cluster-a alla vecchia topologia. La reintroduzione del vecchio primario è un'attività di ripristino separata che deve essere pianificata con attenzione.

Ridurre al minimo la perdita di dati

Non è possibile eliminare tutti i rischi di perdita di dati dal failover, ma è possibile ridurli:

• Monitorare costantemente il ritardo del CDC.
• Mantenere i cluster di standby in grado di gestire la velocità di scrittura del primario.
• Mantenere bassa la latenza della rete tra cluster e la perdita di pacchetti.
• Rendere le scritture delle applicazioni idempotenti.
• Riprovare le scritture il cui successo è incerto dopo il failover.
• Preferire la commutazione quando il primario può ancora rispondere.

DOMANDE FREQUENTI

Il failover perde sempre i dati?

No, ma è possibile. Se tutte le scritture erano già state replicate prima del guasto del primario, non si perdono dati. Se esisteva un ritardo CDC, i dati in ritardo possono andare persi.

Quanto tempo impiega il failover?

In genere si completa in pochi secondi, a seconda dello stato del cluster e della disponibilità del control-plane sullo standby.

È possibile eseguire il failover sul primario?

No. Il failover è destinato a un cluster in standby. Se il primario attuale è disponibile, utilizzare lo switchover.

Il vecchio primario può ricongiungersi automaticamente?

No. Dopo il failover, il vecchio primario deve essere trattato come stale e disattivato o ricostruito prima di poter partecipare nuovamente alla replica.

Come si evita lo split brain?

Assicurarsi che solo il cluster promosso riceva scritture. Rimuovere il vecchio primario da tutti i percorsi di scrittura prima che possa recuperare e accettare il traffico.