Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Gérer les basculements
Lorsqu'un cluster Bigtable ne répond plus, la réplication permet au trafic entrant de basculer vers un autre cluster de la même instance. Le basculement peut s'effectuer manuellement ou automatiquement, en fonction du profil d'application utilisé et de sa configuration.
Cette page décrit les étapes à suivre pour effectuer un basculement entre clusters.
Lorsqu'un profil d'application achemine toutes les requêtes vers un seul cluster, vous pouvez effectuer un basculement manuel.
Si un profil d'application utilise un routage multicluster, les basculements sont automatiques et vous n'avez rien à faire.
Effectuez un basculement manuel lorsque le profil d'application achemine toutes les requêtes vers un seul cluster et que ce dernier est défectueux. Pour obtenir des exemples de critères permettant de déterminer si un cluster ne répond pas, consultez la section Basculements manuels. Vérifiez la latence de réplication de votre instance avant de décider de basculer. Pour en savoir plus, consultez la section Graphiques pour la réplication.
Pour effectuer un basculement manuel, mettez à jour votre profil d'application afin qu'il achemine les requêtes vers un cluster réactif, au lieu du cluster défectueux :
Console
Ouvrez la liste des instances Bigtable dans la console Google Cloud .
Dans la colonne Profils d'application, cliquez sur le profil d'application qui achemine le trafic vers le cluster défectueux.
Si vous ne voyez pas le profil d'application que vous souhaitez modifier, vous pouvez afficher une liste complète en cliquant sur le nom de l'instance, puis sur Profils d'application dans le volet gauche.
Sous Routage vers les clusters, sélectionnez un cluster réactif dans votre instance.
Cliquez sur Enregistrer. Une boîte de dialogue de confirmation s'affiche.
Lisez attentivement les avertissements dans la boîte de dialogue de confirmation, puis suivez les instructions et cliquez sur Continuer.
gcloud
Si vous ne connaissez pas l'ID d'instance, exécutez la commande bigtable instances
list pour afficher la liste des instances du projet :
gcloud bigtable instances list
Si vous ne connaissez pas les ID des clusters de l'instance, exécutez la commande bigtable clusters list pour afficher la liste des clusters de l'instance :
gcloud bigtable clusters list --instances=INSTANCE_ID
Remplacez INSTANCE_ID par l'identifiant permanent de l'instance.
Si vous ne connaissez pas l'ID du profil d'application, exécutez la commande bigtable app-profiles
list pour afficher la liste des profils d'application de l'instance :
gcloud bigtable app-profiles list --instance=INSTANCE_ID
Remplacez INSTANCE_ID par l'identifiant permanent de l'instance.
APP_PROFILE_ID : identifiant permanent du profil d'application.
INSTANCE_ID : identifiant permanent de l'instance.
CLUSTER_ID : ID du cluster vers lequel toutes les demandes doivent être acheminées. Cette option active le routage vers un seul cluster.
Si vous recevez un message d'erreur, examinez attentivement les avertissements qu'il contient. Si vous souhaitez annuler l'erreur, exécutez à nouveau la commande avec l'option --force.
Peu après la mise à jour du profil d'application, toutes les applications utilisant ce profil achemineront l'ensemble de leurs requêtes vers le cluster opérationnel qui a été sélectionné. Le cluster défaillant continuera à utiliser le processeur pour gérer la réplication et d'autres tâches de maintenance.
Une fois le cluster défaillant récupéré, vous pouvez suivre les mêmes étapes pour mettre à jour votre profil d'application afin qu'il achemine toutes les demandes vers le cluster récupéré.
Effectuer un basculement automatique
Avec Bigtable, les basculements automatiques sont entièrement automatisés. Si un profil d'application utilise un routage multicluster et que le cluster le plus proche du serveur d'applications devient non opérationnel, vous ne devez effectuer aucune action.
Même lorsque l'état d'un cluster n'est que brièvement non opérationnel, Bigtable effectue automatiquement le basculement et se sert du cluster opérationnel le plus proche pour gérer les requêtes jusqu'à ce que le cluster non opérationnel soit rétabli.
Pour afficher le nombre de requêtes qui ont été réacheminées automatiquement sur une période donnée, consultez le graphique de Basculements automatiques dans la consoleGoogle Cloud . Accédez à la liste des instances, cliquez sur le nom de l'instance, puis sur Surveillance.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
