如果您搭配使用复制功能和多集群路由来实现应用的高可用性 (HA),则应将客户端服务器或虚拟机放置在多个 Google Cloud 区域内或这些区域附近。即使您的应用服务器不是由 Google Cloud托管,这项建议也适用,因为您的数据会通过距离应用服务器最近的 Google Cloud区域进入 Google Cloud 网络。与任何请求一样,距离越短,故障切换的完成速度就越快。
自动故障转移过程通常非常简短,以至于您无法察觉。您可以在 Google Cloud 控制台中查看自动故障切换图表,以便了解在指定时间段内自动重新路由的请求数,方法如下:打开实例列表,点击实例名称,然后点击系统数据分析。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-27。"],[[["\u003cp\u003eReplication enables traffic failover to another cluster within the same instance if a Bigtable cluster becomes unresponsive, and these failovers can be manual or automatic.\u003c/p\u003e\n"],["\u003cp\u003eManual failovers, used with single-cluster routing, require user judgment based on signals like increased errors, timeouts, or latency, but are not guaranteed to resolve issues, so monitoring is recommended.\u003c/p\u003e\n"],["\u003cp\u003eAutomatic failovers, utilized with multi-cluster routing, are handled by Bigtable, routing traffic to an available cluster when the nearest one is unable to process a request, and also apply to deadline requests.\u003c/p\u003e\n"],["\u003cp\u003eDuring failovers, Bigtable uses a \u003cem\u003elast write wins\u003c/em\u003e algorithm to resolve data conflicts that might occur before replication is completed.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal performance in a multi-cluster routing environment, client servers or VMs should be located near or within multiple Google Cloud regions to ensure faster failovers.\u003c/p\u003e\n"]]],[],null,["# Failovers\n=========\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 explains how manual and automatic failovers work in an instance that\nuses replication.\nTo learn how to complete a failover, see [Managing\nfailovers](/bigtable/docs/managing-failovers).\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\navailable [routing options](/bigtable/docs/routing).\n\nManual failovers\n----------------\n\nIf an app profile uses single-cluster routing to direct all requests to one\ncluster, you must use your own judgement to decide when to start failing over\nto a different cluster.\n\nHere are some signals that might indicate that it would be helpful to fail over\nto a different cluster:\n\n- The cluster starts to return a large number of transient system errors.\n- A large number of requests start timing out.\n- The average response latency increases to an unacceptable level.\n\n\n| **Note**: Bigtable reverts to eventual consistency after a failover. If you fail over to a cluster, and there are writes that have not been replicated to that cluster, some reads will return stale data until replication is complete.\n\n\u003cbr /\u003e\n\nBecause these signals can appear for many different reasons, failing over to a\ndifferent cluster is not guaranteed to resolve the underlying issue. [Monitor\nyour instance](/bigtable/docs/monitoring-instance) before and after the failover to verify that\nthe metrics have improved.\n\nFor details about how to complete a manual failover, see [Completing a manual\nfailover](/bigtable/docs/managing-failovers#manual).\n\nAutomatic failovers\n-------------------\n\nIf an app profile uses multi-cluster routing, Bigtable handles\nfailovers automatically. When the nearest cluster is unable to handle a request,\nBigtable routes traffic to the nearest cluster that is available.\n| **Warning:** If a request that contains a SQL statement fails, the request doesn't fail over, even when multi-cluster routing is enabled. This applies to SQL statements sent using a Bigtable client library as well as those run in the Bigtable Studio query editor.\n\nAutomatic failovers can occur even if a cluster is unavailable for a very short\nperiod of time. For example, if Bigtable routes a request to one\ncluster, and that cluster is excessively slow to reply or returns a transient\nerror, Bigtable will typically retry that request on another\ncluster.\n\nIf you are using multi-cluster routing and you send a request with a deadline,\nBigtable automatically fails over when necessary to help meet the\ndeadline. If the request deadline approaches but the initial cluster has not\nsent a response, Bigtable reroutes the request to the next closest\ncluster.\n\nBigtable uses an internal *last write wins* algorithm to handle\nany data conflicts that might occur as a result of failover before replication\nhas completed. See [Conflict resolution](/bigtable/docs/writes#conflict-resolution) for more details.\n\nIf you are using replication with multi-cluster routing to achieve high\navailability (HA) for your application, you should locate your client servers or\nVMs *in or near more than one Google Cloud region*. This recommendation applies\neven if your application server is not hosted by Google Cloud, because\nyour data enters the Google Cloud network through the Google Cloud\nregion that is closest to your application server. Like any request, a failover\ncompletes more quickly over shorter distances.\n\nMany automatic failovers are so brief that you won't notice them. You can check\nthe **Automatic Failovers** graph in the Google Cloud console to see the\nnumber of requests that were automatically rerouted over a given period of time:\nopen the [list of instances](https://console.cloud.google.com/bigtable/instances), click the instance name, then\nclick **System insights**.\n\nWhat's next\n-----------\n\n- Learn how to [complete a manual failover](/bigtable/docs/managing-failovers#manual).\n- Find out how to [monitor your instance](/bigtable/docs/monitoring-instance)."]]