Amazon Aurora
Aurora 用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

Amazon Aurora 存储和可靠性

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

Aurora 存储概述

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

集群卷包含的内容

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

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

Aurora 存储的增长方式

Aurora 集群卷随着数据库中数据量的增加自动增大。Aurora 集群卷可增大到最大 64 tebibytes (TiB)。表大小限制为集群卷的大小。即,Aurora 数据库集群中表的最大表大小为 64 TiB。

当您的主要目标是可靠性和高可用性时,此自动存储扩展与高性能和高度分布式存储子系统相结合,使 Aurora 成为重要企业数据的良好选择。有关平衡存储成本与这些其他优先级的方法,请参阅以下部分。

Aurora 数据存储的计费方式

即使 Aurora 集群卷最大可增大到 64 TiB,您也只需为在 Aurora 集群卷中使用的空间付费。在删除 Aurora 数据时(例如,删除表或分区),整个分配的空间保持不变。在将来数据量增加时,可以自动重用可用空间。

注意

由于存储成本基于存储"高水位"(在任何时间点为 Aurora 集群分配的最大容量),因此,您可以避免采用创建大量临时信息的 ETL 做法以控制成本,或者避免在删除不需要的旧数据之前加载大量新数据的 ETL 做法。

如果从 Aurora 集群中删除数据导致分配大量未使用的空间,则重置高水位需要使用 mysqldump 之类的工具执行逻辑数据转储和还原以转储和还原到新集群。创建和还原快照不会 减少分配的存储,因为基础存储的物理布局在还原的快照中保持不变。

有关 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 文档中的基于语句和基于行的复制的优点和缺点