使用零停机时间修补 - Amazon Aurora

使用零停机时间修补

对 Aurora MySQL 数据库集群执行升级时可能会在数据库关闭和升级期间发生中断。默认情况下，如果在数据库运行时开始升级，则会丢失数据库集群正在处理的所有连接和事务。如果等到数据库处于空闲状态再执行升级，则可能需要等待很长时间。

零停机时间修补 (ZDP) 功能尝试在 Aurora MySQL 升级期间尽力保留客户端连接。如果 ZDP 成功完成，则应用程序会话将保留，并且数据库引擎将在升级过程中重新启动。数据库引擎重新启动可能会导致吞吐量下降，持续时间从几秒钟到大约一分钟不等。

ZDP 不适用于以下情况：

  • 操作系统（OS）补丁和升级

  • 主要版本升级

ZDP 适用于所有支持的 Aurora MySQL 版本和数据库实例类。

Aurora Serverless v1 或 Aurora 全球数据库不支持 ZDP。

注意

建议仅将 T 数据库实例类用于开发和测试服务器，或其他非生产服务器。有关 T 实例类的更多详细信息，请参阅使用 T 实例类进行开发和测试。

您可以在 MySQL 错误日志中查看 ZDP 期间重要属性的指标。您还可以在 AWS Management Console中的 Events（事件）页面上查看有关 Aurora MySQL 何时使用 ZDP、何时选择不使用 ZDP 的信息。

在 Aurora MySQL 2.10 和更高版本以及版本 3 中，Aurora 可以执行零停机时间补丁，而无论是否启用二进制日志复制。如果启用二进制日志复制，则在 ZDP 操作期间，Aurora MySQL 将自动断开与二进制日志目标的连接。Aurora MySQL 会自动重新连接到二进制日志目标，并在重启完成后恢复复制。

ZDP 还与 Aurora MySQL 2.10 及更高版本中的重启增强功能结合使用。修补写入器数据库实例会同时自动修补读取器。执行修补后，Aurora 将恢复写入器和读取器数据库实例上的连接。低于 Aurora MySQL 2.10 的版本，ZDP 仅适用于集群的写入器数据库实例。

在以下条件下，ZDP 可能无法成功完成：

  • 正在执行长时间运行的查询或事务。如果 Aurora 在此情况下可以执行 ZDP，则将取消所有开放事务，但会保留其连接。

  • 临时表、用户锁定或表锁定正在使用中，例如，在数据定义语言（DDL）语句运行期间。Aurora 会断开这些连接。

  • 存在待处理的参数更改。

如果因以下一个或多个条件导致没有适合执行 ZDP 的时间范围，则修补将恢复为标准行为。

注意

对于低于 2.11.0 的 Aurora MySQL 版本 2 和低于 3.04.0 的版本 3，当存在开放的安全套接字层（SSL）或传输层安全性（TLS）连接时，ZDP 可能无法成功完成。

尽管成功执行 ZDP 操作后连接保持不变，但一些变量和功能会重新初始化。零停机修补重启后，以下类型的信息将不会保留：

  • 全局变量。Aurora 将恢复会话变量，但重启后不会恢复全局变量。

  • 状态变量。特别是，引擎状态报告的正常运行时间值会在使用 ZDR 或 ZDP 机制重启后重置。

  • LAST_INSERT_ID.

  • 表的内存中 auto_increment 状态。重新初始化内存中的自动增量状态。有关自动增量值的更多信息，请参阅 MySQL 参考手册。

  • 来自 INFORMATION_SCHEMA 和 PERFORMANCE_SCHEMA 表的诊断信息。这些诊断信息也会显示在 SHOW PROFILE 和 SHOW PROFILES 等命令的输出中。

Events (事件) 页面上报告了以下与零停机时间重启相关的活动：

  • 尝试在零停机的情况下升级数据库。

  • 尝试在零停机的情况下升级数据库已完成。事件会报告该过程花费的时间。事件还会报告在重启期间保留的连接数量以及断开的连接数量。您可以查看数据库错误日志，了解有关重启期间所发生情况的更多详细信息。