深入理解 Amazon Aurora MySQL 存储空间利用情况

关键要点

在此文中，我们探讨了 Amazon Aurora MySQL 的存储类型、如何监控存储使用情况以及影响存储费用的一些常见因素。特别强调了不同版本的 Aurora MySQL 在处理临时表和存储空间上的不同之处。

Amazon Aurora 是一款完全托管的关系数据库服务，旨在提供企业级数据库的性能、可扩展性和可用性，同时又保持开源数据库的简易性和成本效益。Amazon Aurora MySQL 兼容版与 MySQL 完全兼容，是已经在使用 MySQL 技术的企业的理想选择。

与传统 MySQL 数据库不同，Amazon Aurora MySQL 的存储管理方式有所不同。本文将探讨 Amazon Aurora MySQL 提供的不同存储类型，Aurora 如何使用这些存储类型以及如何监控存储使用情况。我们还将探讨一些可用于估算 Aurora 存储费用的数据库查询和 Amazon CloudWatch 指标。

存储类型

Aurora 有两种类型的存储：

存储类型描述集群卷存储Amazon Aurora MySQL 使用一个共享存储层，该层分布在 AWS 区域内的三个可用区，以提供耐用性、容错性、数据冗余和高可用性。它存储 InnoDB 表和索引、数据库元数据、存储对象如函数和过程以及其他持久数据包括二进制日志和中继日志。本地存储每个 Aurora MySQL 实例都有本地存储卷，由 Amazon Elastic Block StoreAmazon EBS支持。您使用这些本地卷来存储非持久的临时文件和非 InnoDB 临时表、排序大型数据集以及存储不同的引擎日志如错误、审核和通用日志。有关更多信息，请参阅 Aurora MySQL 的临时存储限制。

接下来的部分将讨论在 Aurora MySQL 集群中存储利用的常见来源，以及如何使用数据库指标和元数据来检查存储消耗情况。

用户表、索引和表空间

用户表和索引占用了关系数据库系统中大部分的持久存储空间。在 MySQL 中，存储引擎 是处理不同表类型 SQL 操作的组件。InnoDB 是 MySQL 中的默认通用存储引擎，也是 Amazon Aurora MySQL 唯一支持的持久数据库表存储引擎。因此，我们将仅从 InnoDB 存储引擎的角度讨论存储利用情况。

在传统 MySQL 中，使用 InnoDB 存储引擎的表存储在称为 表空间 的数据文件中，文件扩展名为“ibd”。有关更多信息，请参阅 InnoDB 表空间空间管理。

虽然 Amazon Aurora 并不使用传统文件和基于块的文件系统来存储 InnoDB 数据，但其高层次概念仍然保持一致。Aurora 遵循 InnoDB 表空间的概念，但这些表空间作为对象存在于 Aurora 自定义设计的存储卷中，而不是块存储设备上的文件。

奈云加速器

InnoDB 存储引擎默认使用每表文件的表空间来存储表。这一行为由 innodbfilepertable 参数控制。

当 innodbfilepertable=ON 时，引擎的行为如下：

每个表都有其自己的表空间在传统 MySQL 中相当于 ibd 文件。当一个表空间被删除丢弃时，释放的数据库页面将被释放回存储卷，并可以被新数据重用。Aurora 可以动态地回收这些空闲页面，从而缩小存储卷，增加可用空间并降低存储成本。

存在多种数据库操作可能导致表空间被丢弃，也因此释放出 Aurora 可以回收的页面。这同样适用于表分区，因为每个分区使用独立的表空间：

删除表或模式将导致底层表空间被移除。清空表会用一个空的表空间替换现有表空间，这在技术上与删除并重新创建它相同。优化表通过 OPTIMIZE 或 ALTER将创建一个新表空间并移除旧的表空间。

执行这些操作后，卷的大小不会立即减少。Aurora 将在后台以每天最多 10 TB 的速度逐渐回收空闲空间。有关动态调整大小的更多信息，请参见 存储扩展。

当 innodbfilepertable=OFF 时，行为如下：

表没有各自独立的表空间，而是表数据驻留在系统表空间下。如果您删除、清空或优化表，关联的页面将在系统表空间中被释放，但不会减少系统表空间的大小。因此，Aurora 的动态卷调整不能回收这些页面所占用的空间。

要计算表空间的占用空间，您可以使用 INFORMATIONSCHEMAFILES 表。该表报告 InnoDB 表空间类型的元数据，包括每表表空间、系统表空间、全局临时表空间和撤消表空间。有关 InnoDB 表空间的更多信息，请参阅 表空间。

您可以使用以下查询列出表空间名称及其大小：

sqlSELECT FILENAME TABLESPACENAME ROUND((TOTALEXTENTS EXTENTSIZE) / 1024 / 1024 / 1024 4) AS SIZEGB FROM INFORMATIONSCHEMAFILES ORDER BY sizegb DESC LIMIT 10

该查询适用于 Amazon Aurora MySQL 版本 2兼容 MySQL 57和 Amazon Aurora MySQL 版本 3兼容 MySQL 80。

请注意，即使为空，表空间也具有某种最小大小。当 innodbfilepertable 设置为 ON 时，即使是空表或分区没有行也会占用少量存储，通常为几兆字节。除非您计划在单个 Aurora 集群中存储数千万个表，否则这通常不是一个问题。如果可能，我们建议使用 innodbfilepertable 的默认 ON 设置。

您还应该考虑使用 INFORMATIONSCHEMAFILES 表作为补充或替代来计算表、索引和模式所使用的存储空间，因为 INFORMATIONSCHEMATABLES 表包含的缓存统计信息可能会在未分析表之前过时。系统变量 informationschemastatsexpiry适用于 Aurora MySQL 版本 3定义了缓存统计信息过期的时间段，默认值为 86400 秒24 小时。要强制更新给定表的缓存值，请使用 ANALYZE TABLE 命令，并在此之后检查 INFORMATIONSCHEMATABLES 中的统计信息。请注意，分析表的准确性取决于配置的 innodbstatspersistent 和 innodbstatstransientsamplepages 参数。

临时表和临时表空间

在讨论临时表空间之前，我们首先需要了解临时表、它们的使用场景以及 Amazon Aurora MySQL 版本 2 和版本 3 在临时表处理上的不同。

Aurora MySQL 有两种类型的临时表：

内部或隐式临时表 这些表由数据库引擎自动创建，用于处理诸如排序、聚合、派生表和公共表表达式CTE等操作。数据库用户对这些表没有直接的控制权。有关 MySQL 57 中内部临时表的更多详情，请参见 内部临时表的使用，对于 MySQL 80，请参见 内部临时表的使用。用户创建或显式临时表 这些表由数据库客户端使用 CREATE TEMPORARY TABLE 语句创建。显式临时表仅在创建它们的数据库会话连接中可见，并会在会话关闭时自动删除。这些表适用于存储中间数据，以便在执行复杂 SQL 过程时使用，而这些数据不需要持久化存储。有关 MySQL 57 中这些表的更多细节，请参见 CREATE TEMPORARY TABLE，对于 MySQL 80，请参见 CREATE TEMPORARY TABLE。

Aurora MySQL 版本 2 和版本 3 在临时表的存储机制上存在差异。其中一些差异对性能产生影响，另一些则影响存储消耗。接下来的部分将简要说明与存储相关的差异。有关其他详细信息，请参阅 在 Amazon RDS for MySQL 和 Amazon Aurora MySQL 上使用 TempTable 存储引擎。

Aurora 版本 2兼容 MySQL 57

在 Aurora 版本 2 中，内部临时表可以保存在内存中，并由 MEMORY 存储引擎处理。如果在内存中创建的内部临时表变得过大，MySQL 会自动将其转换为基于磁盘的表。在某些情况下，数据库可能会从一开始就使用基于磁盘的表，例如查询涉及不受 MEMORY 引擎支持的数据类型时例如 BLOB 或 TEXT。基于磁盘的内部临时表的存储引擎是 InnoDB默认或 MyISAM，具体取决于 internaltmpdiskstorageengine 设置。

对于 MySQL 57 的 InnoDB 临时表，引擎使用一个共享的临时表空间，该空间具有自增大小，称为 ibtmp1。有关更多信息，请参见 临时表空间。

要检查临时表空间的大小，可以使用以下查询查询 InformationSchemaFiles 表：

sqlSELECT FILENAME TABLESPACENAME ENGINE INITIALSIZE TOTALEXTENTS EXTENTSIZE AS TotalSizeBytes DATAFREE MAXIMUMSIZE FROM INFORMATIONSCHEMAFILESWHERE TABLESPACENAME = innodbtemporary

默认情况下，临时表空间的数据文件会自动扩展，必要时随着磁盘临时表的增加而增大。

要回收临时表空间占用的磁盘空间，可以重启 Aurora 集群的写入实例。重启写入实例将删除并重新创建临时表空间数据文件。

在 Aurora 版本 2 中，InnoDB 在磁盘上的内部临时表位于临时表空间内位于 Aurora 集群卷上。非 InnoDB 临时表位于 Amazon Aurora MySQL 实例提供的本地存储上。

Aurora 版本 3兼容 MySQL 80

在 Aurora 版本 3 中，内部临时表可以保存在内存中，并由 TempTable 存储引擎默认或 MEMORY 引擎处理。TempTable 存储引擎的限制和存储分配行为由配置参数控制，例如 tmptablesize、temptablemaxram、temptableusemmap 和 temptablemaxmmap。如果内存中创建的内部临时表变得足够大，则 MySQL 会根据这些参数将该表转换为基于磁盘的临时表。在 Aurora MySQL 3x 及更早版本中，可以将用于基于磁盘的内部临时表的存储引擎定义为 InnoDB 或 MyISAM。从 Aurora MySQL 3x 开始，我们仅使用 InnoDB 存储引擎处理基于磁盘的内部临时表。

在 MySQL 80 中，以及相应的 Aurora MySQL 版本 3 中，InnoDB 使用两种类型的 临时表空间：

会话临时表空间 这些表空间用于存储用户创建的临时表和基于磁盘的内部临时表，当 InnoDB 配置为基于磁盘的内部临时表存储引擎时。会话临时表空间从临时表空间池中分配给会话。当会话断开连接时，其临时表空间被截断并释放回池中。在以前的版本中，临时表是在全局临时表空间 (ibtmp1) 中创建的，该空间在临时表被截断或删除后不会将磁盘空间返回给操作系统。全局临时表空间 全局临时表空间 (ibtmp1) 现在存储对用户创建的临时表所做更改的回滚段。此临时表空间数据文件是自动扩展的，并根据需要增大。您可以使用对 Aurora 版本 2 上列出的相同查询来检查此全局临时表空间的大小。

要回收全局临时表空间数据文件占用的磁盘空间，您需要重启 Aurora 集群的写入实例。重启写入实例将删除并重新创建全局临时表空间数据文件。

在 Aurora 版本 3 中，默认情况下，InnoDB 在磁盘上的内部临时表及其临时表空间文件位于 Aurora 集群卷上，而非 InnoDB 临时表和文件则位于 Amazon Aurora MySQL 实例提供的本地存储中。

二进制日志

二进制日志或 binlog包含描述数据库更改的事件，例如表创建操作或表数据的变化。

在 Aurora MySQL 中，二进制日志的应用包括：

从 Aurora MySQL 复制到其他兼容 MySQL 的数据库。使用变更数据捕获CDC工具如 AWS 数据库迁移服务从 Aurora MySQL 复制到非 MySQL 数据库。为多种目的从 Aurora MySQL 中提取 CDC 记录，例如建立 Aurora 与下游消息/事件系统之间的集成。

在 Amazon Aurora MySQL 中，二进制日志默认是禁用的logbin = OFF。您可以通过在集群级别参数组中将 binlogformat 设置为 Mixed、Statement 或 Row 来启用二进制日志。

如果集群上启用了二进制日志，它们所消耗的空间取决于多种因素，包括：

配置的二进制日志保留期。生成的更改量，例如表创建操作或表数据的更改等。在某些情况下，与附加的二进制日志副本有关的问题可能会导致集群卷上的 binlog 空间增加。例如，如果您使用基