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 automatica, a seconda del profilo dell'app e di un'applicazione che sta usando e come è configurato il profilo dell'app.

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

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

Failover manuali

Se il profilo di un'app utilizza il routing a cluster singolo per indirizzare tutte le richieste a un'unica devi usare il tuo giudizio per decidere quando iniziare il fallimento in un cluster diverso.

Ecco alcuni indicatori che potrebbero indicare che sarebbe utile eseguire il failover in un cluster diverso:

  • Il cluster inizia a restituire un numero elevato di errori di sistema temporanei.
  • 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 dell'istanza prima e dopo il failover per verificare le metriche sono migliorate.

Per maggiori dettagli su come completare un failover manuale, consulta la sezione Per completare una di failover.

Failover automatici

Se il profilo di un'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 un periodo di tempo. Ad esempio, se Bigtable instrada una richiesta a uno cluster e questo cluster è troppo lento per rispondere o restituisce un Bigtable in genere riprova a eseguire la richiesta su un altro in un cluster Kubernetes.

Se utilizzi il routing multi-cluster e invii una richiesta con una scadenza, Bigtable esegue automaticamente il failover quando necessario per soddisfare la scadenza del periodo di conservazione. 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 per gestire l'ultima operazione di scrittura Eventuali conflitti tra i dati che potrebbero verificarsi a seguito del failover prima della replica viene completata. 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 tuo server delle applicazioni non è ospitato da Google Cloud, i tuoi dati entrano nella rete Google Cloud attraverso la rete più vicina al tuo server delle applicazioni. Come per ogni richiesta, completa 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 di richieste che sono state automaticamente reinstradate in un determinato periodo di tempo: Apri l'elenco di istanze, fai clic sul nome dell'istanza e fai clic su Monitoring.

Passaggi successivi