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