复制设置示例

本页面首先介绍了启用 Bigtable 复制的一些常见使用场景，然后展示了可供您用来为这些使用场景提供支持的设置。

隔离批量分析工作负载与其他应用
实现高可用性
提供近乎实时的备份
保持高可用性和区域弹性
将数据存储在您的用户附近

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

在将集群添加到实例之前，您需要了解更改复制表的垃圾回收政策时的适用限制。

无论您的使用场景是什么，请务必在实例的每个集群中预配足够的节点，以确保除了从应用接收的负载之外，每个集群还可以处理复制操作。如果集群的节点不足，则复制延迟时间可能会增加，并且由于内存使用量增加，集群可能会遇到性能问题，并且写入实例中其他集群的操作可能会被拒绝。

隔离批量分析工作负载与其他应用

如果您使用同一个集群运行一个执行大量大型读取操作的批量分析作业和一个执行混合读写操作的应用，那么大型批量作业会拖慢该应用的用户体验到的速度。通过复制，您可以通过设置单集群路由的应用配置文件，将批量分析作业流量和应用流量路由到不同的集群，确保批量作业不会影响到应用的用户。

要隔离两个工作负载，请执行以下操作：

新建一个包含 2 个集群的实例，或向现有实例添加第二个集群。

请在此配置中遵循标准 CPU 利用率建议。
创建 2 个应用配置文件，分别是 live-traffic 和 batch-analytics。

如果您的集群 ID 是 cluster-a 和 cluster-b，则 live-traffic 应用配置文件应将请求路由到 cluster-a，而 batch-analytics 应用配置文件应将请求路由到 cluster-b。此配置会为使用相同应用配置文件的应用提供读己所写 (read-your-writes) 一致性，但不会为使用不同应用配置文件的应用提供这种一致性。

如有必要，您可以在 live-traffic 应用配置文件中启用单行事务。无需在 batch-analytics 应用配置文件中启用单行事务（假设该应用配置文件仅用于读取操作）。
使用 live-traffic 应用配置文件运行实时流量工作负载。
在实时流量工作负载运行时，使用 batch-analytics 应用配置文件运行只读的批量工作负载。
针对实例的集群监控 CPU 利用率，并在必要时向集群添加节点。
使用您选择的工具监控客户端延迟情况。若是使用 Java 版 HBase 客户端，您可以根据其客户端指标监控延迟情况。

如需将两个较小的工作负载与一个较大的工作负载隔离开，请执行以下操作：

新建一个包含 3 个集群的实例，或向现有实例添加集群至 3 个。

请在此配置中遵循标准 CPU 利用率建议。

这些步骤假设您的集群使用 ID cluster-a、cluster-b 和 cluster-c。

如果 cluster-a 和 cluster-b 为同一应用提供服务，请在这两个集群中使用相同数量的节点。在 cluster-c 中使用更多的节点，为较大的工作负载提供支持。
创建以下应用配置文件：
- live-traffic-app-a：从您的应用到 cluster-a 的单集群路由
- live-traffic-app-b：从您的应用到 cluster-b 的单集群路由
- batch-analytics：从批量分析作业到 cluster-c 的单集群路由
使用 live-traffic 应用配置文件来运行实时流量工作负载。
在实时流量工作负载运行时，使用 batch-analytics 应用配置文件运行只读的批量工作负载。
针对实例的集群监控 CPU 利用率，并在必要时向集群添加节点。
使用您选择的工具监控客户端延迟情况。若是使用 Java 版 HBase 客户端，您可以根据其客户端指标监控延迟情况。

创建高可用性 (HA)

如果实例只有 1 个集群，那么您的数据的耐用性和可用性将受限于该集群所在的可用区。复制功能可在多个可用区或区域中分别为您的数据存储一份副本，并可在需要时自动在多个集群之间进行故障切换，从而提高了数据的耐用性和可用性。

如需为实例配置高可用性 (HA) 用例，请创建新的应用配置文件以使用多集群路由，或更新默认应用配置文件以使用多集群路由。这一配置可提供最终一致性。您将无法启用单行事务，因为在使用多集群路由时，单行事务可能会导致数据冲突。

如需详细了解 Bigtable 如何帮助实现高可用性，请参阅使用 Bigtable 构建全球规模的数据集合。

用于提高可用性的配置包括以下情形。

位于 3 个或更多不同区域的集群（推荐配置）。 高可用性的推荐配置是具有 N+2 个集群，且每个集群位于不同区域的实例。例如，如果您需要处理数据的集群的最小数量为 2，则需要一个包含 4 个集群的实例才能保持高可用性。即使 2 个区域不可用（此情况极少），此配置也可以确保正常运行时间。我们建议您将集群分布在多个大洲。

配置示例：
- 位于爱荷华州 us-central1-a 可用区的 cluster-a
- 位于比利时 europe-west1-d 可用区的 cluster-b
- 位于台湾 asia-east1-b 可用区的 cluster-c
对于此配置，请预配足够的节点以维持一个目标（3 集群、3 个区域的实例和 4 个集群、4 个区域的实例分别对应 23% 和 35% 的 CPU 利用率）。这样可以确保即使两个区域不可用，剩余的一个或多个集群也可以处理所有流量。
两个集群位于同一区域但位于不同可用区。此方案可提供区域可用性内的高可用性、无需故障切换即可进行跨区域复制费用的功能，并且不会增加故障切换的延迟时间。只要复制的 Bigtable 实例所在的任何可用区可用，该实例中的数据即可用。

配置示例：
- 位于悉尼 australia-southeast1-a 可用区的 cluster-a
- 位于悉尼 australia-southeast1-b 可用区的 cluster-b
请在此配置中遵循标准 CPU 利用率建议。
两个集群位于不同区域。这种多区域配置提供与上述多可用区配置类似的高可用性，但即使您无法连接到其中一个区域，您的数据也可用。

在区域之间复制写入需要付费。

配置示例：
- 位于东京 asia-northeast1-c 可用区的 cluster-a
- 位于香港 asia-east2-b 可用区的 cluster-b
请在此配置中遵循标准 CPU 利用率建议。
两个集群位于区域 A，第三个集群位于区域 B。即使您无法连接到其中一个区域，此选项也可使您的数据可用，并且它在区域 A 中提供额外的容量。

在区域之间复制写入需要付费。如果您写入区域 A，您需要付费一次，因为区域 B 只有一个集群。如果您写入区域 B，则需要支付两次费用，因为区域 A 有两个集群。

配置示例：
- 位于比利时 europe-west1-b 可用区的 cluster-a
- 位于比利时 europe-west1-d 可用区的 cluster-b
- 位于芬兰 europe-north1-c 可用区的 cluster-c
含两个集群的区域 CPU 利用率为 35%，另一个区域为 70%，以此作为起始目标。监视实例的集群并根据需要调整节点数，以便每个集群都有足够的资源来处理故障切换。

您可以模拟此使用场景的故障切换来测试您的应用：

使用采用多集群路由的应用配置文件来运行测试工作负载。
使用 Google Cloud 控制台监控实例的集群并确认集群正在处理传入请求。
删除其中一个集群以模拟中断情况。

这项更改还会删除随集群一起存储的数据副本。
继续监控延迟情况和错误率。如果剩余集群有足够的 CPU 资源，它们应该可以满足传入请求。
向该实例添加集群，并继续监控该实例。系统应该开始将数据复制到新集群。

提供近乎实时的备份

在某些情况下（例如，您不能冒所读取的数据过时的风险），您始终需要将请求路由至一个集群。但是，您仍然可以使用复制功能，即使用一个集群处理请求，而保留另一个集群作为近乎实时的备份。如果生产集群不可用，您可以手动故障切换至备份集群，从而最大程度地减少停机时间。

要针对此使用场景配置您的实例，请创建一个使用单集群路由的新应用配置文件，或者更新默认应用配置文件以使用单集群路由。您在应用配置文件中指定的集群会处理传入请求。另一个集群将充当备份，以供在需要进行故障切换时使用。这一配置有时称为“活跃-非活跃”配置，它可同时提供高度一致性和读己所写一致性。如有必要，您可以在应用配置文件中启用单行事务。

请在此配置中遵循标准 CPU 利用率建议。

如需实现这一配置，请执行以下操作：

用设置单集群路由的应用配置文件运行工作负载。
使用 Google Cloud 控制台监控实例的集群并确认只有 1 个集群正在处理传入请求。

另一个集群仍将使用 CPU 资源执行复制和其他维护任务。
更新应用配置文件，使其指向您实例中的另一个集群。

您将会收到关于失去读己所写一致性的警告，这也意味着您还会失去高度一致性。

如果您启用了单行事务，您还将收到有关可能丢失数据的警告。如果您在故障切换期间发送有冲突的写入，您的数据则会丢失。
继续监控您的实例。您应该会看到另一个集群正在处理传入请求。

保持高可用性和区域弹性

假设您的客户集中分布在一个大洲的两个不同区域。您希望尽可能通过靠近客户的 Bigtable 集群为每个集中区域中的客户提供服务。您希望每个区域内的数据高度可用，还可能希望当一个或多个集群不可用时使用故障切换选项。

对于此使用场景，您可以创建一个实例，使其在区域 A 和区域 B 中分别包含 2 个集群。此项配置在您无法连接到一个 Google Cloud 区域时也可提供高可用性。它还提供区域弹性，即使某个可用区变得不可用，其所在区域的另一个集群仍然可用。

您可以根据业务需要选择针对此用例使用多集群路由还是单集群路由。

如需针对此使用场景配置您的实例，请执行以下操作：

创建一个 Bigtable 实例并使其包含 4 个集群（在区域 A 和区域 B 中分别包含 2 个集群）。同一区域中的集群必须位于不同的可用区。

配置示例：
- 位于孟买 asia-south1-a 可用区的 cluster-a
- 位于孟买 asia-south1-c 可用区的 cluster-b
- 位于东京 asia-northeast1-a 可用区的 cluster-c
- 位于东京 asia-northeast1-b 可用区的 cluster-d
在每个区域附近布置一台应用服务器。

您可以根据业务需要选择针对此用例使用多集群路由还是单集群路由。如果您使用多集群路由，则 Bigtable 会自动处理故障切换。如果使用单集群路由，则您可以根据自己的判断来决定何时故障切换到其他集群。

单集群路由选项

如果您不希望 Bigtable 集群在可用区或区域不再可用时自动故障切换，则可以针对此使用场景使用单集群路由。如果您想要管理 Bigtable 开始在远程区域之间路由流量时可能产生的费用和延迟，或者您希望根据自己的判断或业务规则做出故障切换决策，则此选项是一个不错的选择。

要实现这一配置，请至少创建一个应用配置文件，该应用配置文件会为向实例发送请求的每个应用使用单集群路由。您可以将应用配置文件路由到 Bigtable 实例中的任何集群。例如，如果您在孟买运行三个应用，并在东京运行六个应用，则可以为孟买应用配置一个应用配置文件以路由到 asia-south1-a，并配置两个应用配置文件以路由到 asia-south1-c。对于东京应用，配置三个应用配置文件以路由到 asia-northeast1-a，并另外配置三个应用配置文件以路由到 asia-northeast1-b。

请在此配置中遵循标准 CPU 利用率建议。

使用此配置时，如果一个或多个集群不再可用，您可以执行手动故障切换，或者选择让该可用区的数据暂时不可用，直到该可用区再次可用为止。

多集群路由选项

如果您要实现此使用场景，并且希望 Bigtable 在您的应用无法访问某个区域时自动故障切换到另一个区域，请使用多集群路由。

如需实现这一配置，请创建新的应用配置文件以便为每个应用使用多集群路由，或更新默认应用配置文件以使用多集群路由。

这一配置可提供最终一致性。如果某个区域不再可用，则 Bigtable 请求将会自动发送到其他区域。发生这种情况时，您需要为流往其他区域的网络流量付费，由于距离较远，您的应用可能会遇到较长时间的延迟。

最初设置实例时，每个集群的 CPU 利用率不要超过 35%。此目标可确保在发生故障切换时，通常由区域中其他集群处理的流量可由每个集群单独处理。您可能需要根据流量和使用模式调整此目标。

您可以模拟此使用场景的故障切换来测试您的应用：

运行测试工作负载。
使用 Google Cloud 控制台监控实例的集群并确认所有 4 个集群都在处理传入请求。
删除区域 A 中的一个集群以模拟连接到可用区时发生的问题。

这项更改还会删除随集群一起存储的数据副本。
继续监控剩余集群的延迟情况和错误率。

如果集群有足够的 CPU 资源，它们应该可以满足传入请求。
在区域 A 中为实例添加一个集群，并继续监控实例。

系统应该开始将数据复制到新集群。
删除区域 A 中的两个集群以模拟连接到区域时发生的问题。

这项更改还会删除位于这些集群中的数据副本。
继续监控剩余集群的延迟情况和错误率。

如果集群有足够的 CPU 资源，它们应该可以满足先前由其他区域处理的传入请求。如果集群的资源不足，您可能需要调整节点数。

将数据存储在您的用户附近

如果您的用户遍布全球，则可以通过在用户附近运行应用并尽可能将数据储存在应用附近来减少延迟时间。借助 Bigtable，您可以创建一个实例并使其包含多个 Google Cloud 区域中的集群，您的数据会自动在每个区域中复制。

对于此用例，请使用设置单集群路由的应用配置文件。由于集群之间存在距离，因此多集群路由不适用于此用例。如果某个集群不再可用，而其多集群应用配置文件自动开始跨远距离重新路由流量，则您的应用可能会遇到不可接受的延迟，并导致出乎预料的额外网络费用。