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 Gestione dei failover.

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

Failover manuali

Se un profilo dell'applicazione 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 a un cluster diverso.

Ecco alcuni segnali 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 della risposta aumenta a un livello inaccettabile.

Poiché questi indicatori possono essere visualizzati per molti motivi diversi, il failover a un cluster diverso 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, vedi Completare un failover manuale.

Failover automatici

Se un profilo di un'app utilizza il routing multi-cluster, Bigtable gestisce i failover automaticamente. Quando il cluster più vicino non è in grado di gestire una richiesta, Bigtable indirizza 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 indirizza una richiesta a un cluster e questo cluster è 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 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 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 il routing multicluster per ottenere un'alta disponibilità (HA) per la tua applicazione, devi posizionare i server client o le VM in o vicino a più di una Google Cloud regione. Questo consiglio si applica anche se il server delle applicazioni non è ospitato da Google Cloud, perché i tuoi dati entrano nella rete Google Cloud tramite la regione Google Cloud più vicina al server delle applicazioni. Come qualsiasi richiesta, un failover viene completato più rapidamente su distanze più brevi.

Molti failover automatici sono così brevi che non te ne accorgerai. Puoi controllare il grafico Failover automatici nella console Google Cloud per visualizzare il numero di richieste reindirizzate automaticamente in un determinato periodo di tempo: apri l'elenco delle istanze, fai clic sul nome dell'istanza, quindi su Approfondimenti di sistema.

Passaggi successivi