优化 Amazon Aurora MySQL 数据库重启时间以减少停机时间

作者：Shagun Arora，发表于 2023年10月25日，来源于 Amazon Aurora

关键要点

在使用 Amazon Aurora MySQL 兼容版 管理您的 AWS 云关系数据库时，确保在计划内和非计划内的停机期间实现高可用性极其重要。作为数据库管理员，您应定期进行数据库维护，包括数据库补丁、升级、更改数据库参数需要手动重启、故障转移等。这些操作都需要在实例重启时造成一定的停机时间。尽管有些维护任务可以被安排为计划性操作，但也可能会由于意外故障或资源调节等非计划事件导致停机，所有这些情况下，数据库都需要重启。

在本文中，我们将讨论在 Aurora MySQL 版本 3 中引入的新优化，旨在减少停机时间并在重启后减少对工作负载的干扰。

数据库重启的挑战

数据库重启往往既破坏性又耗时。重启过程需要初始化多个数据结构，验证各类缓存中的数据以确保一致性，最终打开数据库以处理应用连接。由于上述每个步骤所需时间的差异，准确估算重启所需的时间非常具有挑战性，尤其是在关闭时工作负载动态变化的情况下。例如，如果数据库正在进行长时间运行的事务，并且您在 Aurora MySQL 集群中启用了二进制日志，二进制日志恢复可能会增加整体的停机时间。

在重启过程中，许多内部内存组件需要初始化，其中以 InnoDB 缓冲池初始化为最大。Aurora MySQL 默认将 InnoDB 缓冲池 预配置为实例内存的 75。初始化的时间与缓冲池的大小成正比，因此在该初始化阶段，数据库无法接受连接，导致重启时的停机时间延长。新的 Aurora MySQL 优化主要集中在改善缓冲池初始化过程，以减少数据库的初始化时间，从而缩短整体重启时间。

Aurora MySQL 数据库重启时间优化

新引入的 优化 能够减少由于计划内或非计划重启而造成的数据库停机时间。这些是首批增强，我们将继续评估更多机会来进一步缩短整体重启时间。要深入了解这些改进，让我们从几个与重启相关的术语开始：

以下图表展示了这些术语的图形描述，Y轴为吞吐量，X轴为时间。恢复完成是应用连接重新连接到数据库所需的时间，以及数据库恢复到重启前的吞吐量所需的时间。

新优化的目标如下：

重启阶段所花费的时间可以分为几个组成部分，如 MySQL 初始化、缓冲池初始化和验证、二进制日志及 InnoDB 恢复。我们分析认为，缓冲池初始化是造成较长重启时间的主要因素，因为初始化和验证需要数秒的时间。Aurora MySQL 中的缓冲池采用 可生存页面缓存 方法，每个数据库实例的页面缓存由独立于数据库的进程管理，在数据库发生故障时，页面缓存仍然保留在内存中，确保当前数据页在数据库重启时保持温暖。这使得性能在数据库重启时得到提升，因为初始查询无需额外的读 I/O 操作。

通过这些优化，我们降低了初始化和验证缓冲池所需的时间，将部分流程延后到数据库在线并接受连接后进行。虽然部分缓冲池验证可以与重启一起进行，但重要的验证在数据库开始接受连接之前完成。经过仔细验证，其他非关键步骤在数据库已处于接受连接状态后再进行。此外，我们还优化了锁定结构的内存分配，这也有助于缩短重连时间。这减少了重启时的工作量，最终降低了数据库准备接受连接的停机时间。

随着优化的实施，整体重启速度加快，并在 不同实例大小 中保持一致的重启时间。通过新的改进，您将看到重启相关的整体停机时间减少，在某些情况下还可以避免在完成实例恢复时发生故障转移。借助现有的 零停机重启 功能，集群与读写实例的连接最佳努力保持活跃。

根据我们的测试，新的优化可将数据库重启时间减少多达 65。下面的图表比较了重启后数据库恢复工作负载所需的时间。该图反映了在 dbr524xlarge 实例上进行的仅读工作负载，64 个并发线程。蓝线表示应用了新优化，您可以观察到重连时间与稳态时间之间的差距明显缩小。红线代表未应用新优化的情况，达到稳态吞吐量所需的时间较长。在图中，交易每秒的差异在可读性范围内，仅作为改善图表可读性的参考，并不意味着最新优化增强了 Aurora MySQL 的吞吐量。

我们在使用 sysbench 进行的多种合成工作负载测试中观察到了类似的结果，结合不同的数据集、实例类别、实例大小、客户端线程、表的数量以及工作负载类型读、写或读写的组合。

以下表格比较了不同实例类型的重启时间，在应用以及未应用 Aurora MySQL 优化情况下。以下结果来自sysbench测试，采用了250张表、400万行的只读工作负载。这些重启时间并不是绝对的，可能会因您的工作负载而有所变化。

使用场景

数据库重启可能是由多种原因引起。以下我们将讨论在哪些常见使用场景中，新优化可帮助您的 Aurora MySQL 数据库在重启后更快地恢复并接受连接。如果您的 Aurora 数据库没有频繁重启，或者您对 Aurora MySQL 恢复所需的时间感到满意，根据我们的测试，这些优化不会改变现有的行为，唯一的变化是重连时间的减少。另一方面，如果您偶尔计划维护操作导致重启，那么新的优化可以在这些情况下提供帮助。

手动重启

您可能需要手动重启您的数据库集群，通常出于维护原因。当对附属于您的 Aurora 数据库的自定义参数组中的静态参数进行更改时，也可能需要手动重启以进行同步。手动重启数据库实例会重新启动数据库引擎进程，并会导致瞬时中断。通过新的优化，这些重启时间会被最小化。

故障转移

如果您的 Aurora 集群包含一个或多个副本，则在主写入实例出现问题的情况下，Aurora 将发起 故障转移，让其中一个读取实例接管主实例。通常，Aurora 中的故障转移将在 30 秒内完成。借助 Amazon RDS Proxy 或 AWS JDBC Driver for MySQL，这一时间还可以进一步缩短。在自动或手动故障转移的情况下，会执行数据库重启，而新的 Aurora MySQL 优化提高了这一过程的效率，从而减少了整体停机。此外，我们的测试表明，在某些情况下这些优化还可以帮助避免故障转移，因为实例重启比以前更快。作为最佳实践，请测试和检查您的现有故障转移管理策略，以了解在出现中断后您的应用如何重新连接。

小版本和补丁升级

作为最佳实践，我们建议同步最新的小版本和补丁，具体可见 Aurora MySQL 发布说明，因为它们包含新功能以及额外的安全和稳定性修复。这些升级会导致实例的短暂不可用，而通过新的 Aurora MySQL 优化，小版本和补丁升级时的停机时间将减少。

基础操作系统补丁或硬件故障

如果需要应用基础操作系统补丁以解决安全问题，或者如果您的数据库基础实例发生故障并需要更换主机，您的 Aurora 实例可能需要下线。在这种情况下，可能会触发意外故障转移，而这些优化则降低了由此导致的干扰。

数据库引擎重启

在某些情况下，由于内存不足和更高的复制延迟等问题，实例可能会重启。在这种情况下，现有用户连接将在重启期间断开。Aurora MySQL 优化将进一步减少此类情况的整体停机时间；然而，可能会有一些排除情况详细信息见下节。

重点考虑

截至本文发布之际，这些 Aurora MySQL 增强功能已在 305 及以上版本中默认可用。如果您使用的是较早的 Aurora MySQL 3 版本，可以进行小版本升级至 最新版本。

目前，这些优化减少整体重启时间的原因在于将部分缓冲池验证工作延后到数据库上线后进行。这些改进在较大实例类型上表现得更为明显，因为它们的缓冲池配置相对较大，如 db8xlarge、db12xlarge、db16xlarge、db24xlarge。在这些优化的推动下，由于优先考虑更快使数据库上线，在一些情况下，可能会在缓冲池验证的背景处理中给性能带来几秒钟的影响，因为连接正迅速地进入数据库。

由于数据库重启过程需要处理多个组成部分，这些优化旨在减少缓冲池验证时间，从而加快整体重启时间。然而，在数据库重启过程中，后台也会执行多个步骤以维护事务一致性和整体数据库稳定性。恢复时间通常是动态的，需要在允许用户连接之前执行多个步骤。影响重启时间的可变因素包括启用二进制日志的情况，以及数据库在进行大型事务时的处理，这可能导致更多的数据写入二进制日志，从而导致更长时间的恢复。同样， 表空间发现 也可能在数据库有数千至数百万张表时发生。虽然这些因素在大多数场景下不会影响结果，但在一些极端情况下，可能导致数据库可接受连接前额外增加几秒钟的停机时间。目前这些优化的设计并未改善数据库执行其他恢复步骤以完成重启过程所需的时间。

结论

在本文中，我们探讨了新的 Aurora MySQL 优化及其带来的好处。这些优化在进行需要重启的计划性操作或遭遇意外不可用时，能够降低工作负载的整体停机时间。这些增强功能在 Aurora MySQL 305 及以后的版本中默认可用，不需要用户采取任何行动即可使用。

立即 开始使用 Aurora 吧！

关于作者

Shagun Arora 是 Amazon Web Services 的数据库专家解决方案架构师。她与客户合作，设计可扩展、高可用和安全的 AWS 云解决方案。

衡量您转型的成功 云企业战略博客

成功衡量您的转型之道关键要点在这篇文章中，我们探讨如何衡量云端及数字转型的成功。强调连结云端计划与企业核心战略目标的重要性。提出多种衡量成本降低、IT交付、商业灵活性及风险减少的方法。如何判断您在云端...