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 i cluster.
- Se un profilo dell'app instrada tutte le richieste a un singolo cluster, puoi eseguire un failover manuale.
- Se un profilo dell'app utilizza il routing multi-cluster, i failover sono automatici e non devi intraprendere alcuna azione.
Prima di leggere questa pagina, dovresti conoscere la panoramica della replica di Bigtable. Dovresti anche conoscere le opzioni di routing disponibili per Bigtable.
Eseguire un failover manuale
Utilizza un failover manuale se un profilo dell'app instrada tutte le richieste a un singolo cluster e questo cluster smette di rispondere. Per esempi dei criteri che potresti utilizzare per determinare che un cluster non risponde, vedi Failover manuali. Controlla la latenza di replica dell'istanza prima di decidere di eseguire il failover. Per ulteriori informazioni, vedi Grafici per la replica.
Per eseguire un failover manuale, aggiorna il profilo dell'app in modo che instradi le richieste a un cluster che risponde anziché al cluster che non risponde:
Console
Apri l'elenco delle istanze Bigtable nella Google Cloud console.
Nella colonna Profili dell'applicazione, fai clic sul profilo dell'app 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 dell'applicazione nel riquadro a sinistra.
In Routing dei cluster, seleziona un cluster che risponde nella tua istanza.
Fai clic su Salva. Viene visualizzata una finestra di dialogo di conferma.
Esamina attentamente gli avvisi nella finestra di dialogo di conferma, quindi segui le istruzioni nella finestra di dialogo e fai clic su Continua.
gcloud
Se non conosci l'ID istanza, utilizza il
bigtable instances listcomando per visualizzare un elenco delle istanze del progetto:gcloud bigtable instances listSe non conosci gli ID cluster dell'istanza, utilizza il
bigtable clusters listcomando per visualizzare un elenco dei cluster nell'istanza:gcloud bigtable clusters list --instances=INSTANCE_IDSostituisci
INSTANCE_IDcon l'identificatore permanente dell'istanza.Se non conosci l'ID del profilo dell'app, utilizza il
bigtable app-profiles listcomando per visualizzare un elenco dei profili dell'app dell'istanza:gcloud bigtable app-profiles list --instance=INSTANCE_IDSostituisci
INSTANCE_IDcon l'identificatore permanente dell'istanza.Utilizza il
bigtable app-profiles updatecomando per modificare il cluster utilizzato dal profilo dell'app:gcloud bigtable app-profiles update APP_PROFILE_ID \ --instance=INSTANCE_ID \ --route-to=CLUSTER_IDFornisci 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 instradate tutte le richieste. Questo flag abilita il routing a cluster singolo.
Se ricevi un messaggio di errore, esamina attentamente gli avvisi contenuti nel messaggio di errore. Se vuoi ignorare l'errore, esegui di nuovo il comando con il flag
--force.
Poco dopo aver aggiornato il profilo dell'app, tutte le applicazioni che utilizzano il profilo dell'app inizieranno a indirizzare tutte le richieste al cluster integro 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.
Eseguire un failover automatico
Con Bigtable, i failover automatici sono davvero automatici. Se un profilo dell'app utilizza il routing multi-cluster e il cluster più vicino al server delle applicazioni diventa non integro, non devi intraprendere alcuna azione. 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 finché il cluster non integro non viene ripristinato.
La velocità di un failover automatico dipende dalla scadenza della richiesta. Le scadenze più brevi attivano failover più rapidi, ma la scadenza deve comunque consentire alla richiesta di completarsi sul cluster di backup. Per ulteriori informazioni, vedi Failover automatici.
Per visualizzare il numero di richieste che sono state reinstradate automaticamente in un determinato periodo di tempo, consulta il grafico Failover automatici nella Google Cloud console: apri l'elenco delle istanze, fai clic sul nome dell'istanza, quindi fai clic su Monitoraggio.
Passaggi successivi
Scopri come monitorare un'istanza Bigtable.