Gestione dei 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 descrive i passaggi per eseguire un failover tra cluster.

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

Esegui un failover manuale

Utilizza un failover manuale se un profilo dell'app instrada tutte le richieste a un singolo cluster e quest'ultimo non risponde. Per esempi dei criteri che potresti utilizzare per determinare che un cluster non risponde, consulta Failover manuali. Controlla la latenza di replica dell'istanza prima di decidere di eseguire il failover. Per saperne di più, consulta Grafici per la replica.

Per eseguire un failover manuale, aggiorna il profilo dell'app in modo che indirizzi le richieste a un cluster reattivo anziché a quello che non risponde:

Console

  1. Nella console Google Cloud , apri l'elenco delle istanze Bigtable.

    Apri l'elenco delle istanze

  2. Nella colonna Profili applicazione, fai clic sul profilo dell'applicazione che instrada il traffico al cluster che non risponde.

    Se non vedi il profilo dell'app che vuoi modificare, puoi visualizzare un elenco completo facendo clic sul nome dell'istanza, quindi su Profili applicazione nel riquadro a sinistra.

  3. In Routing del cluster, seleziona un cluster reattivo nella tua istanza.

  4. Fai clic su Salva. Viene visualizzata una finestra di dialogo di conferma.

  5. Esamina attentamente gli avvisi nella finestra di dialogo di conferma, poi segui le istruzioni nella finestra di dialogo e fai clic su Continua.

gcloud

  1. Se non conosci l'ID istanza, utilizza il comando bigtable instances list per visualizzare un elenco delle istanze del progetto: 

    gcloud bigtable instances list

  2. Se non conosci gli ID cluster dell'istanza, utilizza il comando bigtable clusters list per visualizzare un elenco di cluster nell'istanza: 

    gcloud bigtable clusters list --instances=INSTANCE_ID

    Sostituisci INSTANCE_ID con l'identificatore permanente dell'istanza.

  3. Se non conosci l'ID del profilo dell'app, utilizza il comando bigtable app-profiles list per visualizzare un elenco dei profili dell'app dell'istanza: 

    gcloud bigtable app-profiles list --instance=INSTANCE_ID

    Sostituisci INSTANCE_ID con l'identificatore permanente dell'istanza.

  4. Utilizza il comando bigtable app-profiles update per modificare il cluster utilizzato dal profilo dell'app:

    gcloud bigtable app-profiles update APP_PROFILE_ID \
    --instance=INSTANCE_ID \
    --route-to=CLUSTER_ID

    Fornisci quanto segue:

    • APP_PROFILE_ID: L'identificatore permanente del profilo dell'app.
    • INSTANCE_ID: l'identificatore permanente dell'istanza
    • CLUSTER_ID: l'ID cluster a cui devono essere indirizzate tutte le richieste. Questo flag attiva il routing a un cluster singolo.

    Se ricevi un messaggio di errore, esamina attentamente gli avvisi contenuti nel messaggio. Se vuoi eseguire l'override dell'errore, esegui di nuovo il comando con il flag --force.

Poco dopo l'aggiornamento del profilo dell'app, tutte le applicazioni che utilizzano il profilo dell'app inizieranno a indirizzare tutte le richieste al cluster integro che hai selezionato. Il cluster non integro continuerà a utilizzare la CPU per gestire la replica e altre attività di manutenzione.

Una volta ripristinato il cluster non integro, puoi seguire gli stessi passaggi per aggiornare il profilo dell'app in modo che instradi tutte le richieste al cluster ripristinato.

Esegui un failover automatico

Con Bigtable, i failover automatici sono davvero automatici. Se il profilo di un'applicazione utilizza il routing multi-cluster e il cluster più vicino all'application server non è integro, non devi fare nulla. Bigtable esegue automaticamente il failover, anche se il cluster non è integro solo per un breve periodo di tempo, e utilizza il cluster integro più vicino per gestire le richieste fino al ripristino del cluster non integro.

La velocità di un failover automatico dipende dalla scadenza della richiesta. Scadenze più brevi attivano failover più rapidi, ma la scadenza deve comunque consentire un tempo sufficiente per il completamento della richiesta sul cluster di backup. Per saperne di più, consulta Failover automatici.

Per visualizzare il numero di richieste che sono state cambiate automaticamente di percorso in un determinato periodo di tempo, guarda il grafico Failover automatici nella consoleGoogle Cloud : apri l'elenco delle istanze, fai clic sul nome dell'istanza, quindi su Monitoraggio.

Passaggi successivi

Scopri come monitorare un'istanza Bigtable.