本页面介绍 Cloud SQL 中的灾难恢复。
概览
在 Google Cloud 中，数据库灾难恢复 (DR) 的目的是让处理过程不中断，尤其是当某个区域出现故障或无法访问时。Cloud SQL 是一项区域性服务（当 Cloud SQL 配置为实现高可用性时）。因此，当托管 Cloud SQL 数据库的 Google Cloud 区域不可用时，Cloud SQL 数据库也会不可用。
如需继续处理，您必须尽快在辅助区域中提供该数据库。灾难恢复方案要求您在 Cloud SQL 中配置跨区域读取副本。您也可以根据导出/导入或备份/恢复执行故障切换，但这种方法需要花费更长时间，尤其是对于大型数据库而言。
以下业务场景是保证跨区域故障切换配置的示例：
- 业务应用的服务等级协议高于区域级 Cloud SQL 服务等级协议（可用性为 99.99%，具体取决于您的 Cloud SQL 版本）。通过故障切换切换到另一个区域，您可以缓解中断所造成的影响。
- 业务应用的所有层级已经属于多区域，其可在区域发生服务中断时继续处理。跨区域故障切换配置可确保数据库的使用不受中断。
- 所需的恢复时间目标 (RTO) 和恢复点目标 (RPO) 都以分钟为单位，而不是以小时为单位。与重新创建数据库相比，通过故障切换切换到另一个区域的速度更快。
一般来说，灾难恢复过程包含两种变化形式：
- 数据库通过故障切换切换到辅助区域。数据库准备就绪并供应用使用后，它将作为新的主数据库并持续作为主数据库。
- 数据库通过故障切换切换到辅助区域，但在主区域从故障中恢复后，将回到主区域。
此 Google Cloud SQL 数据库灾难恢复概览介绍了第二个变体：发生故障的数据库恢复并回退到主要区域。对于因为网络延迟或者因为某些资源仅在主要区域中可用而必须在主要区域运行的数据库，这种灾难恢复变体尤为有用。使用此变体时，数据库只会在主要区域服务中断期间在辅助区域运行。
灾难恢复架构
下图显示了支持高可用性 Cloud SQL 实例进行数据库灾难恢复的最小架构：
该架构的工作原理如下：
- Cloud SQL 的两个实例（主实例和备用实例）位于单个区域（主要区域）内的两个不同地区中。系统将使用区域永久性磁盘同步实例。
- 一个 Cloud SQL 实例（跨区域只读副本）位于另一个区域（辅助区域）。对于灾难恢复，设置跨区域只读副本以使用只读副本设置与主实例同步（使用异步复制）。
主实例和备用实例共享同一区域磁盘，因此它们的状态相同。
由于此类设置使用异步复制，因此跨区域只读副本可能会滞后于主实例。发生故障切换时，跨区域只读副本可能支持 RPO 等于零。
灾难恢复 (DR) 过程
灾难恢复 (DR) 过程会在主要区域不可用时启动。如需继续在次要区域中进行处理，请通过升级跨区域读取副本来触发主实例的故障切换。灾难恢复过程会设置必须手动或自动执行的操作步骤，从而减少区域级故障并在次要区域中建立正在运行的主实例。
下图展示了此灾难恢复过程：
灾难恢复过程包括以下步骤：
- 运行主实例的主要区域 (R1) 不可用。
- 运营团队识别并正式确认灾难，并确定是否需要故障切换。
- 如果需要故障切换，您可以将次要区域 (R2) 中的跨区域读取副本升级为新的主实例。
- 客户端连接已重新配置为继续处理新的主实例，并访问 R2 中的主实例。
此初始过程会再次建立一个正常运行的主数据库。但是，它不会建立完整的灾难恢复架构，其中新的主实例本身具有一个备用实例和一个跨区域只读副本。
完整的灾难恢复过程可确保为 HA 启用单个实例（即新的主实例），并确保该实例具有跨区域只读副本。完整的 DR 过程还会提供回退到原始主区域中的原始部署的机制。
通过故障切换切换到辅助区域
完整灾难恢复过程在基本灾难恢复过程的基础上进行了扩展，它在故障切换之后增加了建立完整灾难恢复架构的步骤。下图展示了故障切换之后的完整数据库灾难恢复架构：
完整数据库灾难恢复过程包括以下步骤：
- 运行主数据库的主要区域 (R1) 不可用。
- 运营团队识别并正式确认灾难，并确定是否需要故障切换。
- 如果需要故障切换，您可以将辅助区域 (R2) 中的跨区域读取副本提升为新的主实例。
- 客户端连接已重新配置为访问并处理新的主实例 (R2)。
- 系统会在 R2 中创建并启动一个新的备用实例并将其添加到主实例中。备用实例与主实例位于不同的可用区。主实例现在具有高可用性，因为已为它创建备用实例。
- 在第三个区域 (R3) 中，系统会创建一个新的跨区域只读副本并将其附加到主实例。此时，完整灾难恢复架构将被重新创建且正常运行。
如果原始主要区域 (R1) 在实现第 6 步之前可用，则跨区域只读副本可以放在区域 R1 中，而不是立即放在区域 R3 中。在此情况下，回退到原始主要区域 (R1) 的步骤不太复杂，所需步骤较少。
避免出现脑裂状态
主要区域 (R1) 故障并不意味着原始主实例及其备用实例会自动关停、移除或在 R1 再次可用时无法访问。如果 R1 可用，客户端可能会在原始主实例上读取和写入数据（甚至意外读取和写入数据）。在这种情况下，脑裂情况可能会出现，即有些客户端访问旧主数据库中的过时数据，而有些客户端访问新的主数据库中的最新数据，从而导致业务出现问题。
为避免出现脑裂情况，在 R1 可用后，您必须确保客户端无法再访问原始主实例。理想情况下，您应先使原始主实例无法访问，再开始使用新的主实例，然后删除无法访问的原始主实例。
在故障切换后建立初始备份
在故障切换中，当您将跨区域读取副本提升为新的主实例时，新主实例中的事务可能不会完全与原始主实例中的事务同步。因此，这些事务在新实例中不可用。
根据最佳做法，我们建议您在故障切换开始时以及在客户访问数据库之前立即备份新的主实例。此类备份表示在进行故障切换时处于一致的已知状态。如果客户在访问新的主实例时遇到问题，则此类备份对于监管目的或恢复为已知状态而言可能很重要。
回退到原始主要区域
如前所述，本文档提供回退到原始区域 (R1) 的步骤。回退过程有两个不同版本。
- 如果您在第三区域 (R3) 中创建了新的跨区域只读副本，则必须在主要区域 (R1) 中创建另一个（第二个）跨区域只读副本。
- 如果您在主要区域 (R1) 中创建了新的跨区域只读副本，则无需在 R1 中另外创建一个跨区域只读副本。
当 R1 中存在跨区域只读副本后，Cloud SQL 实例便可以回退到 R1。由于此回退操作是手动触发而不是根据服务中断触发的，因此您可以为此维护活动选择合适的日期和时间。
因此，为实现具有主实例和备用实例以及跨区域只读副本的完整灾难恢复，您需要执行两次故障切换。第一次故障切换由服务中断触发（真正的故障切换），第二次故障切换会重新建立起始部署（回退）。
回退到原始主要区域 (R1) 的过程包括以下步骤：
- 升级原始主要区域 (R1) 中新创建的跨区域副本。
- 重新配置您的应用以连接到新的主实例。
- 在灾难恢复区域 (R2) 中为新的主实例创建一个跨区域副本。
- （可选）为避免运行多个独立的主实例，请清理灾难恢复区域 (R2) 中的主实例。
后续步骤
- 探索有关 Google Cloud 的参考架构、图表、教程和最佳实践。查看我们的云架构中心。