Failover

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

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

Prima di leggere questa pagina, devi conoscere la panoramica della replica di Bigtable. Dovresti anche conoscere le opzioni di routing disponibili.

Failover manuali

Se un profilo dell'app utilizza il routing a cluster singolo per indirizzare tutte le richieste a un singolo cluster, devi decidere in base alla tua discrezione quando avviare il failover a un altro cluster.

Ecco alcuni indicatori che potrebbero indicare che sarebbe utile eseguire il failover su un altro cluster:

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

Poiché questi indicatori possono apparire per molti motivi diversi, il fallimento in una non è garantito che il problema di fondo venga risolto da un cluster diverso. Monitora la tua istanza prima e dopo il failover per verificare che le metriche siano migliorate.

Per informazioni dettagliate su come completare un failover manuale, consulta Completare un failover manuale.

Failover automatici

Se un profilo dell'app utilizza il routing multi-cluster, Bigtable gestisce automaticamente i failover. Quando 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 breve periodo di tempo. Ad esempio, se Bigtable inoltra una richiesta a un cluster e questo cluster risponde in modo eccessivamente lento o restituisce un errore transitorio, in genere Bigtable 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 aiutarti a rispettare la scadenza. Se la scadenza della richiesta si avvicina, ma il cluster iniziale non ha ha inviato una risposta, Bigtable reindirizza la richiesta all'istanza in un cluster Kubernetes.

Bigtable utilizza un algoritmo interno last write wins per gestire eventuali conflitti di dati che potrebbero verificarsi a seguito del failover prima del completamento della replica. Per ulteriori dettagli, consulta la sezione Risoluzione dei conflitti.

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

Molti failover automatici sono così brevi che non vengono notati. Puoi controllare il grafico Failover automatici nella console Google Cloud per vedere il numero di richieste reindirizzate automaticamente in un determinato periodo di tempo: apri l'elenco di istanze, fai clic sul nome dell'istanza e poi su Monitoraggio.

Passaggi successivi