Cloud SQL 实例维护简介

本页面介绍了 Cloud SQL 实例的维护更新方式，以及如何控制这些更新的时间。如需开始进行维护，请参阅查找和设置维护期。

概览

作为托管式服务，Cloud SQL 会自动更新实例，以确保底层硬件、操作系统和数据库引擎可靠、高性能、安全且是最新版本。其中大部分更新都在 Cloud SQL 实例启动和运行期间执行。但是，某些系统更新需要短暂中断服务。这些更新称为维护。

维护会更新数据库引擎，在某些情况下还会更新操作系统。由于这些更新需要重启实例，因此会导致一些停机时间。维护更新具有以下优势：

  • Cloud SQL 特性如要启动新功能，数据库引擎会更新，并且安装数据库的新插件。

  • 数据库版本升级开发 MySQL 的数据库软件提供商每年会多次发布新的次要版本。每个新版本中都有一些问题修复、安全补丁程序、性能增强功能和新的数据库功能。您可通过查看版本说明或数据库版本和版本政策，查找 Cloud SQL for MySQL 支持的最新次要版本。Cloud SQL 实例在发布后不久就会升级到最新的数据库版本，以便您从运行最新的数据库软件中受益。

    您需要手动执行 MySQL 8.0 次要版本升级。请参阅为实例设置 MySQL 次要版本。

  • 操作系统补丁程序。我们持续监控操作系统中新发现的安全漏洞。发现漏洞后，我们会修补操作系统，以防范新风险。

维护影响

对于 Cloud SQL 企业 Plus 版，Cloud SQL 提供近乎零停机时间的计划内维护。

Cloud SQL 通常每隔几个月安排一次维护更新事件。每个实例的维护更新可能需要大约 5 到 10 分钟。如果实例有读取副本，则维护更新的总时长可能会更长。不过，在维护更新事件期间，每个 Cloud SQL 企业版实例平均会断开连接的时间少于 60 秒。对于在维护更新事件期间具有大量活动或具有非常大的数据集的实例，停机时间可能较长。

您可以采取我们的维护设置，并使您的系统能够应对暂时性错误，来采取措施尽可能减少维护对运营的影响。

近乎零停机时间的计划内维护

由于近乎零停机时间的计划内维护，因此 Cloud SQL 企业 Plus 版实例在计划内维护期间断开连接的时间通常不到 1 秒。

对于在维护期间具有大量活动的实例，停机时间可能较长。

前提条件和限制条件

  • 您必须在实例上启用二进制日志记录。

  • 如果您使用的是以下任何标志，则必须将其设置为默认值：

    • sync_binlog，值：1
    • innodb_flush_log_at_trx_commit，值 1
    • replica_skip_errors，值 OFF
    • binlog_order_commit，值 ON

    如需了解详情，请参阅配置数据库标志。

  • 如果您使用的是 Cloud SQL Auth 代理或 Cloud SQL 语言连接器，请确保将其更新到最新版本。

  • 如果您有启用了 GTID 的外部副本，则必须将这些副本配置为使用基于 GTID 的自动定位，否则复制将在维护后中断。如需了解详情，请参阅 GTID 自动定位。

  • 在维护期间，您的 MySQL 服务器 UID 将会发生变化。

  • 在维护期间，数据库日志将包含来自两个不同的虚拟机的消息。
  • 如果在计划内维护期间发出 DDL，则更改可能会具有晚于维护时间戳的创建或修改时间戳。

模拟近乎零停机时间的计划内维护

如需在不更新数据库实例的情况下测试 Cloud SQL 企业 Plus 版主实例的计划内维护停机时间，您可以模拟近乎零停机时间的计划内维护。

为此，请在符合近乎零停机时间的计划内维护条件的 Cloud SQL 企业 Plus 版实例上调用维护事件模拟。模拟请求会使实例更新为操作之前的同一维护版本。

即使实例上有待处理的维护更新，您也可以执行模拟。在整个模拟过程中，实例版本保持不变。

如需模拟近乎零停机时间的计划内维护事件，请使用以下 gcloud CLI 命令：

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

将 INSTANCE_NAME 替换为您要在其中运行模拟维护事件的实例的名称。

维护设置

Cloud SQL 可让您通过一组维护设置来配置维护更新。

您可以将维护配置为在短暂停机给应用带来的影响最小的时候进行。对于每个 Cloud SQL 实例，您可以配置以下内容：

  • 维护时间（以前称为更新顺序）。在发布期间更新 Cloud SQL 实例的周。您可以采取以下做法：

    • Any：维护更新可能会随时进行，但通常会在第 1 周内进行。
    • Week 1：维护在发出维护通知后的 7 到 14 天内进行。
    • Week 2：维护更新在发出通知后的 15 到 21 天内进行。
    • Week 5：维护更新在发出维护通知后的 35 到 42 天内进行。

    您可以在配置维护窗口时安排维护更新。

  • 维护窗口。Cloud SQL 安排维护的星期几和时段。维护窗口持续一小时。了解 如何配置维护窗口。

  • 拒绝维护期。Cloud SQL 不安排维护的时间段。您可以设置最长 90 天的拒绝维护期。了解如何配置拒绝维护期。

默认维护窗口

如果您未设置维护窗口，则 Cloud SQL 会根据实例的时区在以下默认窗口中更新实例：

  • 工作日时段（星期一至星期五）：晚上 10 点至早上 6 点
  • 周末时段：星期五晚上 10 点至星期一早上 6 点

维护示例

假设您是管理购物车服务的零售商的开发者。拥有一个用于生产环境的 Cloud SQL 实例，和一个用于预演环境的实例。您希望在实例处理最低流量时（大约在星期日零点）进行维护。您还希望在年末节假日购物旺季跳过维护。

在这种情况下，您需要将生产实例的维护设置设置为：

  • 维护窗口：星期日凌晨 12:00 到凌晨 1:00（美国东部时间）
  • 维护时间：Week 2
  • 拒绝维护期：11 月 1 日到 1 月 15 日。

预演环境的维护设置完全相同，但维护时间设置为 Week 2。这可确保在维护发布正式版之前，您至少在七天内针对维护版本运行操作验收测试。如果在预演环境中出现问题，您将有时间诊断并解决问题，或设置拒绝维护期，以使您的生产环境不受影响。

即将进行的维护通知

在安排维护之前，您可以至少提前一周向您的电子邮件地址发送有关即将进行维护的通知。如果您要为通知设置电子邮件过滤条件，请注意此类通知的电子邮件标题为您的 Cloud SQL 实例 instancename 即将进行维护。

默认情况下，系统不会发送维护通知。您需要选择接收维护通知。您还必须先选择一个维护窗口，然后才能接收通知。

通知会发送到与您的 Google 账号关联的电子邮件地址。无法配置自定义电子邮件别名（例如团队电子邮件别名）。

您可以为给定项目中具有维护窗口的所有 Cloud SQL 实例选择接收维护通知。每个实例接收一条通知。不会为读取副本发送即将进行的维护通知。

您还可以在 Google Cloud 控制台中查看即将进行的维护信息。

  • 在实例列表的维护列中。如果已安排维护，您会看到安排开始进行维护的日期和时间。您可以使用维护一词来过滤实例列表，以查找所有已安排维护的实例。只有在项目中的一个或多个实例已安排维护时，系统才会显示维护列。如果没有安排维护，则该列会隐藏起来。
  • 在实例详情页面的维护窗格中。如果已安排维护，则您会在即将开始下方看到安排开始进行维护的日期和时间。

  • 在 Google Cloud 控制台中的活动页面上，您可以查看已安排进行维护的实例的列表。如果已安排维护，则实例会显示 SQL 维护这一消息以及安排开始进行维护的日期和时间。

重新安排维护时间

如果您的实例具有维护窗口，则您可以在预定的维护更新发生前 24 小时内重新安排维护更新。例如，如果您在预定的维护窗口期间启动了新服务，则可能需要将维护更新推迟到启动后几天内。

重新安排维护更新存在一些限制。Cloud SQL 发出通知电子邮件后，会在为期 7 周的时间段内执行维护更新，以避免与下一个 Cloud SQL 维护更新重叠。例如，如果您选择第 1 周或第 2 周的维护时间，则可以将维护更新重新安排在最初安排日期后的最长 4 周（28 天）内。如果您将实例的维护时间设置为第 5 周，则只能将维护事件重新安排在原始日期后的最长一周（7 天）内。您可以多次重新安排维护，只要重新安排的维护事件在您为实例配置的维护时间定义的重新安排时长内即可。

如需了解所有其他限制，请参阅重新安排限制。

对于新的维护窗口，您可以作出一些安排选择：

  • 立即应用更新。您可以立即将更新应用于实例，而不是等待安排的维护窗口。在这种情况下，维护通常在五分钟内开始。

  • 重新安排到其他时间。您可以通过以下两种方式推迟已安排的维护事件：

    • 下一个可用时段。此选项会将维护推迟到当前安排的维护时间之后的下一个可用维护窗口（通常是一周以后）。
    • 特定时间。借助此选项，您可以选择您为实例配置的维护时间定义的重新安排时长内的特定时间。
      • 如果您选择第 1 周或第 2 周的维护时间，则为 28 天
      • 如果您选择第 5 周的维护时间，则为 7 天

如需了解如何重新安排维护，请参阅重新安排计划内维护。

维护方式

为了使维护简单明了，Cloud SQL 使用维护故障切换工作流，该工作流与我们高可用性实例的自动故障切换工作流非常相似。

简而言之，步骤如下所示：

  1. 使用新软件设置更新后的虚拟机。
  2. 在原始虚拟机上停止数据库。
  3. 将磁盘和静态 IP 切换到更新后的虚拟机。
  4. 在更新后的虚拟机上启动数据库。

浏览以下各个标签页，查看工作流（包括维护前和维护后）的详细信息。

维护前

在维护前，客户端通过静态 IP 地址与原始虚拟机进行通信。数据存储在挂接到原始虚拟机的永久性磁盘上。在此示例中，Cloud SQL 实例已配置高可用性，这意味着另一个虚拟机将处于待命状态，一旦出现计划外服务中断就接管工作。Cloud SQL 实例处理流向应用的流量。

显示维护前状态的示意图

第 1 步

设置新虚拟机。

使用最新的数据库软件和虚拟机操作系统 (OS) 设置新的虚拟机 (VM)。更新后的虚拟机操作系统已启动。此时，数据库引擎尚未启动。对于高可用性实例，还会设置新的备用虚拟机。

通过在原始 Cloud SQL 实例仍在处理流量时在另一个虚拟机上安装软件更新，总停机时间会大大缩短。

显示设置虚拟机的示意图

第 2 步

在原始虚拟机上停止数据库。

数据库引擎会关停，以便磁盘与原始虚拟机分离并挂接到更新后的虚拟机。关停之前，数据库引擎会等待几秒钟，以便提交正在进行的事务，并请求排空现有连接。之后，所有未结或长时间运行的事务都将回滚。数据库停止接受新连接，并且现有连接将被丢弃。实例将变为不可用，并且维护停机开始。

故障切换后的实例示意图

第 3 步

切换到更新后的虚拟机。

该磁盘与原始虚拟机分离，并挂接到更新后的虚拟机。静态 IP 地址已重新配置为指向更新后的虚拟机。 这可确保该应用在维护后使用的 IP 地址与之前相同。数据库缓存与原始虚拟机被淘汰，这意味着数据库缓存会在维护期间被有效清除。

切换到更新后的虚拟机示意图

第 4 步

在更新后的虚拟机上启动数据库。

更新后的数据库引擎将在数据磁盘上启动。使用通用数据磁盘可确保维护之前写入原始实例的所有事务在维护后仍存在于维护后的更新数据库中。如果在数据库关停期间有任何未完成的事务没有回滚，数据库会自动进行崩溃恢复，以确保数据库恢复为可用状态。

启动更新后的虚拟机的示意图

维护后

在第 4 步后，Cloud SQL 实例可以接受连接，并恢复为处理流向应用的流量。

对于应用而言，除了更新后的软件之外，Cloud SQL 实例看起来一样。应用仍使用相同的静态 IP 地址连接到 Cloud SQL 实例，并且更新后的虚拟机与原始虚拟机在同一个可用区中运行。写入原始数据库的所有数据都会保留。

维护后的示意图

最大限度降低维护的影响

通常，Google Cloud 建议在云端运行应用的用户使其系统能够适应暂时性错误，即由于暂时不可用而导致的瞬时服务间通信问题。云中偶发的暂时性错误无法避免。

维护期间发生的一些瞬时错误会丢弃连接并导致传输中事务失败。如果您设计系统并调整应用以使其能够适应暂时性错误，那么也可以最大限度地减少因数据库维护而产生的影响。

为了最大限度地降低连接中断的影响，您可以使用连接池。虽然池程序与数据库之间的连接会在维护期间中断，但应用与池程序之间的连接会保留。这样，重新建立连接工作对于应用是透明的，并分流到连接池程序。

为减少事务失败的情况，您可以限制长时间运行的事务的数量。将查询重写为更小、更高效不仅可减少维护停机时间，还可以提高数据库性能和可靠性。

如需从连接中断和事务失败中高效恢复，您可以高效地管理数据库连接。您可以使用指数退避算法将连接和查询重试逻辑构建到您的应用和连接池程序中。如果查询失败或连接中断，系统会在重试之前建立一个等待期，每次后续重试都会增加等待期。例如，系统可能只需等待几秒钟即可进行第一次重试，但在第四次重试时可能最多等待一分钟。遵循此模式可确保这些故障得以纠正，而不会使服务过载。

其他广告素材解决方案还可以最大限度地降低维护影响，例如使用脚本在维护后预热数据库缓存以简化数据库中的表数。我们建议遵循数据库管理最佳做法和操作指南，以确保维护顺利。

对时间敏感的维护

在极少数情况下，Cloud SQL 可能需要将维护工作安排在维护设置之外，以修补时间敏感的严重稳定性问题或漏洞。这些更新会快速交付，而 Cloud SQL 会根据服务等级协议 (SLA) 将相应的时间计为停机时间。

自助维护

Cloud SQL 会定期通过可在实例上安装的新维护版本来发布软件改进和安全漏洞的补丁。Cloud SQL 会为每个数据库引擎主要版本维护 Cloud SQL 维护更改日志。如需了解详情，请参阅 Cloud SQL 维护更新日志。

虽然 Cloud SQL 每隔几个月安排一次维护更新，以确保您拥有最新的软件，但在以下情况下，您可以使用自助维护来使实例保持最新：

  • 您需要在下一次计划维护事件之前进行更新。
  • 您想要在跳过最近的维护更新后使用最新软件。

如果您使用读取副本，则可以使用自助维护来更新所有读取副本。您需要指定主实例，维护请求会将主实例的所有读取副本更新到指定的维护版本。然后，主实例会更新到该维护版本。

维护限制

本部分介绍了 Cloud SQL 维护的限制。

重新安排限制

关于重新安排，您需要了解以下几点：

  • 您必须在最初安排的维护事件发生前至少 24 小时重新安排维护。

  • 您可以为项目中的一个或多个实例重新安排维护。但是，您一次只能重新安排一个实例（无法批量进行重新安排）。

  • 您可以将维护重新安排在拒绝维护期内的时间，甚至在维护窗口外，只要重新安排时长在您为实例配置的维护时间定义的时间段内即可。

  • 如果维护操作正在进行，则重新安排会延迟到操作完成为止。

拒绝维护期限制

关于拒绝维护期，您需要了解以下几点：

  • 即使您没有为实例配置维护期，也可以设置拒绝维护期。拒绝维护期可能从 1 天到 90 天不等。

  • 拒绝维护期优先于任何计划的维护期。如果某维护窗口的时间与拒绝维护期之间存在冲突，则拒绝维护期会覆盖该维护窗口。

  • 拒绝维护期和维护时间是独立的功能。如果您为维护时间为 Week 1 的实例创建了拒绝维护期，则不会影响确定维护时间为 Week 2 的实例的预定更新。如果预定维护更新在拒绝维护期内，则 Cloud SQL 不会针对您已配置维护时间的那些实例发出通知。

  • 在主实例上设置拒绝维护期后，还会拒绝与主实例关联的所有副本的维护。例如，位于区域 A 的主实例有三个读取副本：两个位于区域 A，另一个位于区域 B。在主实例上设置拒绝维护期后，在主实例的拒绝维护期结束之前，每个副本（包括位于区域 B 的副本）都不会得到维护。

  • 如果在安排维护后设置拒绝维护期，因此拒绝维护期与计划维护时间重叠，则跳过更新。

  • 通过不在开始和结束日期参数中添加年份，您可以将拒绝维护期设置为每年重复。如果指定了年份，则表示您仅为该年份设置拒绝维护期。

  • 您可以在一年中设置多个拒绝维护期。我们建议您避免将拒绝期连在一起，以跳过连续的计划维护事件。及时了解 Cloud SQL 维护非常重要，可确保您的实例可靠运行。通常，Cloud SQL 维护会每隔几个月安排一次。

  • 为了确保服务可靠性，Cloud SQL 可能会通知运行超过 12 个月的维护版本的实例的用户，需要进行下一次维护发布。

  • 拒绝维护期结束后，定期维护行为会继续进行。

  • 拒绝维护期不会影响用户触发的操作，例如自助维护。

维护常见问题解答

维护对旧版高可用性故障切换实例有何影响？

旧版高可用性故障切换实例会关停进行维护更新。它们会在主实例之前收到维护更新。您不能直接对旧版高可用性故障切换实例设置维护窗口，因为该实例与主实例的维护窗口相同。

维护停机时间是否计入 SLA？

由于正常维护造成的停机时间不计入 SLA。但是，Cloud SQL 会根据 SLA 的要求，将时间敏感型维护的停机时间计算在内。

维护对读取副本有何影响？

  • Cloud SQL 始终在主实例之前维护只读副本。 如果主实例具有维护期，只读副本会遵循相同的维护期。
  • 如果主实例具有多个只读副本，Cloud SQL 可能会同时更新某些副本。
  • 读取副本会遵循为主实例设置的拒绝维护期。

我可以取消计划性维护吗？

您无法取消计划的维护窗口，但可以重新安排。您还可以配置一个与计划性维护时间重叠的拒绝维护期，以产生跳过维护的实际效果。

如果维护事件被取消，会发生什么情况？

如果 Cloud SQL 取消维护事件，您将在可能的情况下提前收到维护被取消的通知。

维护事件重新安排后，您会收到有关即将进行维护的新通知。

Cloud SQL 维护是否是累积的？

维护更新是累积的。您无需应用可能错过的每一次维护更新。最新的维护版本会在下一次预定维护更新时应用。或者，您也可以使用自助维护来应用最新的维护更新。

如果实例在预定维护更新期间停止，会发生什么情况？

如果实例在预定维护更新期间停止，则 Cloud SQL 会跳过维护更新。不过，当您下次重启实例时，Cloud SQL 会自动使用最新的维护更新来更新实例。

对主实例的所有读取副本执行自助维护需要多长时间？

自助维护更新所需的时间取决于主实例的读取副本总数。为了减少自助维护更新可能需要的时间，您可以单独更新一些读取副本，然后对主实例执行更新以更新其余的读取副本。

第二个更新会跳过任何已具有目标维护版本的副本。

如果主实例有多个读取副本，我可以对单个读取副本执行自助维护吗？

可以，您可以对单个读取副本实例执行自助维护。但是，我们建议您之后尽快将其余的读取副本和主实例更新到同一维护版本。我们建议您使用相同的维护版本来运行所有读取副本和主实例。

后续步骤