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 定价
Amazon Aurora 可靠性
Aurora 的设计具有可靠、持久和容错的特点。您可通过执行一些操作（例如，添加 Aurora 副本并将这些副本置于不同的可用区中）来构建 Aurora 数据库集群以提高可用性，Aurora 还包括一些自动化功能，这些功能可使其成为一种可靠的数据库解决方案。
存储自动修复
由于 Aurora 将多个数据副本保留在三个可用区中，因此大大降低了因磁盘故障导致数据丢失的可能性。Aurora 会自动检测集群卷包含的磁盘卷中的故障。如果磁盘卷的某个区段发生故障，Aurora 会立即修复该区段。在 Aurora 修复磁盘区段时，它使用集群卷包含的其他卷中的数据以确保已修复区段中的数据最新。因此，Aurora 将避免数据丢失，并减少了执行时间点还原以从磁盘故障恢复的需求。
自动恢复页面缓存
在 Aurora 中，每个数据库实例的页面缓存将通过与数据库不同的单独进程进行管理，这将允许页面缓存独立于数据库进行自动恢复。（页面缓存在 Aurora MySQL 上也称为 InnoDB 缓冲池，在 Aurora PostgreSQL 上也称为缓冲区缓存。）
万一发生数据库故障，页面缓存将保留在内存中，这样，当数据库重新启动时，页面缓存中的当前数据页将保持“热”状态。这样，初始查询便无需执行读取 I/O 操作来“预热”页面缓存，从而提高性能。
对于 Aurora MySQL，重新启动和失效转移时的页面缓存行为如下：
-
2.10 之前的版本 – 当写入器数据库实例重新启动时，写入器实例上的页面缓存仍然存在，但读取器数据库实例会丢失页面缓存。
-
2.10 及更高版本 – 您可以重新启动写入器实例，而无需重新启动读取器实例。
-
如果读取器实例在写入器实例重新启动时没有重新启动，则它们不会丢失其页面缓存。
-
如果读取器实例在写入器实例重新启动时重新启动，则它们确实会丢失其页面缓存。
-
-
当读取器实例重新启动时，写入器和读取器实例上的页面缓存都会保留。
-
当数据库集群发生失效转移时，效果与写入器实例重新启动时类似。在新的写入器实例（以前是读取器实例）上，页面缓存仍然存在，但是在读取器实例（以前是写入器实例）上，页面缓存将不存在。
对于 Aurora PostgreSQL，您可以使用集群缓存管理来保留指定读取器实例（在失效转移后会成为写入器实例）的页面缓存。有关更多信息，请参阅通过 Aurora PostgreSQL 的集群缓存管理提供故障转移后的快速恢复。
从计划外重启中恢复
Aurora 设计为几乎可以立即从计划外重启中恢复，并在不使用二进制日志的情况下继续为您的应用程序数据提供服务。Aurora 在并行线程上异步执行恢复，以便在发生计划外重启后使数据库能够打开并立即恢复使用。
有关更多信息，请参阅 Aurora 数据库集群的容错能力 和 进行优化以缩短数据库重启时间：
下面是二进制日志记录与 Aurora MySQL 上的计划外重启恢复的注意事项：
-
直接在 Aurora 上启用二进制日志记录会影响计划外重启后的恢复时间，因为它强制数据库实例执行二进制日志恢复。
-
所用二进制日志记录的类型影响日志记录的大小和效率。对于相同数量的数据库活动，某些格式会比二进制日志中的其他格式记录更多信息。
binlog_format参数的以下设置会产生不同的日志数据量：-
ROW– 最多的日志数据 -
STATEMENT– 最少的日志数据 -
MIXED– 中等数量的日志数据，通常提供最佳的数据完整性和性能组合
二进制日志数据量影响恢复时间。二进制日志中记录的数据越多，数据库实例在恢复过程中就必须处理更多数据，这会增加恢复时间。
-
-
要通过二进制日志记录减少计算开销并缩短恢复时间，您可以使用增强型二进制日志。增强型二进制日志可将数据库恢复时间缩短多达 99%。有关更多信息，请参阅设置增强型二进制日志。
-
Aurora 不需要二进制日志来复制数据库集群中的数据或执行时间点恢复（PITR）。
-
如果您不需要外部复制的二进制日志 (或外部二进制日志流)，我们建议您将
binlog_format参数设置为OFF以禁用二进制日志记录。这样做可以减少恢复时间。
有关 Aurora 二进制日志记录和复制的更多信息，请参阅使用 Amazon Aurora 进行复制。有关不同 MySQL 复制类型的含义的更多信息，请参阅 MySQL 文档中的基于语句和基于行的复制的优点和缺点