故障转移

如果 Cloud Bigtable 集群无响应,则复制功能可将传入流量故障转移到属于同一实例的其他集群。故障转移可以手动或自动执行,具体取决于应用使用的应用配置文件以及该应用配置文件的配置方式。

本页面介绍了在使用复制功能的实例中手动和自动故障转移的工作原理。 如需了解如何完成故障转移,请参阅管理故障转移

在阅读本页内容之前,您应先熟悉 Cloud Bigtable 复制功能概览

手动故障转移

如果应用配置文件使用单集群路由将所有请求引向一个集群,您必须自行判断何时开始故障转移到其他集群。

如果出现下面的信号,可能表示故障转移到其他集群会有所帮助:

  • 集群开始返回大量暂时性系统错误。
  • 大量请求开始超时。
  • 平均响应延迟增加到不可接受的水平。

这些信号可能是由许多不同原因造成的,因此故障转移到不同集群并不能保证解决潜在的问题。您应在故障转移之前和之后监控您的实例,以确认相关指标是否有所改善。

如需详细了解如何完成手动故障转移,请参阅完成手动故障转移

自动故障转移

如果应用配置文件使用多集群路由,则 Cloud Bigtable 会自动处理故障转移。如果距离最近的集群无法处理请求,Cloud Bigtable 会将流量路由到另一个可用的最近集群。

即使集群只是在很短的一小段时间内不可用,也可能发生自动故障转移。例如,如果 Cloud Bigtable 将请求路由到一个集群,并且该群集响应速度过慢或返回暂时性错误,则 Cloud Bigtable 通常会在另一个集群上重试该请求。

如果您使用多集群路由,并且发送了带有截止时间的请求,则 Cloud Bigtable 会在必要时自动进行故障转移,以帮助您满足截止时间。如果请求的截止时间已到,但初始集群尚未发送响应,则 Cloud Bigtable 会将该请求重新路由到下一个最近的集群。

如果您搭配使用复制功能和多集群路由来实现应用的高可用性,则应将客户端服务器或虚拟机放置在多个 Google Cloud 区域内或这些区域附近。即使您的应用服务器不是由 Google Cloud 托管,这项建议也适用,因为您的数据会通过距离应用服务器最近的 Google Cloud 区域进入 Google Cloud 网络。与任何请求一样,距离越短,故障转移的完成速度就越快。

自动故障转移过程通常非常简短,以至于您无法察觉。您可以在 Cloud Console 中查看自动故障转移图表,以便了解在指定时间段内自动重新路由的请求数,方法如下:打开实例列表,点击实例名称,然后点击监控

后续步骤