Cloud SQL 中的灾难恢复 (DR) 简介

MySQL   |  PostgreSQL   |  SQL Server

本页面介绍 Cloud SQL 中的灾难恢复。

概览

在 Google Cloud 中，数据库灾难恢复 (DR) 的目的是让处理过程不中断，尤其是当某个区域出现故障或无法访问时。Cloud SQL 是一项区域级服务（当 Cloud SQL 配置为实现高可用性 [HA] 时）。因此，当托管 Cloud SQL 数据库的 Google Cloud 区域不可用时，Cloud SQL 数据库也会不可用。

如需继续处理，您必须尽快在辅助区域中提供该数据库。灾难恢复方案要求您在 Cloud SQL 中配置跨区域读取副本。您也可以根据导出/导入或备份/恢复执行故障切换，但这种方法需要花费更长时间，尤其是对于大型数据库而言。

以下业务场景是保证跨区域故障切换配置的示例：

• 业务应用的服务等级协议高于区域级 Cloud SQL 服务等级协议（可用性为 99.99%，具体取决于您的 Cloud SQL 版本）。通过故障切换切换到另一个区域，您可以缓解中断所造成的影响。
• 业务应用的所有层级已经属于多区域，其可在区域发生服务中断时继续处理。跨区域故障切换配置可确保数据库的使用不受中断。
• 所需的恢复时间目标 (RTO) 和恢复点目标 (RPO) 都以分钟为单位，而不是以小时为单位。与重新创建数据库相比，通过故障切换切换到另一个区域的速度更快。

一般来说，灾难恢复过程包含两种变化形式：

• 数据库通过故障切换切换到辅助区域。数据库准备就绪并供应用使用后，它将作为新的主数据库并持续作为主数据库。
• 数据库通过故障切换切换到辅助区域，但在主区域从故障中恢复后，将回到主区域。

此 Google Cloud SQL 数据库灾难恢复概览介绍了第二个变体：发生故障的数据库恢复并回退到主要区域。对于因为网络延迟或者因为某些资源仅在主要区域中可用而必须在主要区域运行的数据库，这种灾难恢复变体尤为有用。使用此变体时，数据库只会在主要区域服务中断期间在辅助区域运行。

与此灾难恢复文档关联的两个教程：

• Cloud SQL for MySQL 灾难恢复：完整的故障切换和回退过程
• Cloud SQL for PostgreSQL 灾难恢复：完整的故障切换和回退过程

灾难恢复架构

下图显示了支持高可用性 Cloud SQL 实例进行数据库灾难恢复的最小架构：

该架构的工作原理如下：

• Cloud SQL 的两个实例（主实例和备用实例）位于单个区域（主要区域）内的两个不同地区中。系统将使用区域永久性磁盘同步实例。
• 一个 Cloud SQL 实例（跨区域只读副本）位于另一个区域（辅助区域）。对于灾难恢复，设置跨区域只读副本以使用只读副本设置与主实例同步（使用异步复制）。

主实例和备用实例共享同一区域磁盘，因此它们的状态相同。

由于此类设置使用异步复制，因此跨区域只读副本可能会滞后于主实例。因此，当发生故障切换时，跨区域只读副本 RPO 可能不为零。

灾难恢复 (DR) 过程

灾难恢复 (DR) 过程会在主要区域不可用时启动。如需继续在次要区域中进行处理，请通过升级跨区域读取副本来触发主实例的故障切换。灾难恢复过程会设置必须手动或自动执行的操作步骤，从而减少区域级故障并在次要区域中建立正在运行的主实例。

下图展示了此灾难恢复过程：

灾难恢复过程包括以下步骤：

1. 运行主实例的主要区域 (R1) 不可用。
2. 运营团队识别并正式确认灾难，并确定是否需要故障切换。
3. 如果需要故障切换，您可以将次要区域 (R2) 中的跨区域读取副本升级为新的主实例。
4. 客户端连接已重新配置为继续处理新的主实例，并访问 R2 中的主实例。

此初始过程会再次建立一个正常运行的主数据库。但是，它不会建立完整的灾难恢复架构，其中新的主实例本身具有一个备用实例和一个跨区域只读副本。

完整的灾难恢复过程可确保为 HA 启用单个实例（即新的主实例），并确保该实例具有跨区域只读副本。完整的 DR 过程还会提供回退到原始主区域中的原始部署的机制。

通过故障切换切换到辅助区域

完整灾难恢复过程在基本灾难恢复过程的基础上进行了扩展，它在故障切换之后增加了建立完整灾难恢复架构的步骤。下图展示了故障切换之后的完整数据库灾难恢复架构：

完整数据库灾难恢复过程包括以下步骤：

1. 运行主数据库的主要区域 (R1) 不可用。
2. 运营团队识别并正式确认灾难，并确定是否需要故障切换。
3. 如果需要故障切换，您可以将辅助区域 (R2) 中的跨区域读取副本提升为新的主实例。
4. 客户端连接已重新配置为访问并处理新的主实例 (R2)。
5. 系统会在 R2 中创建并启动一个新的备用实例并将其添加到主实例中。备用实例与主实例位于不同的可用区。主实例现在具有高可用性，因为已为它创建备用实例。
6. 在第三个区域 (R3) 中，系统会创建一个新的跨区域只读副本并将其附加到主实例。此时，完整灾难恢复架构将被重新创建且正常运行。

如果原始主要区域 (R1) 在实现第 6 步之前可用，则跨区域只读副本可以放在区域 R1 中，而不是立即放在区域 R3 中。在此情况下，回退到原始主要区域 (R1) 的步骤不太复杂，所需步骤较少。

注意：您可以通过消除第 5 步和第 6 步来降低完整灾难恢复过程的 RTO。为此，请在辅助区域 (R2) 中创建跨区域副本作为高可用性副本，在第三个区域 (R3) 中创建跨区域副本作为级联副本，并将其来源用作 R2 中的副本。

避免出现脑裂状态

主要区域 (R1) 故障并不意味着原始主实例及其备用实例会自动关停、移除或在 R1 再次可用时无法访问。如果 R1 可用，客户端可能会在原始主实例上读取和写入数据（甚至意外读取和写入数据）。在这种情况下，脑裂情况可能会出现，即有些客户端访问旧主数据库中的过时数据，而有些客户端访问新的主数据库中的最新数据，从而导致业务出现问题。

为避免出现脑裂情况，在 R1 可用后，您必须确保客户端无法再访问原始主实例。理想情况下，您应先使原始主实例无法访问，再开始使用新的主实例，然后删除无法访问的原始主实例。

在故障切换后建立初始备份

在故障切换中，当您将跨区域读取副本提升为新的主实例时，新主实例中的事务可能不会完全与原始主实例中的事务同步。因此，这些事务在新实例中不可用。

根据最佳做法，我们建议您在故障切换开始时以及在客户访问数据库之前立即备份新的主实例。此类备份表示在进行故障切换时处于一致的已知状态。如果客户在访问新的主实例时遇到问题，则此类备份对于监管目的或恢复为已知状态而言可能很重要。

回退到原始主要区域

如前所述，本文档提供回退到原始区域 (R1) 的步骤。回退过程有两个不同版本。

• 如果您在第三区域 (R3) 中创建了新的跨区域只读副本，则必须在主要区域 (R1) 中创建另一个（第二个）跨区域只读副本。
• 如果您在主要区域 (R1) 中创建了新的跨区域只读副本，则无需在 R1 中另外创建一个跨区域只读副本。

当 R1 中存在跨区域只读副本后，Cloud SQL 实例便可以回退到 R1。由于此回退操作是手动触发而不是根据服务中断触发的，因此您可以为此维护活动选择合适的日期和时间。

因此，为实现具有主实例和备用实例以及跨区域只读副本的完整灾难恢复，您需要执行两次故障切换。第一次故障切换由服务中断触发（真正的故障切换），第二次故障切换会重新建立起始部署（回退）。

回退到原始主要区域 (R1) 的过程包括以下步骤：

1. 升级原始主要区域 (R1) 中新创建的跨区域副本。
2. 如果升级的实例最初并非作为高可用性副本创建，请在实例上启用高可用性以防止发生可用区故障。
3. 重新配置您的应用以连接到新的主实例。
4. 在灾难恢复区域 (R2) 中为新的主实例创建一个跨区域副本。
5. （可选）为避免运行多个独立的主实例，请清理灾难恢复区域 (R2) 中的主实例。

高级灾难恢复 (DR)

预览

此功能须遵守服务专用条款的“通用服务条款”部分中的“非正式版产品条款”。 非正式版功能“按原样”提供，可能只能获得有限的支持。 如需了解详情，请参阅发布阶段说明。

如果您使用的是 Cloud SQL 企业 Plus 版，则可以利用高级灾难恢复。高级灾难恢复简化了跨区域故障切换后的恢复和回退过程。如灾难恢复过程中所述，执行灾难恢复时，您需要移除旧主实例的故障区域与新主实例的操作区域之间的连接。使用灾难恢复时，如需恢复与原始部署区域的连接并重新获得旧的主实例，您必须执行一系列手动回退步骤。

使用高级灾难恢复时，如果发生区域性故障，您可以调用副本故障切换。使用副本故障切换时，您需要升级跨区域只读副本，此过程与执行常规灾难恢复类似，不同之处是需要升级指定的灾难恢复 (DR) 副本。提升灾难恢复副本的过程很快。

系统不会移除旧的主实例，该实例仍会保留为 Cloud SQL 异步复制拓扑的一部分。在灾难恢复副本升级为新的主实例后，旧的主实例（实例 A）最终会成为其灾难恢复副本（实例 B）的副本。

旧的主实例 (A) 转换为副本后，您可以执行高级灾难恢复的最后一步。您可以将 Cloud SQL 部署恢复为原始状态，并将旧的主实例 (A) 恢复为以前的角色（即主实例），而不会丢失任何数据。如需对旧的主实例 (A) 执行无任何数据丢失的恢复过程，您可以使用切换操作。执行切换时，不会丢失任何数据，因为主实例 (B) 在其指定的灾难恢复副本 (A) 完成与主实例 (B) 的同步之前一直保持只读模式。在灾难恢复副本 (A) 收到所有复制更新后，灾难恢复副本 (A) 会充当主实例，而之前的主实例 (B) 会自动重新配置为当前主实例 (A) 的灾难恢复副本。实例会恢复为原始角色，从而将拓扑恢复到进行灾难恢复和副本故障切换之前的原始状态。

在整个高级灾难恢复过程中，副本故障切换和切换操作涉及的所有实例都将保留其 IP 地址。

注意：虽然切换不会导致任何数据丢失，但如果在您启动副本故障切换操作时，灾难恢复副本遇到复制延迟现象，则副本故障切换可能会导致数据丢失。

您还可以使用高级灾难恢复的切换操作执行例行灾难恢复深入分析，以便在灾难发生之前测试和准备用于跨区域故障切换的 Cloud SQL 拓扑。如果发生实际灾难，您可以执行已测试的跨区域副本故障切换。

灾难恢复 (DR) 副本

作为高级灾难恢复的必需组成元素，灾难恢复副本具有以下特征：

• 灾难恢复副本是直接连接的跨区域只读副本。
• 您可以多次更改指定的灾难恢复副本。
• 除了在切换或副本故障切换操作期间外，您可以随时更改指定的灾难恢复副本。

此外，为了在使用高级灾难恢复后降低 RTO，我们建议您执行以下操作：

• 配置与主实例大小相同的灾难恢复副本。
• 如果主实例启用了高可用性，我们建议您也对灾难恢复副本启用高可用性。为此，请先验证主实例是否启用了高可用性。然后，执行切换到灾难恢复副本的操作。切换操作完成后，对新的主实例启用高可用性。然后，您可以切换回旧的主实例。即使灾难恢复副本再次成为副本，它也会保留其高可用性配置。

副本故障切换

副本故障切换包含以下步骤：

1. 在执行副本故障切换之前，您已为主实例分配了一个灾难恢复副本，并且可能已经通过执行切换测试了该过程。
2. 运行主数据库的主要区域不可用。
3. 运营团队认为需要进行灾难恢复。
4. 执行副本故障切换以切换到指定的跨区域灾难恢复副本。
5. 指定的跨区域灾难恢复副本会立即成为主实例，并开始接受传入的读取和写入。
6. 此时，您必须将应用配置为指向新的主实例。
7. 提升副本后，Cloud SQL 会定期检查原始主实例是否已恢复为在线状态。如果原始主实例处于在线状态，Cloud SQL 会将旧的主实例重新配置为提升的实例的副本。旧的主实例会保留其 IP 地址。

执行副本故障切换后，您可以通过执行切换操作来恢复相同的灾难恢复副本和主实例对，从而恢复原始区域中的主实例。

切换

切换包括以下步骤：

1. 在开始切换操作之前，您必须为主实例分配灾难恢复副本。
2. 验证主实例的运行状况是否良好。只有在主实例和灾难恢复副本都处于在线状态时，才能执行切换操作。
3. 您可以启动切换。启动切换时，主实例会停止接受写入，变为只读状态。
4. 等待二进制日志复制到 Cloud Storage 中。
5. 指定的灾难恢复副本完全与主实例同步。
6. 当复制延迟时间减少到零时，灾难恢复副本将升级为新的主实例。新的主实例开始接受传入的连接，包括应用读取和写入。
7. 旧的主实例重新配置为只读副本。
8. 此时，您必须将应用配置为指向新的主实例。
9. 系统会自动为新的主实例启用 PITR。只有在首次自动备份后才可以使用 PITR。

后续步骤

• 使用高级灾难恢复 (DR)。
• 尝试 Cloud SQL for MySQL 灾难恢复教程。
• 探索有关 Google Cloud 的参考架构、图表、教程和最佳实践。查看我们的云架构中心。