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 cluster, devi utilizzare il tuo giudizio per decidere quando avviare il failover su 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 temporanei.
  • Un numero elevato di richieste inizia a scadere.
  • La latenza media delle risposte aumenta a un livello inaccettabile.

Poiché questi indicatori possono essere visualizzati per molti motivi diversi, il failover su un altro cluster non garantisce la risoluzione del problema sottostante. Monitora l'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 disponibile più vicino.

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 questo è eccessivamente lento a rispondere o restituisce un errore temporaneo, Bigtable in genere riprova 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 si avvicina e il cluster iniziale non ha inviato una risposta, Bigtable instrada la richiesta al cluster più vicino successivo. La scadenza impostata influisce sulla velocità con cui si verifica questa operazione: una scadenza più breve attiva un failover precedente, mentre una scadenza più lunga consente di avere più tempo prima del failover.

Assicurati che la scadenza sia sufficientemente lunga da consentire il completamento della richiesta di failover su un cluster successivo, soprattutto se il cluster successivo si trova in un'altra regione.

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 maggiori dettagli, consulta Risoluzione dei conflitti.

Se utilizzi la replica con il routing multi-cluster per ottenere la disponibilità elevata (HA) per la tua applicazione, devi individuare i server o le VM in o vicino a più Google Cloud regioni. Questa raccomandazione si applica anche se il server dell'applicazione non è ospitato da Google Cloud, perché i dati entrano nella Google Cloud rete tramite la Google Cloud regione più vicina al server dell'applicazione. 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 Google Cloud console per visualizzare il numero di richieste che sono state instradate automaticamente in un determinato periodo di tempo: apri l'elenco delle istanze, fai clic sul nome dell'istanza, quindi fai clic su Informazioni sul sistema.

Passaggi successivi