Failover

Se un cluster Bigtable smette di rispondere, 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 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 a scadere.
  • La latenza di risposta media aumenta a un livello inaccettabile.

Poiché questi indicatori possono comparire per molti motivi diversi, non è garantito che il passaggio a un altro cluster risolva il problema sottostante. 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, Bigtable riprova in genere 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 si avvicina la scadenza della richiesta, ma il cluster iniziale non ha inviato una risposta, Bigtable reindirizza la richiesta al cluster più vicino.

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 a cluster multipli per ottenere un'alta disponibilità (HA) per la tua applicazione, devi posizionare i server client o le VM in più di una regione Google Cloud o nelle 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 li noterai. 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