Amazon Aurora 存储和可靠性 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

Amazon Aurora 存储和可靠性

接下来,您可以了解 Aurora 存储子系统。Aurora 使用分布式的共享存储架构,这是影响 Aurora 集群的性能、可扩展性和可靠性的一个重要因素。

Aurora 存储概述

Aurora 数据存储在集群卷 中,该集群卷是使用固态驱动器 (SSD) 的单个虚拟卷。集群卷由跨一个 Amazon 区域中的三个可用区的数据副本组成。由于数据会自动跨可用区复制,因此,数据具有高持久性,同时数据丢失的可能性很小。此复制还确保您的数据库在故障转移期间更可用。这样做是因为数据副本已存在于其他可用区中并且继续响应对数据库集群中数据库实例的数据请求。复制的数量与集群中的数据库实例数量无关。

集群卷包含的内容

Aurora 集群卷包含所有用户数据、架构对象和内部元数据,例如系统表和二进制日志。例如,Aurora 在集群卷中存储一个 Aurora 集群的所有表、索引、二进制大对象 (BLOB)、存储过程等。

Aurora 共享存储架构使您的数据独立于集群中的数据库实例。例如,您可以快速添加数据库实例,因为 Aurora 不会创建表数据的新副本。相反,数据库实例连接到已包含所有数据的共享卷。您可以从集群中删除数据库实例,而无需从集群中删除任何基础数据。仅当您删除整个集群时,Aurora 才会删除数据。

Aurora 存储如何自动调整大小

Aurora 集群卷随着数据库中数据量的增加自动增大。Aurora 集群卷可增大到最大 128 tebibytes (TiB)。这种自动存储扩展与高性能和高分布式存储子系统相结合。当您的主要目标是可靠性和高可用性时,这些使 Aurora 成为您重要的企业数据的理想选择。

要显示卷状态,请参阅 显示 Aurora MySQL 数据库集群的卷状态显示 Aurora PostgreSQL 数据库集群的卷状态。有关平衡存储成本与其他优先级的方法,存储扩展 介绍了如何监控 CloudWatch 中的 Amazon Aurora 指标 AuroraVolumeBytesLeftTotalVolumeBytesUsed

删除 Aurora 数据后,将释放为该数据分配的空间。删除数据的示例包括删除或截断表。这种自动减少存储使用量有助于您最大限度地减少存储费用。

注意

此处讨论的存储限制和动态调整大小行为适用于存储在集群卷中的持久性表和其他数据。临时表的数据存储在本地数据库实例中,其最大大小取决于您使用的实例类。

某些存储功能(如集群卷的最大大小和删除数据时自动调整大小)取决于集群的 Aurora 版本。有关更多信息,请参阅存储扩展。您还可以了解如何避免存储问题,以及如何监控集群中分配的存储和可用空间。

Aurora 数据存储的计费方式

即使 Aurora 集群卷最大可增大到 128 tebibytes (TiB),您也只需为在 Aurora 集群卷中使用的空间付费。在早期的 Aurora 版本中,集群卷可以重复使用在删除数据时释放的空间,但分配的存储空间绝不会减少。从 Aurora MySQL 2.09.0 和 1.23.0 以及 Aurora PostgreSQL 3.3.0 和 2.6.0 开始,当删除 Aurora 数据(例如,通过删除表或数据库)时,整个分配的空间将减少相当数量。因此,您可以通过删除不再需要的表、索引、数据库等来减少存储费用。

提示

对于没有动态调整大小功能的早期版本,重置集群的存储使用量涉及到执行逻辑转储和还原到新集群。对于大量的数据,该操作可能需要很长时间。如果您遇到这种情况,请考虑将集群升级到支持卷缩减的版本。

有关 Aurora 数据存储的定价信息,请参阅 Amazon RDS for Aurora 定价

有关如何通过监控集群的存储使用量来最大限度地减少存储费用的信息,请参阅存储扩展。有关 Aurora 数据存储的定价信息,请参阅 Amazon RDS for Aurora 定价

Amazon Aurora 可靠性

Aurora 的设计具有可靠、持久和容错的特点。您可通过执行一些操作(例如,添加 Aurora 副本并将这些副本置于不同的可用区中)来构建 Aurora 数据库集群以提高可用性,Aurora 还包括一些自动化功能,这些功能可使其成为一种可靠的数据库解决方案。

存储自动修复

由于 Aurora 将多个数据副本保留在三个可用区中,因此大大降低了因磁盘故障导致数据丢失的可能性。Aurora 自动检测集群卷包含的磁盘卷中的故障。如果磁盘卷的某个区段发生故障,Aurora 会立即修复该区段。在 Aurora 修复磁盘区段时,它使用集群卷包含的其他卷中的数据以确保已修复区段中的数据最新。因此,Aurora 将避免数据丢失,并减少了执行时间点还原以从磁盘故障恢复的需求。

自动恢复缓存预热

当数据库在关闭后启动或在发生故障后重新启动时,Aurora 将对缓冲池缓存进行“预热”。即,Aurora 会用内存页面缓存中存储的已知常用查询页面预加载缓冲池。这样,缓冲池便无需从正常的数据库使用“预热”,从而提高性能。

Aurora 页面缓存将通过与数据库不同的单独进程进行管理,这将允许页面缓存独立于数据库进行自动恢复。在出现极少发生的数据库故障时,页面缓存将保留在内存中,这将确保在数据库重新启动时,使用最新状态预热缓冲池。

崩溃恢复

Aurora 设计为几乎立即从崩溃中恢复,并继续提供应用程序数据而没有二进制日志。Aurora 在并行线程上异步执行崩溃恢复,以便在发生崩溃后立即打开并使用数据库。

有关崩溃恢复的更多信息,请参阅Aurora 数据库集群的容错能力

下面是二进制日志记录与 Aurora MySQL 上的崩溃恢复的注意事项:

  • 直接在 Aurora 上启用二进制日志记录会影响崩溃后的恢复时间,因为它强制数据库实例执行二进制日志恢复。

  • 所用二进制日志记录的类型影响日志记录的大小和效率。对于相同数量的数据库活动,某些格式会比二进制日志中的其他格式记录更多信息。binlog_format 参数的以下设置会产生不同的日志数据量:

    • ROW – 最多的日志数据

    • STATEMENT – 最少的日志数据

    • MIXED – 中等数量的日志数据,通常提供最佳的数据完整性和性能组合

    二进制日志数据量影响恢复时间。二进制日志中记录的数据越多,数据库实例在恢复过程中就必须处理更多数据,这会增加恢复时间。

  • Aurora 不需要二进制日志来复制数据库集群中的数据或执行时间点恢复 (PITR)。

  • 如果您不需要外部复制的二进制日志 (或外部二进制日志流),我们建议您将 binlog_format 参数设置为 OFF 以禁用二进制日志记录。这样做可以减少恢复时间。

有关 Aurora 二进制日志记录和复制的更多信息,请参阅使用 Amazon Aurora 进行复制。有关不同 MySQL 复制类型的含义的更多信息,请参阅 MySQL 文档中的基于语句和基于行的复制的优点和缺点