通过亚马逊 Aurora MySQL 数据库重启时间优化减少停机时间

使用 兼容 Amazon Aurora MySQL 的版本 在 亚马逊云科技 云中运行您的关系数据库时，关键要求之一是验证它在计划内和计划外停机期间是否具有高可用性。作为数据库管理员，您应该偶尔进行数据库维护。这可以采取数据库补丁、升级、需要手动重启的数据库参数修改、执行故障转移以缩短更改实例类所需的时间等形式。所有这些操作都需要在实例重启时停机。您可以控制何时将其中一些数据库维护任务应用于您的 Aurora 数据库资源，使其成为有计划的操作。

但是，停机也可能是由计划外事件引起的，例如由于底层硬件故障或数据库资源限制而导致的意外故障转移，以及可能导致 mysqld 数据库引擎重新启动的问题。这两种情况，无论是计划内还是计划外，都会导致数据库重启。

在这篇文章中，我们讨论了 Aurora MySQL 版本 3 中引入的新的 Aurora MySQL 优化，这些优化可以减少停机时间，减少重启后对工作负载的干扰。

数据库重启面临的挑战

数据库重启既会造成中断，又非常耗时。重启包括初始化多个数据结构、验证各种缓存中的数据以保持一致性，最后打开数据库以处理应用程序连接。由于上述每个步骤所花费的时间各不相同，因此很难完全估计完成重启所需的时间。这主要是由数据库重启的恢复方面驱动的，这些恢复方面受关闭时数据库服务器工作负载的动态性质的影响。例如，如果数据库正处于长时间运行的事务中，并且您的 Aurora MySQL 集群 中 启用 了二进制日志 (binlog)，则二进制日志恢复可能会增加总体停机时间。有关更多信息，请参阅 Amazon Aurora 用户 指南 中的 从计划外重启中 恢复 。

在启动过程中，许多内部存储器组件都被初始化，最大的是 InnoDB 缓冲池初始化。在 Aurora MySQL 中， InnoDB 缓冲池 默认预配置为实例内存大小的 75%，初始化时间与 InnoDB 缓冲池的大小成正比。在此初始化阶段，数据库无法接受连接，这会导致重启期间的停机时间更长。新的 Aurora MySQL 优化主要侧重于改进缓冲池初始化过程以缩短数据库初始化时间，从而缩短数据库的整体重启时间。

Aurora MySQL 数据库重启时间优化

Aurora MySQL 3.05 版中 引入@@ 的新优化 减少了计划内或计划外重启可能导致的数据库停机时间。这些是首批增强功能之一，我们将继续评估更多此类机会，以缩短总体重启时间。为了深入研究这些改进，让我们从与重启相关的几个术语开始：

• 重新连接时间 -应用程序因计划内或计划外操作而变得不可用后启动数据库连接所花费的时间。
• 进入稳定状态的时间 -与数据库重新建立连接后，吞吐量恢复到重启之前的水平所花费的时间。
• 稳定状态吞吐量 -这是衡量重启前后数据库读写吞吐量的指标。

下图是对这些术语的图形描述，Y 轴为吞吐量，X 轴为时间。恢复完成是指应用程序连接重新连接到数据库所花费的时间以及数据库在重新启动之前达到以前的吞吐量级别所花费的时间。

新的 Aurora MySQL 优化有以下目标：

• 缩短重新连接的时间
• 尽可能缩小重新连接时间和进入稳定状态的时间之间的差异
• 确认重启后稳定状态吞吐量没有降低

数据库重启期间花费的时间可以分为几个部分，例如 MySQL 初始化、缓冲池初始化和验证、binlog 和 InnoDB 恢复。根据我们对导致更长重启时间的组件的分析，缓冲池初始化是最大的贡献者，需要几秒钟才能进行初始化和验证。如上所述，对于较大的实例类，InnoDB 缓冲池按比例较大。这反过来又意味着更长的缓冲池初始化时间，这可能导致更长的重启时间。

Aurora MySQL 中缓冲池的当前实现采用了 可存活 的页面缓存， 其中每个数据库实例的页面缓存都在与数据库不同的进程中进行管理，这允许页面缓存独立于数据库存活。万一出现数据库故障，这种情况很少发生，页面缓存会保留在内存中，这样当数据库重新启动时，页面缓存中的当前数据页保持 “温暖” 状态。Survivable 页面缓存可提高数据库重启时的性能，因为初始查询无需执行额外的读取 I/O 操作来 “预热” 缓存。

通过这些优化，我们将部分过程推迟到数据库已经在线并接受连接之后，从而缩短了初始化和验证缓冲池所需的时间。虽然某些缓冲池校验可以与重启同时进行，但基本校验发生在数据库开始接受连接之前。经过仔细验证后，其他非关键步骤已安全地推迟到数据库已经接受连接后首次访问页面。此外，我们还优化了锁定结构的内存分配，这也有助于缩短重新连接的时间。这减少了重启时执行的工作，并最终缩短了数据库准备好接受连接之前所经历的停机时间。虽然重新连接的实际时间会更短，但根据您的工作负载，重新连接后可能需要几秒钟才能完成剩余的验证部分。但是，重新连接的时间和进入稳定状态的时间的累积时间仍将小于先前的机制。

这些优化加快了整体重启速度，还使 各种实例大小的 重启时间保持一致。通过新的改进，您将看到与重启相关的总体停机时间减少，在某些情况下，这还可以防止您的 Aurora 集群中的故障转移，因为实例恢复速度会快得多。利用 零停机时间重启 (ZDR) 的现有优势 ，将尽最大努力保留与集群读/写实例的连接。

通过数据库重启优化，Aurora MySQL 尝试缩小重新连接时间和稳定状态时间之间的差距。根据我们的测试，与不进行优化相比，新的优化可将数据库重启时间缩短多达65％。下图比较了数据库在重新启动后恢复其工作负载所花费的时间。该图适用于具有 64 个并发线程的只读工作负载的 db.r5.24xlarge。蓝线与新的优化有关，你可以观察到重新连接的时间和进入稳定状态的时间之间的差距要小得多。红线不包括新的优化，需要更长的时间才能实现稳态吞吐量。在图表中，每秒交易之间的差异在一定误差范围内，以提高图表的可读性，但这并不意味着使用 Aurora MySQL 的最新优化提高了吞吐量。

我们在使用 sysbench 的多个合成工作负载中观察到类似的结果，这些工作负载结合了不同的数据集、实例类、实例大小、客户端线程、表数量和工作负载类型（读取、写入或读写）。

下表显示了各种实例类型的比较以及使用 Aurora MySQL 优化和未进行 Aurora MySQL 优化的重启时间。这些结果是使用只读工作负载的 sysbench 测试中捕获的，该工作负载包含 250 个表，400 万行。这些重启值不是绝对值，可能会因工作负载而异。

用例

数据库重启可能由多种原因引起。在本节中，我们将讨论一些常见用例，在这些案例中，新的优化可以帮助你的 Aurora MySQL 数据库恢复并在重启后更快地提供连接服务。根据我们的测试，如果您没有看到 Aurora 数据库很少重启，或者对 Aurora MySQL 恢复所需的时间感到满意，那么除了缩短重新连接时间外，这些优化不应改变任何现有行为。另一方面，如果您偶尔计划维护操作以导致重启，则新的优化措施可以在这些情况下提供帮助。

手动重启

通常出于维护原因，您可能需要重启数据库集群或集群中的某些实例。对附加到 Aurora 数据库的自定义参数组中的静态参数进行更改时，可能还需要手动重启才能同步任何修改。重启数据库实例会重新启动数据库引擎进程并导致短暂中断。通过新的优化，可以最大限度地缩短这些重启时间。

故障转移

如果您的 Aurora 集群包含一个或多个副本，则如果主写入器实例出现问题，Aurora 会启动 故障转移 ，让其中一个读取器实例接管主实例。通常，Aurora 中的故障转移会在 30 秒内完成。通过使用 亚马逊 RDS 代理 或使用适用于 MySQL 的 亚马逊云科技 JDBC 驱动程序，可以进一步缩短这段时间。 如果发生自动或手动故障转移，则会执行数据库重启，新的 Aurora MySQL 优化对此进行了改进，从而减少了总体停机时间。此外，根据我们的测试，在某些情况下，这些优化还可以帮助防止故障转移，因为实例的重启速度比以前快得多。最佳做法是，使用新的优化来测试和审查现有的故障转移管理实践，以观察应用程序在中断后如何重新连接。

次要版本和补丁升级

作为最佳实践，我们建议您及时了解 Aurora MySQL 发行说明 中发布的次要版本中的最新次要版本和补丁， 因为它们包含新功能以及额外的安全性和稳定性补丁。这些升级会导致一段时间内实例不可用，因为集群中的实例会同时升级。借助新的 Aurora MySQL 优化，次要升级和补丁升级期间的停机时间将减少。

底层操作系统补丁或硬件故障

如果要应用底层操作系统补丁来解决安全问题，或者数据库的底层实例出现故障并需要更换主机，则可能需要使您的 Aurora 实例脱机。在这种情况下，可能会触发意外故障转移，如前所述，这些优化减少了由于这些操作而造成的中断。

数据库引擎重启

在某些情况下，实例可能会由于各种问题（例如内存不足状况和更高的复制延迟问题）而重新启动。在这种情况下，现有用户连接将在重启期间断开。Aurora MySQL 优化也将减少这些场景中的总停机时间；但是，可能存在一些例外情况（如下一节所述）。

关键注意事项

在撰写本博客文章时，Aurora MySQL 3.05 及更高版本的客户默认可以使用和启用这些 Aurora MySQL 增强功能。如果您使用的是 Aurora MySQL 3 的先前版本，则可以执行次要版本升级以获得 最新版本 。

当前，通过这些优化缩短了总重启时间，这是将缓冲池验证的某些部分推迟到数据库联机之后进行的。这些改进在较大的实例类上更为明显，因此这些实例类具有更大的缓冲池，例如 db.8xlarge、db.12xlarge、db.16xlarge、db.24xlarge。通过这些优化，由于当务之急是使数据库更快地联机，在某些情况下，当缓冲池验证在后台进行时，由于在重新启动后与数据库建立连接，可能会影响几秒钟的性能。

由于在数据库重启时会有多个组件发挥作用，因此这些优化旨在减少缓冲池验证时间，从而加快整体重启时间。但是，在数据库重新启动时，需要在后台执行多个步骤来维护事务一致性和数据库的整体稳定性。恢复的时间主要是动态的，因为在允许用户连接之前需要执行多个步骤。影响重启的一些可变因素包括启用了二进制日志且数据库处于大型事务中间的情况，这可能会导致在二进制日志中写入更多数据，并可能导致二进制日志恢复 时间 不一致。 同样，另一个因素是 表空间发现 ，如果数据库有成千上万个表，则可能发生这种发现。尽管这些因素在大多数情况下不会起作用，但在某些边缘情况下，它们可能会导致在数据库可供连接之前多停几秒钟。这些优化的当前设计并不能缩短数据库执行作为重启过程一部分的其他恢复步骤所花费的时间。

结论

在这篇文章中，我们探讨了新的Aurora MySQL优化及其优点。在执行需要重新启动数据库的计划操作时，或在涉及数据库重启的意外不可用时期，这些优化可以缩短工作负载的总体停机时间。默认情况下，这些增强功能在 Aurora MySQL 3.05 及更高版本中可用，无需执行任何操作即可使用它们。

今天@@ 就开始使用 Aurora 吧！

作者简介

Shagun Arora 是亚马逊网络服务的数据库专家解决方案架构师。她与客户合作，在 亚马逊云科技 云中设计可扩展、高度可用和安全的解决方案。