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

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

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

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

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

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

应用场景

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

手动重启

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

失效转移

如果您的 Aurora 集群包含一个或多个副本，则如果主写入器实例出现问题，Aurora 会启动失效转移，让其中一个读取器实例接管主实例。通常，Aurora 中的失效转移会在 30 秒内完成。通过使用 Amazon RDS 代理或使用适用于 MySQL 的 Amazon 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 优化及其优势。在执行需要重新启动数据库的计划操作时，或在涉及数据库重新启动的意外不可用时期，这些优化可以缩短工作负载的总体停机时间。默认情况下，这些增强功能在 Amazon Aurora MySQL 3.05 及更高版本中可用，无需执行任何操作即可使用。

立即开始使用 Aurora！

Original URL: https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/

本篇作者