Failover

Se un cluster Bigtable non risponde, la replica consente il failover del traffico in entrata su un altro cluster nella stessa istanza. I failover possono essere manuali o automatici, a seconda del profilo dell'app usato da un'applicazione e della configurazione del profilo stesso.

Questa pagina spiega come funzionano i failover manuali e automatici in un'istanza che utilizza la replica. Per scoprire come completare un failover, consulta Gestione dei failover.

Prima di leggere questa pagina, dovresti acquisire familiarità con la panoramica sulla replica di Bigtable. Dovresti anche conoscere le opzioni di percorso disponibili.

Failover manuali

Se un profilo di app utilizza il routing a cluster singolo per indirizzare tutte le richieste a un cluster, devi valutare autonomamente quando iniziare a eseguire il failover su un cluster diverso.

Di seguito sono riportati alcuni indicatori che potrebbero indicare che sarebbe utile eseguire il failover su un cluster diverso:

  • Il cluster inizia a restituire un numero elevato di errori di sistema temporanei.
  • Inizia il timeout di un numero elevato di richieste.
  • La latenza media della risposta aumenta a un livello inaccettabile.

Poiché questi indicatori possono apparire per molti motivi diversi, non è garantita la risoluzione del problema di fondo in un cluster diverso. Monitora l'istanza prima e dopo il failover per verificare che le metriche siano migliorate.

Per maggiori dettagli su come completare un failover manuale, consulta Completamento di un failover manuale.

Failover automatici

Se un profilo dell'app utilizza il routing multi-cluster, Bigtable gestisce automaticamente i failover. Se il cluster più vicino non è in grado di gestire una richiesta, Bigtable instrada il traffico al cluster più vicino disponibile.

I failover automatici possono verificarsi anche se un cluster non è disponibile per un periodo di tempo molto breve. Ad esempio, se Bigtable instrada una richiesta a un cluster e quest'ultimo è eccessivamente lento a rispondere o restituisce un errore temporaneo, Bigtable in genere riprova a inviare la richiesta su un altro cluster.

Se utilizzi il routing multi-cluster e invii una richiesta con una scadenza, Bigtable esegue automaticamente il failover quando necessario per rispettare la scadenza. Se la scadenza della richiesta si avvicina, ma il cluster iniziale non ha inviato una risposta, Bigtable reindirizza la richiesta al cluster più vicino successivo.

Bigtable utilizza un algoritmo interno per l'ultima scrittura vince per gestire eventuali conflitti di dati che potrebbero verificarsi come risultato del failover prima del completamento della replica. Per ulteriori dettagli, consulta Risoluzione dei conflitti.

Se utilizzi la replica con il routing multi-cluster per ottenere un'alta disponibilità (HA) per la tua applicazione, devi individuare i tuoi server client o VM in più regioni di Google Cloud o nelle loro vicinanze. Questo suggerimento si applica anche se il server delle applicazioni non è ospitato da Google Cloud, perché i dati entrano nella rete Google Cloud tramite l'area geografica Google Cloud più vicina al server delle applicazioni. Come per qualsiasi richiesta, un failover viene completato più rapidamente su distanze più brevi.

Molti failover automatici sono talmente brevi che non te ne accorgerai. Puoi controllare il grafico Failover automatici nella console Google Cloud per vedere il numero di richieste dirottate automaticamente in un determinato periodo di tempo: apri l'elenco di istanze, fai clic sul nome dell'istanza e poi su Monitoring.

Passaggi successivi