Amazon Aurora 存储
接下来，您可以了解 Aurora 存储子系统。Aurora 使用分布式的共享存储架构，这是影响 Aurora 集群的性能、可扩展性和可靠性的一个重要因素。
Amazon Aurora 存储概述
Aurora 数据存储在集群卷 中，该集群卷是使用固态驱动器 (SSD) 的单个虚拟卷。集群卷由跨一个 Amazon 区域中的三个可用区的数据副本组成。由于数据会自动跨可用区复制，因此，数据具有高持久性，同时数据丢失的可能性很小。此复制还确保您的数据库在故障转移期间更可用。这样做是因为数据副本已存在于其他可用区中并且继续响应对数据库集群中数据库实例的数据请求。复制的数量与集群中的数据库实例数量无关。
Aurora 对非持久性临时文件使用单独的本地存储。这包括用于在查询处理过程对大型数据集进行排序或用于索引构建等用途的文件。有关更多信息，请参阅Aurora MySQL 的临时存储限制 和Aurora PostgreSQL 的临时存储限制。
集群卷包含的内容
Aurora 集群卷包含所有用户数据、架构对象和内部元数据，例如系统表和二进制日志。例如，Aurora 在集群卷中存储一个 Aurora 集群的所有表、索引、二进制大对象 (BLOB)、存储过程等。
Aurora 共享存储架构使您的数据独立于集群中的数据库实例。例如，您可以快速添加数据库实例，因为 Aurora 不会创建表数据的新副本。相反，数据库实例连接到已包含所有数据的共享卷。您可以从集群中删除数据库实例，而无需从集群中删除任何基础数据。仅当您删除整个集群时，Aurora 才会删除数据。
Amazon Aurora 数据库集群的存储配置
Amazon Aurora 有两种数据库集群存储配置：
-
Aurora I/O-Optimized – 提高了 I/O 密集型应用程序的性价比和可预测性。您只需为数据库集群的使用量和存储付费，而无需为读取和写入 I/O 操作支付额外费用。
当您的 I/O 支出占 Aurora 数据库总支出的 25% 或更多时，Aurora I/O-Optimized 是最佳选择。
当您使用支持 Aurora I/O-Optimized 集群配置的数据库引擎版本创建或修改数据库集群时，可以选择 Aurora I/O-Optimized。您可以随时从 Aurora I/O-Optimized 切换到 Aurora Standard。
-
Aurora Standard – 为许多 I/O 使用率适中的应用程序提供经济实惠的定价。除了数据库集群的使用量和存储外，您还需要为每 100 万个 I/O 操作请求支付标准费率。
当您的 I/O 支出低于 Aurora 数据库总支出的 25% 时，Aurora Standard 是最佳选择。
您可以每 30 天从 Aurora Standard 切换到 Aurora I/O-Optimized 一次。从 Aurora Standard 切换到 Aurora I/O-Optimized 或从 Aurora I/O-Optimized 切换到 Aurora Standard 时不会出现停机。
有关 Amazon Web Services 区域和版本支持的信息，请参阅支持集群存储配置的区域和 Aurora 数据库引擎。
有关 Amazon Aurora 存储配置定价的更多信息，请参阅 Amazon Aurora 定价
有关在创建数据库集群时选择存储配置的信息，请参阅创建数据库集群。有关修改数据库集群的存储配置的信息，请参阅Amazon Aurora 设置。
Aurora 存储如何自动调整大小
Aurora 集群卷随着数据库中数据量的增加自动增大。Aurora 集群卷的最大大小为 128 TiB 或 64 TiB，具体取决于数据库引擎版本。有关特定版本最大大小的详细信息，请参阅 Amazon Aurora 大小限制。这种自动存储扩展与高性能和高分布式存储子系统相结合。当您的主要目标是可靠性和高可用性时，这些使 Aurora 成为您重要的企业数据的理想选择。
要显示卷状态，请参阅 显示 Aurora MySQL 数据库集群的卷状态 或 显示 Aurora PostgreSQL 数据库集群的卷状态。有关平衡存储成本与其他优先级的方法，存储扩展 介绍了如何监控 CloudWatch 中的 Amazon Aurora 指标 AuroraVolumeBytesLeftTotal 和 VolumeBytesUsed。
删除 Aurora 数据后，将释放为该数据分配的空间。删除数据的示例包括删除或截断表。这种自动减少存储使用量有助于您最大限度地减少存储费用。
注意
此处讨论的存储限制和动态调整大小行为适用于存储在集群卷中的持久性表和其他数据。
对于 Aurora PostgreSQL，临时表数据存储在本地数据库实例中。
对于 Aurora MySQL 版本 2，在原定设置情况下，临时表数据存储在写入器实例的集群卷中，读取器实例的临时表数据存储在本地存储中。有关更多信息，请参阅 磁盘上的临时表的存储引擎。
对于 Aurora MySQL 版本 3，临时表数据存储在本地数据库实例或集群卷中。有关更多信息，请参阅 Aurora MySQL 版本 3 中的新临时表行为。
驻留在本地存储中的临时表的最大大小受数据库实例的最大本地存储大小限制。本地存储大小取决于您使用的实例类。有关更多信息，请参阅Aurora MySQL 的临时存储限制 和Aurora PostgreSQL 的临时存储限制。
某些存储功能（如集群卷的最大大小和删除数据时自动调整大小）取决于集群的 Aurora 版本。有关更多信息，请参阅 存储扩展。您还可以了解如何避免存储问题，以及如何监控集群中分配的存储和可用空间。
Aurora 数据存储的计费方式
即使 Aurora 集群卷最大可增大到 128 tebibytes (TiB)，您也只需为在 Aurora 集群卷中使用的空间付费。在早期的 Aurora 版本中，集群卷可以重复使用在删除数据时释放的空间，但分配的存储空间绝不会减少。现在，当删除 Aurora 数据（例如，通过删除表或数据库）时，总体分配的空间将减少与之相当的数量。因此，您可以通过删除不再需要的表、索引、数据库等来减少存储费用。
提示
对于没有动态调整大小功能的早期版本，重置集群的存储使用量涉及到执行逻辑转储和还原到新集群。对于大量的数据，该操作可能需要很长时间。如果您遇到这种情况，请考虑将集群升级到支持动态卷大小调整的版本。
有关哪些 Aurora 版本支持动态调整大小以及如何通过监控集群的存储使用量来最大限度地减少存储费用的信息，请参阅 存储扩展。有关 Aurora 备份存储账单的信息，请参阅 了解 Amazon Aurora 备份存储使用量。有关 Aurora 数据存储的定价信息，请参阅 Amazon RDS for Aurora 定价