Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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.
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 di criteri che puoi 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 ulteriori informazioni, 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 non reattivo:
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 e poi su Profili delle applicazioni nel riquadro a sinistra.
In Routing cluster, seleziona un cluster adattabile 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, poi segui le istruzioni riportate nella finestra di dialogo e fai clic su Continua.
gcloud
Se non conosci l'ID istanza, utilizza il
comando bigtable instances
list per visualizzare un elenco delle istanze del progetto:
gcloud bigtable instances list
Se non conosci gli ID cluster dell'istanza, utilizza il
bigtable clusters list
comando per visualizzare un elenco di cluster nell'istanza:
gcloud bigtable clusters list --instances=INSTANCE_ID
Sostituisci INSTANCE_ID con l'identificatore permanente dell'istanza.
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.
CLUSTER_ID:
l'ID cluster a cui devono essere inoltrate tutte le richieste. Questo flag attiva il routing a un cluster singolo.
Se ricevi un messaggio di errore, esamina attentamente gli avvisi al suo interno. 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 lo utilizzano inizieranno a indirizzare tutte le richieste al cluster funzionante selezionato. Il cluster non in stato normale continuerà a utilizzare la CPU per gestire la replica e altre attività di manutenzione.
Una volta recuperato il cluster non funzionante, puoi seguire gli stessi passaggi per aggiornare il profilo dell'app in modo che indirizzi tutte le richieste al cluster recuperato.
Esegui un failover automatico
Con Bigtable, i failover automatici sono davvero automatici. Se il profilo di un'app utilizza il routing multi-cluster e il cluster più vicino al server dell'applicazione diventa non disponibile, non devi intraprendere alcuna azione.
Bigtable esegue automaticamente il failover, anche se il cluster è solo brevemente non funzionante, e utilizza il cluster funzionante più vicino per gestire le richieste fino al recupero del cluster non funzionante.
Per visualizzare il numero di richieste reindirizzate automaticamente in un determinato periodo di tempo, esamina il grafico Failover automatici nella consoleGoogle Cloud : apri l'elenco di istanze, fai clic sul nome dell'istanza e poi su Monitoraggio.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eBigtable replication enables traffic failover to another cluster if one becomes unresponsive, either manually or automatically.\u003c/p\u003e\n"],["\u003cp\u003eManual failovers are required when an app profile routes all requests to a single cluster, and involve updating the app profile to direct traffic to a responsive cluster.\u003c/p\u003e\n"],["\u003cp\u003eAutomatic failovers occur when an app profile uses multi-cluster routing, where Bigtable automatically reroutes traffic to the nearest healthy cluster.\u003c/p\u003e\n"],["\u003cp\u003eTo perform a manual failover, one must use the Google Cloud console or the gcloud command-line tool to update the app profile and select a healthy cluster.\u003c/p\u003e\n"],["\u003cp\u003eThe number of requests automatically rerouted can be monitored using the "Automatic Failovers" graph in the Google Cloud console under instance monitoring.\u003c/p\u003e\n"]]],[],null,["Manage failovers\n\n\nIf a Bigtable cluster becomes unresponsive, replication makes it possible for incoming\ntraffic to fail over to another cluster in the same instance. Failovers can be either manual or\nautomatic, depending on the [app profile](/bigtable/docs/app-profiles) an application\nis using and how the app profile is configured.\n\nThis page describes the steps for performing a failover between clusters.\n\n- If an app profile routes all requests to a single cluster, you can [perform a\n manual failover](#manual).\n- If an app profile uses multi-cluster routing, [failovers are\n automatic](#automatic) and you don't need to take any action.\n\n\nBefore you read this page, you should be familiar with the\n[overview of Bigtable replication](/bigtable/docs/replication-overview).\nYou should also be familiar with the\n[routing options](/bigtable/docs/routing) that are available for\nBigtable.\n\nPerform a manual failover\n\nUse a manual failover if an app profile routes all requests to a single cluster\nand that cluster becomes unresponsive. For examples of the criteria you could\nuse to determine that a cluster is unresponsive, see\n[Manual failovers](/bigtable/docs/failovers#manual). Check your instance's replication latency\nbefore you decide to fail over. For more information, see [Charts for\nreplication](/bigtable/docs/monitoring-instance).\n\nTo perform a manual failover, update your app profile so that it routes requests\nto a responsive cluster instead of the unresponsive cluster: \n\nConsole\n\n1.\n Open the list of Bigtable instances in the Google Cloud console.\n\n\n [Open the instance list](https://console.cloud.google.com/bigtable/instances)\n2. In the **Application profiles** column, click the app profile that is\n routing traffic to the unresponsive cluster.\n\n If you don't see the app profile you want to edit, you can view a\n complete list by clicking the name of the instance, then clicking\n **Application profiles** in the left pane.\n3. Under **Cluster routing**, select a responsive cluster in your instance.\n\n | **Important:** If **Any cluster (multi-cluster)** is selected, the app profile handles failovers automatically. Click **Cancel** to exit without saving.\n4. Click **Save**. A confirmation dialog appears.\n\n5. Carefully review the warnings in the confirmation dialog, then follow\n the instructions in the dialog and click **Continue**.\n\ngcloud\n\n1.\n If you don't know the instance ID, use the\n [`bigtable instances\n list` command](/sdk/gcloud/reference/bigtable/instances/list) to view a list of your project's instances:\n\n gcloud bigtable instances list\n\n2.\n If you don't know the instance's cluster IDs, use the\n [`bigtable clusters list`\n command](/sdk/gcloud/reference/bigtable/clusters/list) to view a list of clusters in the instance:\n\n gcloud bigtable clusters list --instances=\u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e\n\n\n Replace \u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e with the permanent identifier for the instance.\n3.\n If you don't know the app profile's ID, use the\n [`bigtable app-profiles\n list` command](/sdk/gcloud/reference/bigtable/app-profiles/list) to view a list of the instance's app profiles:\n\n gcloud bigtable app-profiles list --instance=\u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e\n\n\n Replace \u003cvar translate=\"no\"\u003eINSTANCE_ID\u003c/var\u003e with the permanent identifier for the instance.\n4. Use the [`bigtable app-profiles update` command](/sdk/gcloud/reference/bigtable/app-profiles/update) to\n change the cluster that the app profile uses:\n\n gcloud bigtable app-profiles update APP_PROFILE_ID \\\n --instance=INSTANCE_ID \\\n --route-to=CLUSTER_ID\n\n\n Provide the following:\n - `APP_PROFILE_ID`: The permanent identifier for the app profile.\n - `INSTANCE_ID`: The permanent identifier for the instance.\n - `CLUSTER_ID`: The cluster ID that all requests should be routed to. This flag enables [single-cluster routing](/bigtable/docs/routing#single-cluster).\n\n If you receive an error message, carefully review any warnings in the\n error message. If you want to override the error, run the command again\n with the `--force` flag.\n\nShortly after you update the app profile, any applications that use the app\nprofile will start to direct all of their requests to the healthy cluster that\nyou selected. The unhealthy cluster will continue using CPU to handle\nreplication and other maintenance tasks.\n\nAfter the unhealthy cluster recovers, you can follow the same steps to update\nyour app profile so that it routes all requests to the recovered cluster.\n\nPerform an automatic failover\n\nWith Bigtable, automatic failovers truly are automatic. If an app\nprofile uses multi-cluster routing, and the nearest cluster to the application\nserver becomes unhealthy, you don't need to take any action.\nBigtable automatically fails over, even if the cluster is only\nbriefly unhealthy, and uses the nearest healthy cluster to handle requests until\nthe unhealthy cluster has recovered.\n\nTo view the number of requests that were automatically rerouted over a given\nperiod of time, look at the **Automatic Failovers** graph in the\nGoogle Cloud console: open the [list of instances](https://console.cloud.google.com/bigtable/instances), click\nthe instance name, then click **Monitoring**.\n\nWhat's next\n\nLearn how to [monitor a Bigtable instance](/bigtable/docs/monitoring-instance)."]]
