Amazon Aurora 常见问题

Amazon Aurora 是一项现代关系数据库服务，它能够大规模地提高性能和高可用性，提供完全开源的 MySQL 兼容版和 PostgreSQL 兼容版，以及一系列用于构建无服务器和机器学习（ML）驱动型应用程序的开发工具。

Aurora 采用一种有容错能力并且可以自我修复的分布式存储系统，这一系统与计算资源分离并可以把每个数据库实例自动扩展到最高 256 TiB。它具备高性能和高可用性，支持最多 15 个低延迟只读副本、时间点恢复、持续备份到 Amazon Simple Storage Service (Amazon S3)，还支持跨三个可用区（AZ）复制。

Aurora 也是一项完全托管式服务，该服务使耗时的管理任务（例如硬件调配、数据库设置、修补和备份）自动化，同时以 1/10 的成本提供商用数据库的安全性、可用性和可靠性。

Amazon Aurora 与现有的 MySQL 开源数据库嵌入式兼容，还会定期增加对新版本的支持。这意味着您可以使用标准导入/导出工具或者快照将 MySQL 数据库轻松迁移到和迁移出 Aurora。它意味着，您已用于 MySQL 数据库的代码、应用程序、驱动程序和工具可与 Aurora 配合使用，只需对其进行少量更改或不需要更改。这使得在两个引擎之间迁移应用程序变得非常简单。

您可以在文档中看到最新的 Amazon Aurora MySQL 版本兼容性信息。

Amazon 完全支持 Aurora PostgreSQL 和 Aurora 提供的所有扩展。如果需要 Aurora PostgreSQL 支持，请联系 AWS Support。如果具有有效的 AWS Premium Support 账户，可以联系 AWS Premium Support 解决 Aurora 的特定问题。

Amazon Aurora 与现有的 PostgreSQL 开源数据库嵌入式兼容，还会定期增加对新版本的支持。这意味着您可以使用标准导入/导出工具或者快照将 PostgreSQL 数据库轻松迁移到和迁移出 Aurora。它意味着，您已用于 PostgreSQL 数据库的大多数代码、应用程序、驱动程序和工具可与 Aurora 配合使用，只需对其进行少量更改或无需更改。

您可以在文档中看到最新的 Amazon Aurora PostgreSQL 版本兼容性信息。

要试用 Aurora，请登录 AWS 管理控制台，选择“数据库”类别下的 RDS，然后选择 Amazon Aurora 作为您的数据库引擎。有关详细的指导和资源，请查看我们的开始使用 Aurora 页面。

您可以在此处查看 Aurora 的区域可用性。

如果您想从 PostgreSQL 迁移到 Aurora（或反之亦然），则有几种选择：

• 您可以使用标准的 pg_dump 实用工具将数据从 PostgreSQL 中导出，使用 pg_restore 实用工具将数据导入 Aurora，反之亦然。
• 您还可以使用 RDS 数据库快照迁移功能通过 AWS 管理控制台将 Amazon RDS for PostgreSQL 数据库快照迁移到 Aurora 中。

虽然持续时间取决于格式和数据集大小，但对于大多数客户而言，迁移到 Aurora 的过程可在一小时内完成。

为将 SQL Server 数据库迁移到 Amazon Aurora PostgreSQL 兼容版，您可以使用适用于 Aurora PostgreSQL 的 Babelfish。您的应用程序将继续工作，不做任何更改。请参阅 Babelfish 文档了解更多信息。

如果您想从 MySQL 迁移到 Aurora（或反之亦然），则有几种选择：

• 您可以使用标准的 mysqldump 实用工具将数据从 MySQL 中导出，并使用 mysqlimport 实用工具将数据导入 Aurora，反之亦然。
• 您还可以使用 Amazon RDS 数据库快照迁移功能通过 AWS 管理控制台将 Amazon RDS for MySQL 数据库快照迁移到 Aurora 中。

虽然持续时间取决于格式和数据集大小，但对于大多数客户而言，迁移到 Aurora 的过程可在一小时内完成。有关更多信息，请参阅将 MySQL 数据库迁移到 Amazon Aurora 的最佳实践。

不需要，Aurora 适用于标准的 PostgreSQL 数据库驱动程序。

Amazon Aurora 通过将数据库引擎与为数据库工作负载构建的基于 SSD 的虚拟化存储层紧密集成，减少存储系统的写入操作，最大程度降低锁竞争并消除数据库进程线程所产生的延迟，使性能大幅超过 MySQL。

我们根据 SysBench 对 r3.8xlarge 实例进行的测试表明，Amazon Aurora 每秒提供超过 500000 次选择和 100000 次更新，是在同一硬件上运行相同基准的 MySQL 的五倍。有关此基准的详细说明以及如何自行复制此基准，请参阅 Amazon Aurora MySQL 兼容版性能基准指南。

Amazon Aurora 通过将数据库引擎与为数据库工作负载构建的基于 SSD 的虚拟化存储层紧密集成，使性能大幅超过 PostgreSQL，从而减少至存储系统的写入操作，最大程度降低锁竞争并消除数据库进程线程所产生的延迟。

我们根据 SysBench 对 r4.16xlarge 实例进行的测试表明，Amazon Aurora 每秒提供的选择和更新次数，是在同一硬件上运行相同基准的 PostgreSQL 的三倍。有关此基准的详细说明以及如何自行复制此基准，请参阅 Amazon Aurora PostgreSQL 兼容版性能基准指南。

Amazon Aurora 的设计与 MySQL 兼容，因此现有 MySQL 应用程序和工具无需修改即可运行。然而，Amazon Aurora 优于 MySQL 的一点就是具有大量并行工作负载。为了在 Amazon Aurora 上最大限度地提高您的工作负载吞吐量，我们建议您构建自己的应用程序来支持大量并行查询和事务。

由于 Amazon Aurora 与 PostgreSQL 兼容，因此现有 PostgreSQL 应用程序和工具无需修改即可运行。然而，Amazon Aurora 优于 PostgreSQL 的一点就是具有大量并行工作负载。为了在 Amazon Aurora 上最大限度地提高您的工作负载吞吐量，我们建议您构建自己的应用程序来支持大量并行查询和事务。

有关最新定价信息，请参阅 Aurora 定价页面。

目前没有针对 Aurora 提供的 AWS Free Tier。但是，Aurora 会将您的数据持久存储在一个区域的三个可用区中，并且仅对一个数据副本收费。对于最多不超过数据库集群 100% 大小的的备份，您无需支付任何费用。在为数据库集群配置的备份保留期内，您也不需要为快照付费。

是的，您可以为您使用的 Amazon Aurora 购买数据库节省计划，当您承诺在 1 年期限内保持稳定的使用量时，成本可降低多达 35%。 有关符合条件的使用量的更多信息，请参阅数据库节省计划定价页面。

不是，Aurora 复制已包含在价格中。我们将根据数据库在数据库层消耗的存储量向您收费，而非 Aurora 的虚拟存储层消耗的存储量。

I/O 操作由 Aurora 数据库引擎依靠基于 SSD 的虚拟化存储层执行。每个数据库页面读取操作计为一个 I/O。
Aurora 数据库引擎依靠存储层发出读取，以获取不在缓存内的存储器中的数据库页面：

• 如果您的查询流量完全可从存储器或缓存中提供，则您从存储器检索任何数据页面的操作都不收取费用。
• 如果您的查询流量无法完全从内存中提供，则需要从存储中检索的任何数据页面都将产生收费。
  Amazon Aurora MySQL 兼容版中的每个数据库页面均为 16KB，每个 Aurora PostgreSQL 兼容版中的每个数据库页面均为 8KB。

Aurora 的目的是移除不必要的 I/O 操作，以降低成本，并确保资源可服务于读/写流量。只有在为了使写入持久而将 Aurora MySQL 兼容版中的重做日志记录或 Aurora PostgreSQL 兼容版中的写前日志记录永久保存到存储层时，才会使用写入 I/O 操作。

写入 I/O 操作以 4KB 为单位计算。例如，1,024 字节的日志记录计为一个写入 I/O 操作。但是，如果日志记录超过 4KB，则将需要一个以上写入 I/O 操作才能使其永久存在。

日志记录小于 4KB 的并发写入操作可能通过 Aurora 数据库引擎批量进行，以便优化 I/O 消耗。与传统数据库引擎不同，Aurora 从不会将脏数据页刷新到存储。

您可以在 AWS 管理控制台看到 Aurora 实例消耗的 I/O 请求数量。要查询 I/O 消耗，请转到控制台的 Amazon RDS 部分，查看您的实例列表，选择 Aurora 实例，然后在监控部分查找“VolumeReadIOPs”和“VolumeWriteIOPs”指标。

有关 I/O 操作定价的更多信息，请访问 Aurora 定价页面。将数据库集群配置为 Aurora Standard 配置时，您需要为读取和写入 I/O 操作付费。将数据库集群配置为 Amazon Aurora I/O 优化版时，无需为读取和写入 I/O 操作付费。

Aurora 可以根据您的性价比和价格可预测性需求在两个配置选项之间进行选择，从而灵活地优化数据库支出。这两个配置选项是 Aurora Standard 和 Aurora I/O-Optimized。这两个选项都不需要预先预置 I/O 或存储资源，而且两者都可以扩展 I/O 操作以支持最苛刻的应用程序。

Aurora Standard 是一种数据库集群配置，可为绝大多数 I/O 使用率低到中等的应用程序提供经济实惠的定价。使用 Aurora Standard，您可以为数据库实例、存储和按请求付费 I/O 付费。

Aurora I/O-Optimized 是一种数据库集群配置，可为支付处理系统、电子商务系统和金融应用程序等 I/O 密集型应用程序提供更高的性价比。此外，如果您的 I/O 支出超过 Aurora 数据库总支出的 25%，则使用 Aurora I/O-Optimized 的 I/O 密集型工作负载成本最多可节省 40%。Aurora I/O 优化版为所有应用程序提供可预测的定价，因为读取和写入 I/O 操作不收取任何费用，这使得该配置非常适合 I/O 可变性大的工作负载。

当您需要为任何应用程序提供可预测的成本时，Aurora I/O 优化版是理想的选择。它为需要高写入吞吐量或运行处理大量数据的分析查询的 I/O 密集型应用程序提供了更高的性价比。对于 I/O 支出超过 Aurora 账单 25% 的客户，使用 Aurora I/O 优化版最多可使 I/O 密集型工作负载成本节省 40%。

您可以使用 AWS 管理控制台中提供的一键式体验，将现有数据库集群的存储类型更改为 Aurora I/O-Optimized。您也可以调用 AWS 命令行界面（AWS CLI）或 AWS SDK 来进行此更改。

您可以每 30 天将现有数据库集群切换到 Aurora I/O-Optimized。您可以随时切换回 Aurora Standard。

是的，Aurora I/O-Optimized 适用于现有的 Aurora 预留实例。对于预留实例，Aurora 会自动考虑 Aurora Standard 和 Aurora I/O-Optimized 之间的价格差异。借助 Aurora I/O 优化版实现的预留实例折扣，您可以进一步节省 I/O 支出。

使用 Aurora I/O 优化版进行回溯、快照、导出或持续备份的价格没有变化。

是的，跨区域复制数据所需的 I/O 操作将继续收取费用。Aurora I/O 优化版不对读取和写入 I/O 操作收费，这与数据复制不同。

除了基于 Intel 的 R6id 和基于 Graviton 的 R6gd 实例的价格之外，适用于 Aurora PostgreSQL 的 Amazon Aurora 优化型读取不收取任何额外费用。有关更多信息，请访问 Aurora 定价页面。

最低存储为 10 GiB。根据您的数据库使用量，您的 Aurora 存储将以 10 GiB 的增量自动增长到 256 TiB，而不会影响数据库的性能。 无需提前预置存储。 Aurora 借助 Amazon Aurora PostgreSQL Limitless Database 提供自动水平扩缩功能，可将存储扩展到 256 TiB 以上。要了解更多信息，请访问使用 Aurora PostgreSQL Limitless 数据库。

可以通过三种方法扩展与 Amazon Aurora DB 关联的计算资源：使用 Amazon Aurora Serverless、Aurora PostgreSQL Limitless Database 或手动扩展。无论您选择哪种选项，都只需按实际使用量付费。

您可以使用 Aurora Serverless（一项适用于 Aurora 的按需弹性伸缩配置）来基于应用程序需求扩展数据库计算资源。它有助于在云中运行数据库，而无需担心数据库容量管理。您可以指定所需的数据库容量范围，且数据库将根据应用程序的需求进行扩缩。请在 Aurora Serverless 用户指南中阅读更多信息。

使用 Aurora PostgreSQL Limitless Database，您可以根据工作负载要求自动水平扩展计算资源，以支持高规模应用程序。它可以帮助您将应用程序扩展到单个数据库实例的写入吞吐量和存储限制之外，同时保持在单个数据库内操作的简便性。 

您还可以通过在 AWS 管理控制台中选择所需的数据库实例类型，手动扩展与数据库关联的计算资源。您请求的更改将在您指定的维护窗口期间应用，或者您可以使用“立即应用”标记立即更改数据库实例类型。

Amazon Aurora 数据库实例上始终都会启用自动备份。备份不影响数据库性能。

能，拍摄快照时不影响性能。请注意，从数据库快照中恢复数据需要创建一个新的数据库实例。

Amazon Aurora 可跨一个区域的三个可用区（AZ）自动维护您的数据持久性，并将自动尝试在运行状况正常的可用区恢复您的数据库，而不会造成数据丢失。您的数据不太可能在 Amazon Aurora 存储内不可用，您可以从数据库快照中进行恢复或对新实例执行时间点还原操作。请注意，时间点还原操作的最迟可还原时间在过去最长可达 5 分钟。

您可以选择在删除数据库实例时创建最终的数据库快照。如果您进行了此操作，您可以使用此数据库快照稍后恢复已删除的数据库实例。在您删除数据库实例后，Amazon Aurora 会将用户创建的这个最终数据库快照与其他所有人工创建的数据库快照一起保留。删除数据库实例后只会保留数据库快照（即，为时间点恢复创建的自动备份不会保留）。

能。借助 Aurora，您可以创建数据库快照，用于以后恢复数据库。您可以与不同的 AWS 账户共享这一快照，并且对方可以使用您的快照来恢复包含您的数据的数据库。您甚至还可以将您的快照公开，这样，任何人都能恢复包含您的（公开）数据的数据库。

您可以使用此功能在拥有不同 AWS 账户的各种环境（生产、开发/测试、分段等）之间共享数据，也可以将所有数据的备份安全保存到一个单独的账户中，以防主 AWS 账户受到安全威胁。

在账户之间共享快照不需要付费。但是，您需要为快照本身以及通过共享快照恢复的任何数据库付费。详细了解 Aurora 定价。

我们不支持自动共享数据库快照。要共享快照，您必须手动创建快照的副本，然后共享该副本。

您可以将手动快照共享给最多 20 个 AWS 账户 ID。如果您需要将快照共享给 20 个以上的账户，则可以将快照公开，或联系支持人员要求增加配额。

您可以将您的 Aurora 快照共享到支持 Aurora 的每个 AWS 区域。

不能，只有与分享快照的账户处于同一区域内的账户才能访问您共享的 Aurora 快照。

能，您可以共享加密的 Aurora 快照。

Amazon Aurora 会将您的数据库卷分成分散在很多个磁盘上的 10 GB 的区段。每 10GB 的数据库卷组块都能在三个可用区间用六种方法进行复制。Amazon Aurora 的设计可透明应对多达两个数据副本的损失，而不会影响数据库写入可用性，还能在不影响读取可用性的情况下应对多达三个副本。

Amazon Aurora 存储还具有自我修复能力。可连续扫描数据块和磁盘有无出错并自动将其修复。

与其他数据库不同的是，Amazon Aurora 在数据库崩溃之后不需要重放最后一个数据库检查点（通常为 5 分钟）的重做日志，且不需要在数据库可用于操作之前确认所有更改都已应用。在大多数情况下，这会将数据库的重启时间缩短到 60 秒以下。

Amazon Aurora 会将缓冲缓存移出数据库进程，并在重启时使其立即可用。这将防止您限制访问，直到重新填充缓存以避免停止。

Aurora MySQL 兼容版和 Amazon Aurora PostgreSQL 兼容版都支持 Amazon Aurora 副本，这些副本与同一 AWS 区域内的主实例共享相同的底层卷。主实例作出的更新对所有的 Amazon Aurora 副本可见。

借助 Amazon Aurora MySQL 兼容版，您还可以根据 MySQL 基于二进制日志的复制引擎创建跨区域复制的 MySQL 只读副本。在 MySQL 只读副本中，您的主实例中的数据会作为事务在您的副本上重放。对于大多数使用案例，包括读取扩展和高可用性，我们推荐使用 Amazon Aurora 副本。

您可以根据您的应用程序需求灵活地混合搭配这两种副本类型。

除了上面列出的选项之外，还有其他两个复制选项。您可以使用 Amazon Global Database 在不同区域的 Aurora 集群之间实现更快的物理复制。对于 Aurora 与非 Aurora MySQL 兼容版数据库之间的复制（甚至在 AWS 之外），您可以设置自己的自我管理的二进制日志复制。

能，您可以通过物理或逻辑复制功能来设置跨区域 Aurora 副本。物理复制也称为Amazon Aurora Global Database，它使用专用基础设施，使您的数据库完全可用于为应用程序提供服务，并且可以复制最多五个辅助区域，典型延迟时间不到一秒。Aurora MySQL 兼容版和 Aurora PostgreSQL 兼容版均可提供。

为确保低延迟全球读取和灾难恢复，我们建议使用 Amazon Aurora Global Database。
Aurora 支持各种数据库引擎的原生逻辑复制（MySQL 和 PostgreSQL 的二进制日志以及 PostgreSQL 的复制槽），因此您可以复制到 Aurora 和非 Aurora 数据库，甚至可以跨区域复制。

Aurora MySQL 兼容版还提供方便易用的逻辑跨区域只读副本功能，最高可支持五个辅助 AWS 区域。此功能基于单线程的 MySQL 二进制日志复制操作，复制滞后时间会受到更改/应用速度以及所选区域之间的网络通信延迟影响。

能。您可以在每个跨区域集群上添加最多 15 个 Aurora 副本，它们将与跨区域副本共享相同的底层存储。跨区域副本将成为该集群上的主副本，集群上的 Aurora 副本通常比主副本滞后 10 毫秒。

能。您可以通过 Amazon RDS 控制台将跨区域副本提升为主副本。对于逻辑（二进制日志）复制，提升过程一般需要几分钟，具体取决于您的工作负载。启动提升过程后，跨区域复制将会停止。

使用 Amazon Aurora Global Database，您可以在一分钟内提升辅助区域以获取完整的读/写负载。

能。您可以为群集中的每个实例指定一个提升优先级分层。如果主实例发生故障，Amazon RDS 会将优先级最高的副本提升为主实例。如果两个或多个 Aurora 副本优先级相同，则 Amazon RDS 将提升最大的那个副本。如果两个或多个 Aurora 副本优先级和大小均相同，则 Amazon RDS 将提升同一提升分层中的任意副本。

有关失效转移逻辑的更多信息，请阅读 Amazon Aurora 用户指南。

能。您随时可以修改实例的优先级分层。单纯地修改优先级分层并不会触发失效转移。

如果您不希望某个副本被提升为主实例，可为其指定较低的优先级分层。不过，如果群集上优先级较高的副本因为某些原因无法运行或使用，那么 Amazon RDS 将提升优先级较低的副本。

您可以添加 Amazon Aurora 副本。同一 AWS 区域中的 Aurora 副本与主实例共享同一个底层存储。任何 Aurora 副本都可在不损失任何数据的情况下被提升为主实例，因此，它可用于在主数据库实例发生故障时提高容错能力。

要想提高数据库可用性，只需在 3 个可用区的任何一个创建 1 到 15 个副本，且 Amazon RDS 将在发生数据库运行中断时自动将其纳入故障转移主选择中。如果您希望数据库跨越多个 AWS 区域，可以使用 Amazon Aurora Global Database。这样可以在不影响数据库性能的情况下复制您的数据，并从区域范围的中断中进行灾难恢复。

Amazon Aurora 会自动处理失效转移，以便您的应用程序可以尽快恢复数据库操作，而无需人工管理干预。

• 如果您在相同或不同的可用区中有 Aurora 副本，在进行失效转移时，Aurora 会翻转您的数据库实例的规范名称记录（CNAME），以指向运行状态正常的副本，此副本会晋升为新的主实例。从开始到结束，失效转移通常会在 30 秒内完成。为了提高弹性并加快失效转移，可以考虑使用 Amazon RDS 代理，它可以在保留应用程序连接的同时自动连接到失效转移数据库实例。代理使失效转移对您的应用程序透明，并将失效转移的时间减少多达 66%。 
• Aurora Serverless v2 的工作方式与为失效转移和其他高可用性功能配置的一样。有关更多信息，请参阅 Aurora Serverless v2 和高可用性。
  
• 如果您没有 Aurora 副本（即单个实例），也未运行 Aurora Serverless，则 Aurora 会先尝试在原始实例的可用区中新建数据库实例。原实例会尽量替换，但可能不会成功，例如出现全面影响该可用区的问题时。

您的应用程序应会在连接丢失时重试数据库连接。跨区域进行灾难恢复是一个手动过程，在此期间，您可以提升辅助区域以获取读/写工作负载。

Amazon Aurora 将自动检测主实例中的问题并触发失效转移。如果您使用的是集群端点，您的读取/写入连接将自动重新导向至将被晋升为主实例的 Amazon Aurora 副本。

此外，您的 Aurora 副本提供的读取流量将短暂中断。如果您使用集群读取器终端节点将读取流量定向至 Aurora 副本，则只读连接将定向至新晋升的 Aurora 副本，直到原主节点恢复为副本时为止。

能，您可以在 Aurora MySQL 兼容版实例和外部 MySQL 数据库之间设置二进制日志复制。另一个数据库可以在 Amazon RDS 上运行，或作为自我管理的数据库在 AWS 上运行，或完全在 AWS 之外运行。

如果您运行的是 Aurora MySQL 兼容版 5.7，请考虑设置基于 GTID 的二进制日志复制。这将提供完全一致性，即使在故障转移或停机后，您的复制也不会错过事务或生成冲突。

Amazon Aurora 副本与同一 AWS 区域内的主实例共享同一个数据卷，因此几乎没有复制滞后。据我们观察，滞后时间一般在 10 毫秒内。

对于跨区域复制，基于 binlog 的逻辑复制滞后可根据更改/应用速度以及网络通信的延迟无限增长。不过，一般情况下，1 分钟以内的复制滞后是很常见的。使用 Amazon Aurora Global Database 物理复制的跨区域副本通常有不到一秒的滞后时间。

Amazon Aurora Global Database 是一项支持单个 Amazon Aurora 数据库跨越多个 AWS 区域的功能。它可以在不影响数据库性能的情况下复制您的数据，支持在每个区域中实现快速本地读取，典型延迟时间不到一秒，并可从区域范围的中断中进行灾难恢复。在不太可能发生区域性性能下降或中断的情况下，它可以在不到 1 分钟的时间内将辅助区域提升为具有完全读/写功能。Aurora MySQL 兼容版和 Aurora PostgreSQL 兼容版均可提供该功能。

您只需在 Amazon RDS 控制台上单击几下即可创建 Aurora Global Database。此外，你可以使用 AWS 软件开发工具包（SDK）或 AWS Command-Line Interface（CLI）。您可以在主区域和辅助区域之间使用预置或无服务器实例类类型的混合配置。您也可以将主区域配置为 Aurora I/O 优化版集群，将辅助区域配置为 Aurora Standard，反之亦可。要了解更多信息，请访问创建 Amazon Aurora Global Database。

您可以为 Amazon Aurora Global Database 创建最多五个辅助区域。

可以。如果您的目标是分析数据库活动，请考虑使用 Aurora 高级审计、常规日志和慢速查询日志，以免影响数据库性能。

不会。如果主区域不可用，您可以使用托管的跨区域 Aurora Global Database 失效转移操作来升级辅助区域，以获得完全读写能力。您也可以使用 Aurora Global Database 写入器端点，这样，无需更改应用程序代码即可连接到新升级的区域。要了解更多信息，请访问连接 Amazon Aurora Global Database。

能，所有 Amazon Aurora 数据库实例都必须在 VPC 中创建。借助 Amazon VPC，您可以定义一个与自己数据中心内运行的传统网络非常相似的虚拟网络拓扑。这样一来，您可以对谁能访问您的 Amazon Aurora 数据库进行完全控制。

能。Amazon Aurora 使用 SSL（AES-256）保护数据库实例与应用程序之间的连接。Amazon Aurora 可让您使用通过 AWS Key Management Service（AWS KMS）管理的密钥加密您的数据库。

在通过 Amazon Aurora 加密运行的数据库实例上，静态存储于底层存储的数据都将加密，同一集群的自动备份、快照和副本也是如此。加密和解密操作的处理都是无缝的。有关将 AWS KMS 与 Amazon Aurora 一起使用的更多信息，请参阅 Amazon RDS 用户指南。

目前不支持加密现有的未加密 Aurora 实例。要将 Amazon Aurora 加密用于现有的未加密数据库，请在启用加密的情况下创建一个新数据库实例，并将您的数据迁移到该实例中。

必须通过您在创建数据库时输入的数据库端口访问 Aurora 数据库。这就为您的数据安全性提供了另外一层保护。有关如何连接到 Amazon Aurora 数据库的分步说明，请参阅 Amazon Aurora 连接指南。

是的，MySQL 兼容版和 PostgreSQL 兼容版 Aurora 都符合 HIPAA 要求。您可以依照与 AWS 签署的商业伙伴附录（BAA），用其构建符合 HIPAA 要求的应用程序，并存储医疗保健相关信息，包括受保护的健康信息（PHI）。如果您已与 AWS 签署 BAA，可以即刻开始在 BAA 协议涵盖的账户内使用这些服务。关于使用 AWS 构建合规应用程序的更多信息，请参阅医疗保健提供商。

现在，您可以在 Amazon Aurora 安全更新中找到 CVE 列表。

Aurora 与 Amazon GuardDuty 集成，帮助您识别存储在 Aurora 数据库中的数据的潜在威胁。GuardDuty RDS Protection 分析和监控您账户中新数据库的登录活动，并使用定制的 ML 模型来检测对 Aurora 数据库的可疑登录。有关更多信息，请参阅使用 GuardDuty RDS Protection 监控威胁和 GuardDuty RDS Protection 用户指南。

Aurora Serverless 是 Amazon Aurora 的一种按需自动扩展配置。 使用 Aurora Serverless，无需管理数据库容量即可在云中运行数据库。手动管理数据库容量可能很耗时，也可能导致数据库资源的使用效率低下。借助 Aurora Serverless，您可以创建数据库，指定所需的数据库容量范围，然后连接您的应用程序。Aurora 根据应用程序的需要，在指定的范围内自动调整容量。

您需要为数据库处于活动状态时所使用的数据库容量按每秒支付费用。请了解有关 Aurora Serverless 的更多信息，并通过在 Amazon RDS 管理控制台中执行几个步骤开始使用。

可在此处查看 Aurora Serverless v2 兼容性信息。

能，您可以将快照从现有 Aurora 预置的群集还原到 Aurora Serverless 数据库群集（反之亦然）。

您可以通过在相同 VPC 中运行的客户端应用程序访问 Aurora Serverless 数据库集群。您不能为 Aurora Serverless 数据库指定公有 IP 地址。

虽然 Aurora 无服务器会根据活动数据库工作负载自动进行扩展，但是在某些情况下，容量的扩展速度可能不足以应对工作负载的突然变化，例如大量新事务。在这种情况下，您可以借助 AWS 管理控制台、AWS CLI 或 Amazon RDS API 将容量明确设置为具体的值。

扩展操作启动后，Aurora Serverless 会尝试寻找扩展点，数据库可在该时间点安全完成扩展。如果您有长期运行的查询或正在处理的事务，或正在使用临时表或表格锁定，那么 Aurora Serverless 可能无法找到扩展点。

是，您可以开始使用 Aurora Serverless v2 在您现有的 Aurora 数据库集群中管理数据库计算容量。同时包含预置实例以及 Aurora Serverless v2 的集群称为混合配置集群。您可以选择在集群中使用任何预置实例和 Aurora Serverless v2 的任何组合。

要测试 Aurora Serverless v2，您可以在 Aurora 数据库集群中添加一个读取器，然后选择 Serverless v2 作为实例类型。当读取器创建且可用时，您可以开始将它用于只读工作负载。一旦确认读取器按预期工作，您就可以启动故障转移，以开始将 Aurora Serverless v2 进行读写操作。此选项为开始使用 Aurora Serverless v2 提供了最低停机时间体验。

Aurora Serverless v2 支持预置 Aurora 的所有功能，包括只读副本、多可用区配置、Aurora Global Database、RDS Proxy 和性能详情。

在 Aurora Serverless 中，数据库容量按 Aurora 容量单位（ACU）计算。您按每秒的 ACU 使用量支付统一价格。在 Aurora Serverless 上运行工作负载的计算成本将取决于选择的数据库集群配置：Aurora Standard 或 Aurora I/O-Optimized。访问 Aurora 定价页面，了解有关定价和区域可用性的信息。

Aurora PostgreSQL Limitless Database 提供自动水平扩缩功能，每秒可处理数百万个写入事务并管理 PB 级数据，同时保持在单个数据库内操作的简便性。您可以专注于构建高规模应用程序，而无需构建和维护复杂的解决方案来跨多个数据库实例扩展数据以支持您的工作负载。Aurora PostgreSQL Limitless Database 根据您的应用程序工作负载进行扩展，您只需为应用程序使用的部分付费。要了解更多信息，请访问 Aurora PostgreSQL Limitless Database 用户指南。

对于需要水平扩展且需要超出单个 Aurora 数据库实例支持的写入吞吐量或数据存储容量限制的应用程序，您应该使用 Aurora PostgreSQL Limitless Database。例如，会计应用程序可以由用户水平分区，因为每个用户的会计数据都独立于其他用户。Aurora PostgreSQL Limitless Database 会自动扩展以支持您最大且增长最快的应用程序。 

现有的扩展功能有两种：使用 Aurora 副本和 Aurora Serverless v2 的 Amazon Aurora 自动扩缩。

Aurora 副本允许您增加 Aurora 集群的读取容量，使其超出单个数据库实例所能提供的限制。能够将读取工作负载与写入工作负载分开的应用程序可以受益于多达 15 个读取副本，从而实现更高的总体读取吞吐量。Aurora 副本不需要应用程序水平拆分其数据。所有数据在每个副本中都可用。Aurora 副本不会增加 Aurora 集群的存储容量或写入吞吐量。

Aurora Serverless v2 是 Aurora 的按需垂直扩缩配置，可根据应用程序需求在单个计算实例的容量限制内自动扩缩数据库计算和内存。写入器和读取器实例均支持 Aurora Serverless v2。但是，它不会增加 Aurora 集群的存储容量。如果您的应用程序设计为水平扩展，Aurora PostgreSQL Limitless Database 允许您将数据库的写入吞吐量和存储容量扩展到单个 Aurora 写入实例的限制之外

Aurora PostgreSQL Limitless Database 使用表列中客户指定的值（也称为分片键）跨数据库实例拆分数据。例如，可以使用 User-ID 列作为分片键来拆分存储用户信息的表。从本质上讲，Aurora PostgreSQL Limitless Database 是无服务器节点的分布式部署。节点是路由器或分片。路由器管理数据库的分布式特性。每个分片存储数据的一个子集，从而支持并行处理以实现高写入吞吐量。

随着计算或存储需求的增加，Aurora 首先自动扩展每个实例及其相关存储，然后扩展以提供不同分片键值的数据库工作负载。在任何时候，分片键值都由单个无服务器实例拥有和提供。当应用程序连接到 Aurora PostgreSQL Limitless Database 并发出请求时，首先会分析该请求。然后，将其发送到拥有请求指定的分片键值的计算实例，或者协调跨多个实例的查询。

多个计算实例（每个实例提供不同的分片键值）可以同时为同一 Aurora PostgreSQL Limitless Database 提供应用程序请求。Aurora PostgreSQL Limitless Database 提供与单写入器 Aurora PostgreSQL 系统相同的事务语义，从而消除了在应用程序中管理不同事务域的复杂性。

Aurora PostgreSQL Limitless Database 支持三种包含数据的表：分片表、参考表和标准表。

分片表：这些表分布在多个分片中。数据根据表中指定列的值（称为分片键）在分片之间进行拆分。它们对于扩展应用程序中最大、I/O 最密集的表非常有用。

参考表：这些表会在每个分片上完整复制数据，这样就可以消除不必要的数据移动，从而加快连接查询的速度。它们通常用于不经常修改的参考数据，例如产品目录和邮政编码。

标准表：这些表与常规 Aurora PostgreSQL 表类似。标准表全部放在一个分片上，因此可以消除不必要的数据移动，从而加快连接查询的速度。您可以从标准表创建分片表和参考表。

要了解有关 PostgreSQL 兼容性注意事项的更多信息，请访问 Aurora PostgreSQL Limitless Database 要求和注意事项。

您可以在 Amazon RDS 控制台或 Amazon API 中开始使用 Aurora PostgreSQL Limitless Database，以使用受支持的引擎版本创建新的 Aurora PostgreSQL 集群。要了解有关入门的更多信息，请访问 Aurora PostgreSQL Limitless Database 用户指南。

将您的应用程序连接到 Aurora PostgreSQL Limitless 数据库的方式与连接到标准 Aurora PostgreSQL 集群的方式相同。您只需连接到集群端点即可。要了解更多信息，请访问使用 Aurora PostgreSQL Limitless 数据库。

是的，您可能需要调整数据库架构才能使用 Aurora PostgreSQL Limitless Database。所有分片表都需要包含分片键，因此可能需要回填这些数据。例如，会计应用程序可能使用 User-ID 列按用户拆分其数据，因为每个用户都独立于其他用户。虽然用户表本身自然包含此
列，但其他表可能不包含，例如包含发票明细项目的表。由于这些表也需要按用户拆分以共置表以实现最佳查询性能，因此需要将 User-ID 列添加到表中。

用于拆分数据的列没有命名约束，但列定义必须匹配。您需要将分片键添加到应用程序查询中，并且可能还需要调整查询和事务以获得最佳性能。例如，当表仅按用户 ID 拆分时，使用发票 ID 查找发票会很慢，因为查询需要在所有数据库实例上执行。但是，如果查询还指定了用户 ID，则查询将被路由到包含该用户 ID 的所有订单的单个数据库实例，从而减少查询的延迟。

可以。当您将 Aurora PostgreSQL Limitless Database 的计算冗余度设置为大于零时，您可以选择高可用性选项，从而提供 99.99% 的可用性。每个存储和访问 Aurora PostgreSQL Limitless Database 数据的计算实例都可以有一个或两个备用实例，当主实例不可用时，它们可以接管请求。路由器将自动重定向流量，以最大限度地减少对您的应用程序的影响。

Aurora PostgreSQL Limitless Database 适用于兼容 PostgreSQL 16.4 的 Aurora I/O 优化版集群配置。有关 Aurora PostgreSQL Limitless Database 的 AWS 区域可用性的更多信息，请参阅 Aurora 定价页面。

在 Aurora PostgreSQL Limitless Database 中，数据库容量以 ACU 为单位。您按每秒的 ACU 使用量支付统一价格。适用 Aurora I/O 优化版配置存储费率。有关更多信息，请访问 Aurora 定价页面。

Amazon Aurora Parallel Query 是指，能够将单个查询的计算负载下移并分布到 Aurora 存储层中的数千个 CPU 的功能。如果不使用 Parallel Query，则对 Amazon Aurora 数据库发出的查询将全部在数据库集群的一个实例中执行；这与大多数数据库的运作方式类似。

Parallel Query 非常适合需要新数据和良好查询性能的分析工作负载，即使在大型表上也是如此。这种类型的工作负载在本质上通常是可操作的。

Parallel Query 可将分析查询的运行速度提高多达 2 个数量级。它提供操作简易性和数据新鲜度：您可以直接对 Aurora 集群中的当前事务数据发出查询。并且，Parallel Query 启用同一数据库上的事务工作负载和分析工作负载：Parallel Query 允许 Aurora 可以在处理并行分析查询的同时保持较高的事务吞吐量。

对不在缓冲池中的大型数据集的大多数查询的运行速度都有望提高。初始版本的 Parallel Query 可以下移并扩展超过 200 个 SQL 函数、等值连接和投影的处理。

特定查询的运行速度提高程度取决于有多少查询计划会被下移到 Aurora 存储层。据客户报告，查询延迟降低了不止一个数量级。

有可能。但我们认为很少会出现这种情况。

不需要更改查询语法。查询优化器可以自动确定是否使用 Parallel Query 来运行特定查询。要查看查询是否在使用 Parallel Query，您可以通过运行 EXPLAIN 命令来查看查询执行计划。如果您想绕过启发式算法并且强制使用 Parallel Query 进行测试，则需要使用 aurora_pq_force 会话变量。

可使用 aurora_pq 参数在全局和会话级别动态启用和禁用 Parallel Query。

没有。除了您已经支付的实例、I/O 和存储费用之外，无需再支付任何费用。

不会。查询产生的 Parallel Query I/O 费用在存储层进行计算，启用 Parallel Query 后， I/O 费用可能保持不变，也可能会增加。您可以获得的益处是查询性能得到提高。

使用 Parallel Query 后，有两个原因可能会导致 I/O 费用增加。第一，即使表中的一些数据在缓冲池中， Parallel Query 要求在存储层扫描所有数据，从而产生 I/O。第二，避免缓冲池中资源争用的一个影响是运行 Parallel Query 查询不会预热缓冲池。因此，连续运行相同的 Parallel Query 会重复产生 I/O 费用。

请参阅文档中的 Parallel Query 了解更多信息。

否。目前，您可以将 Parallel Query 与 R* 实例系列中的实例结合使用。

Parallel Query 并行查询适用于 Amazon Aurora 的 MySQL 5.7 和 MySQL 8.0 兼容版。

Parallel Query 与 Aurora Serverless v2 和 Backtrack 兼容。

否。虽然我们预计 Parallel Query 在大多数情况下都可以降低查询延迟，但 I/O 费用可能会增加。我们建议您通过启用和禁用功能充分测试您的工作负载。如果您确信 Parallel Query 是正确的选择，则可以依靠查询优化器自动确定哪些查询将使用 Parallel Query。在极少数情况下，优化器不能做出最佳选择，此时您可以覆盖这一设置。

Aurora Parallel Query 不是数据仓库，也不提供此类产品通常具有的功能。这项功能旨在提高关系数据库上的查询性能，而且适用于运营分析（当您需要对数据库中的新数据执行快速分析查询时）等使用场景。

对于 EB 级的云数据仓库，请考虑 Amazon Redshift。

适用于 Aurora PostgreSQL 的 Amazon Aurora 优化型读取是一种具有性价比的新选项，与没有该选项的实例相比，可实现高达 8 倍的查询延迟改进和高达 30% 的成本节省。它非常适合具有超出数据库实例内存容量的大型数据集的应用程序。

Amazon Aurora 优化型读取实例使用基于 NVMe 的本地 SSD 块级存储（在基于 Graviton 的 r6gd 和基于 Intel 的 r6id 实例上可用）来改善数据集超出数据库实例内存容量的应用程序的查询延迟。优化型读取包括性能增强功能，例如分层缓存和临时对象。

分层缓存可为操作控制面板、异常检测和基于向量的相似性搜索等需要大量读取的 I/O 密集型应用程序提供高达 8 倍的查询延迟改进和高达 30% 的成本节省。这些好处是通过自动将从内存数据库缓冲区缓存中逐出的数据缓存到本地存储中，从而加快对该数据的后续访问来实现的。分层缓存仅适用于采用 Aurora I/O 优化型配置的 Amazon Aurora PostgreSQL 版本。

临时对象通过将 Aurora PostgreSQL 生成的临时表放置在本地存储上来实现更快的查询处理，从而提高涉及排序、哈希聚合、高负载联接和其他数据密集型操作的查询的性能。

适用于 Aurora PostgreSQL 的 Amazon Aurora 优化型读取为具有延迟敏感型应用程序和大型工作集的客户提供了一种极具性价比的替代方案，可满足其业务 SLA 并利用其实例执行更多操作。

Amazon Aurora 优化型读取可在基于 Intel 的 R6id 和基于 Graviton 的 R6gd 实例上使用。您可以在此处查看 Aurora 的区域可用性。

Amazon Aurora 优化型读取适用于 R6id 和 R6gd 实例上的 Aurora PostgreSQL 兼容版本。Aurora PostgreSQL 支持的引擎版本为 15.4 及更高版本以及 14.9 及更高版本。

Amazon Aurora 优化读取在 Aurora Serverless v2（ASv2）上不可用。

是的，这两种配置都支持 Amazon Aurora 优化型读取。在这两种配置上，启用了优化型读取的实例都会自动将临时表映射到基于 NVMe 的本地存储，以提高分析查询和索引重建的性能。

对于需要进行大量读取的 I/O 密集型工作负载，Aurora PostgreSQL 上启用优化型读取的实例配置为使用 Aurora I/O 优化版自动缓存从基于 NVMe 的本地存储上的内存中逐出的数据。对于具有超出数据库实例内存容量的大型数据集的应用程序，与未启用该功能的实例相比，可提供高达 8 倍的查询延迟改进以及高达 30% 的成本节省。

客户可以通过 AWS 管理控制台、CLI 和软件开发工具包开始使用 Amazon Aurora 优化型读取。默认情况下，所有 R6id 和 R6gd 实例均提供优化型读取功能。要使用此功能，客户只需修改现有的 Aurora 数据库集群以包含 R6id 和 R6gd 实例，或使用这些实例创建新的数据库集群。请参阅 Amazon Aurora 优化型读取文档以开始使用。

R6id 和 R6gd 实例上大约 90% 的可用本地存储可用于优化型读取，Aurora 保留 10% 的 NVMe 存储以减少 SSD 写入放大的影响。可用存储的分配取决于已启用的优化型读取功能。

将优化型读取与临时对象和分层缓存功能结合使用时，本地存储中可用于临时对象的空间相当于这些数据库实例上可用内存大小的两倍。这与 Aurora PostgreSQL 上临时对象存储的当前大小相匹配。剩余的本地存储磁盘空间可用于缓存数据。

将优化型读取与临时对象功能结合使用时，所有可用的本地存储磁盘空间都可用于临时对象。例如，当使用同时具有临时对象和分层缓存功能的 r6gd.8xlarge 实例时，为临时对象保留 534GiB（2 倍内存容量），为分层缓存保留 1054GiB。

如果本地存储出现故障，Aurora 会自动执行主机更换。在多节点数据库集群中，这会触发区域内失效转移。

如果发生数据库失效转移，则失效转移后，查询延迟将暂时增加。这种延迟增加将随着时间的推移而减少，并最终降至失效转移之前的查询延迟水平。通过启用集群缓存管理（CCM），可以缩短恢复期。使用 CCM，客户可以将特定的 Aurora PostgreSQL 数据库实例指定为失效转移目标。

启用 CCM 后，指定失效转移目标的本地存储缓存会密切镜像主实例的本地存储缓存，从而缩短失效转移后的恢复时间。但是，如果指定的失效转移目标也用于服务与写入器实例上的工作负载分开的读取工作负载，则启用 CCM 可能会影响本地存储缓存的长期功效。

因此，运行需要将读取器指定为备用失效转移的工作负载的客户必须启用 CCM，以提高在失效转移后快速恢复查询延迟的可能性。在启用 CCM 之前，在其指定的失效转移目标上运行单独工作负载的客户可能希望在失效转移后的即时延迟恢复需求与缓存性能的长期有效性之间取得平衡。

pgvector 是 PostgreSQL 的开源扩展，由 Amazon Aurora PostgreSQL 兼容版本提供支持。

您可以使用 pgvector 在数据库中存储、搜索、索引和查询由机器学习（ML）和人工智能（AI）模型生成的数十亿个嵌入，例如来自 Amazon Bedrock或 Amazon SageMaker 的嵌入。向量嵌入是一种数字表示法，表示文本、图像和视频等内容的语义含义。

使用 pgvector，您可以查询 Aurora PostgreSQL 数据库中的嵌入，对这些数据类型（以向量表示，与 Aurora 中的其他表格数据相结合）执行有效的语义相似度搜索。这使得生成式人工智能和其他 AI/ML 系统能够用于新型应用，例如基于相似文本描述或图像的个性化推荐、基于面试笔记的候选人匹配、聊天机器人和基于成功记录或聊天会话对话的客户服务下一个最佳行动建议等等。 

阅读我们关于向量数据库功能的博客，了解如何使用 pgvector 扩展在 Aurora PostgreSQL 数据库中存储嵌入，创建交互式问答聊天机器人，以及如何使用 pgvector 和 Aurora 机器学习之间的原生集成进行情感分析。

可以。 Aurora 机器学习（ML）将机器学习模型作为 SQL 函数公开，允许您使用标准 SQL 来调用 ML 模型，向其传递数据，并将预测作为查询结果返回。pgvector 要求将向量嵌入存储在数据库中，这需要在源文本或图像数据上运行 ML 模型以生成嵌入，然后将嵌入批量移动到 Aurora PostgreSQL 中。

Aurora ML 可以将上述流程实时化，方法是通过定期调用 Amazon Bedrock 或 Amazon SageMaker，从模型中返回最新的嵌入，从而使嵌入在 Aurora PostgreSQL 中保持最新。

可以。可以通过两种方法将 Amazon Aurora 数据库与 Amazon Bedrock 集成以支持生成式人工智能应用程序。首先，Amazon Aurora ML 可以通过 SQL 直接访问 Aurora MySQL 和 Aurora PostgreSQL 中可用的 Amazon Bedrock 基础模型。其次，您只需单击一下即可将 Aurora 配置为 Amazon Bedrock 知识库中的向量存储，并将从 Bedrock 生成的嵌入存储在 Aurora 上。Amazon Bedrock 知识库支持 Aurora PostgreSQL 作为检索增强生成（RAG）等使用案例的向量存储。阅读我们关于使用 Aurora PostgreSQL 作为 Amazon Bedrock 知识库的博客和文档。

带有 pgvector 的 Amazon Aurora PostgreSQL 优化型读取功能将超过可用实例内存的工作负载中向量搜索的每秒查询次数提高了多达 9 倍。这是可能的，因为优化型读取中提供了分层缓存功能，该功能会自动将从内存数据库缓冲区缓存中逐出的数据缓存到本地存储上，以加快该数据的后续访问速度。

阅读我们的博客和文档，了解如何使用 Aurora Optimized Reads 提高 Aurora PostgreSQL 的查询性能。

当您需要近乎实时地访问事务数据时，应该使用 Amazon Aurora 与 Amazon Redshift 的零 ETL 集成。这种集成允许您通过简单的 SQL 命令来利用 Amazon Redshift ML。

通过 Amazon Aurora 与 Amazon SageMaker 的零 ETL 集成，您可以近乎实时地将运营数据库和应用程序中的数据导入到湖仓中。通过 SageMaker 的湖仓架构，您可以在现有数据资产基础上构建开放湖仓，无需改变现有数据架构，并可使用 SQL、Apache Spark、BI 及 AI/ML 工具等首选分析工具与查询引擎。

Aurora 与 Amazon Redshift 的零 ETL 集成适用于 Aurora MySQL 3.05.2 版本（兼容 MySQL 8.0.32）及更高版本的 Aurora MySQL 兼容版。Aurora 与 Amazon Redshift 的零 ETL 集成在 Aurora PostgreSQL 兼容版本 Aurora PostgreSQL 16.4 及更高版本上提供。

Aurora 与 Amazon SageMaker 的零 ETL 集成适用于 Aurora MySQL 3.05.0 版本（兼容 MySQL 8.0.32）及更高版本的 Aurora MySQL 兼容版。Aurora 与 Amazon SageMaker 的零 ETL 集成在 Aurora PostgreSQL 兼容版本 Aurora PostgreSQL 16.4 及更高版本和 Aurora PostgreSQL 17.4 及更高版本上提供。

访问 AWS 区域和 Aurora DB 引擎支持的 Aurora 功能，了解有关 AWS 区域是否提供 Aurora 零 ETL 集成的更多信息。

Aurora 与 Amazon Redshift 和 Amazon SageMaker 的零 ETL 集成使您无需构建和维护复杂的数据管道。您可以将来自多个 Aurora 数据库集群中多个表的数据整合到单个 Amazon Redshift 数据库集群或 SageMaker 的湖仓架构，并对 Amazon 操作数据进行近乎实时的分析和 ML。

Aurora 与 Amazon Redshift 的零 ETL 集成与 Aurora Serverless v2 兼容。同时使用 Aurora Serverless v2 和 Amazon Redshift Serverless 时，您可以对事务数据生成近乎实时的分析，而无需管理数据管道的任何基础设施。 

Aurora 与 Amazon SageMaker 的零 ETL 集成与 Aurora Serverless v2 兼容。

首先，您可以使用 Amazon RDS 控制台，通过指定 Aurora 源和目标来创建零 ETL 集成。创建集成后，Aurora 数据库将被复制到目标，并且您可以在初始数据插入完成后开始查询数据。有关更多信息，请阅读 Amazon Aurora 与 Amazon Redshift 零 ETL 集成和Aurora 与 Amazon SageMaker 的零 ETL 集成的入门指南。

通过零 ETL 集成对数据变更进行的持续处理无需另行付费。您需要为用于创建和处理在零 ETL 集成过程中产生的变更数据的现有资源付费。这些资源可能包括：

• 启用增强型 binlog 所用的额外的 I/O 和存储空间
• 将初始数据导出至数据库作为种子所需的快照导出费用
• 额外的存储空间，用于存储复制的数据
• 额外的算力，用于处理数据复制
• 将数据从来源移动到目标的跨可用区数据传输费用

有关更多信息，请访问 Aurora 定价页面。

是，您可以使用 AWS CloudFormation 轻松管理和自动化 Aurora 零 ETL 集成所需的资源的配置和部署。有关更多信息，请访问具有零 ETL 集成的 CloudFormation 模板。

CloudWatch Database Insights 是一种旨在简化和增强数据库故障排除的监控和指标解决方案。它可以自动收集遥测数据，包括指标、日志和跟踪，无需手动设置和配置。通过将这些遥测数据整合到 Amazon CloudWatch 中，CloudWatch Database Insights 提供了统一的数据库性能和运行状况视图。

CloudWatch Database Insights 的主要优势包括：

1. 轻松收集遥测数据：自动收集数据库指标、日志和跟踪，最大限度地缩短设置时间。
2. 精选洞察：提供预构建的控制面板、警报和洞察，用于监控和优化数据库性能，只需最少的配置即可开始使用。
3. 统一的 CloudWatch 视图：将来自多个数据库的遥测数据合并到一个视图中，以简化监控。
4. AI/ML 功能：利用 AI/ML 技术检测异常，减少人工故障排除工作。
5. 应用程序上下文监控：允许用户将数据库性能与应用程序性能关联起来。
6. 队列和实例级视图：同时提供笼统的队列监控视图和详细的实例视图，便于分析根本原因。
7. 无缝集成 AWS：与 Amazon CloudWatch Application Signals 和 AWS X-Ray 集成，提供全面的可观测性体验。

Amazon DevOps Guru for RDS 是 Amazon RDS（包括 Amazon Aurora）中一款由机器学习（ML）支持的功能，用于自动检测并诊断数据库中的性能和操作问题，使您能够在几分钟内解决问题，而不是几天。

Amazon DevOps Guru for RDS 是 Amazon DevOps Guru 的一项功能，它可以检测所有 Amazon RDS 引擎和数十种其他资源类型的操作和性能问题。DevOps Guru for RDS 扩展了 DevOps Guru 的现有功能，用于检测、诊断和解决 Amazon RDS 中的各种数据库相关问题（如资源过度利用和 SQL 查询的不当行为）。

当问题发生时，Amazon DevOps Guru for RDS 会立即通知开发人员和 DevOps 工程师，并提供诊断信息、问题程度的详细信息和智能补救建议，以帮助客户快速解决数据库相关性能瓶颈和操作问题。

Amazon DevOps Guru for RDS 用于消除人工工作，并缩短时间（从数小时、数天到数分钟），以此检测并解决关系数据库工作负载中难以发现的性能瓶颈。

您可以为每个 Amazon Aurora 数据库启用 DevOps Guru for RDS，它将自动检测工作负载的性能问题，就每个问题向您发送提示，解释发现的结果，并提供解决措施建议。
DevOps Guru for RDS 可帮助专家以外的人员更轻松地访问数据库管理，并协助数据库专家管理更多数据库。

Amazon DevOps Guru for RDS 利用机器学习（ML）分析由 Amazon RDS 性能详情（PI）收集的遥测数据。DevOps Guru for RDS 在其分析中不使用任何存储在数据库中的数据。 PI 度量数据库负载，这是一个度量指标，用于描述应用程序在数据库上耗费的时间和数据库生成的已选指标，例如 MySQL 中的服务器状态变量和 PostgreSQL 中的 pg_stat 表。

开始使用 DevOps Guru for RDS，要确保通过 RDS 控制台启用性能详情，然后为您的 Amazon Aurora 数据库简单启用 DevOps Guru。使用 DevOps Guru 时，您可以选择整个 AWS 账户作为分析覆盖范围、指定您希望 DevOps Guru 分析的特定 AWS CloudFormation 堆栈，或者使用 AWS 标签创建您希望 DevOps Guru 分析的资源组。

Amazon DevOps Guru for RDS 用于识别可能影响应用程序服务质量的各种性能问题，例如锁定堆存、连接风暴、SQL 回归、CPU 和 I/O 连接，以及内存问题。

Amazon RDS 性能详情是一项数据库性能优化和监控功能，收集并可视化 Amazon RDS 数据库性能指标，帮助您迅速评测数据库负载，并确定在何时、何处采取行动。Amazon DevOps Guru for RDS 旨在监控这些指标，检测您的数据库何时发生性能问题，分析这些指标，并告诉您发生了哪些问题以及可以采取哪些措施。

CloudWatch Database Insights 可实时监控 Aurora 资源和应用程序，然后通过可自定义的控制面板呈现数据。相比之下，Amazon DevOps Guru 是一项机器学习（ML）服务，用于分析 CloudWatch 指标以了解应用程序在一段时间内的行为、检测异常情况并为解决问题提供洞察和建议。此外，DevOps Guru 可以分析来自多个来源的数据，包括 AWS Config、AWS CloudFormation 和 AWS X-Ray。您可以使用 CloudWatch 控制面板，通过 AWS/DevOps-Guru 命名空间中发布的指标来监控 DevOps Guru 的洞察。这可以帮助您使用 CloudWatch 控制台中的单一管理平台查看所有洞察和异常。

RDS 性能详情是一项数据库性能调优和监控功能，可帮助客户评估数据库负载，以及确定在何时、何处采取行动。CloudWatch Database Insights 是一项新的数据库可观测性功能，它继承了性能详情的所有功能，同时还支持队列级监控、与应用程序性能监控集成以及将数据库指标与日志和事件进行关联。

您应该将数据 API 用于新的现代应用程序，特别是那些使用 AWS Lambda 构建、需要以请求/响应模型访问 Aurora 的应用程序。当现有应用程序与数据库驱动程序高度耦合、存在长时间运行的查询时，或者当开发人员想要利用数据库功能（例如临时表或使用会话变量）时，您应该使用数据库驱动程序而不是数据 API 管理持久数据库连接。

有关 Aurora Serverless v2 和 Aurora 预置实例的数据 API AWS 区域和数据库版本可用性，请访问我们的文档。

借助数据 API，您将能够简化和加速现代应用程序的开发。数据 API 是一种易于使用的基于安全 HTTP 的 API，无需部署数据库驱动程序、管理客户端连接池，也无需在应用程序和数据库之间设置复杂的 VPC 网络。数据 API 还可通过自动池化和共享数据库连接来提高可扩展性，从而减少频繁打开和关闭连接的应用程序的计算开销。 

Aurora Serverless v2 和 Aurora 预置实例的数据 API 支持 Aurora 全局数据库写入器实例。

用户只有在获得授权的情况下才能调用数据 API 操作。管理员可以通过附加定义其权限的 AWS Identity and Access Management（IAM）策略来授予用户使用数据 API 的权限。如果您使用 IAM 角色，还可以将策略附加到角色。调用数据 API 时，您可以使用 AWS Secrets Manager 中的密钥传递 Aurora 数据库集群的凭证。 

Aurora Serverless v2 和 Aurora 预置实例的数据 API 按 API 请求量定价，如 Aurora 定价页面所述。Aurora Serverless v2 和 Aurora 预置实例的数据 API 使用 AWS CloudTrail 数据面板事件来记录活动，而不是使用管理事件。

如果您想跟踪此活动，您可以通过 CloudTrail 控制台、CLI 或 SDK 启用数据事件日志记录。这需要按照 CloudTrail 定价页面上规定的费用付费。此外，使用 AWS Secrets Manager 需按照 AWS Secrets Manager 定价页面中规定的费用付费。 

AWS CloudTrail 将 AWS API 活动捕获为管理事件或数据事件。CloudTrail 管理事件（也称为“控制面板操作”）显示在您的 AWS 账户中的资源上执行的管理操作，例如创建、更新和删除资源。CloudTrail 数据事件（也称为“数据面板操作”）显示在您的 AWS 账户中的资源上或资源内执行的资源操作。

数据 API 执行数据面板操作，因为它对您的 Aurora 数据库中的数据执行查询。因此，我们会将数据 API 活动记录为数据事件，因为这是事件的正确分类。如果您启用数据事件日志记录，则只需要为 CloudTrail 数据事件付费。

有，第一年使用时，数据 API 免费套餐包括每月 100 万个 API 请求（跨 AWS 区域汇总）。 一年后，客户将开始按照 Aurora 定价页面上的描述为数据 API 付费。

Amazon RDS 蓝绿部署在 Amazon Aurora MySQL 兼容版 5.6 及更高版本以及 Amazon Aurora PostgreSQL 兼容版 11.21 及更高版本、12.16 及更高版本、13.12 及更高版本、14.9 及更高版本以及 15.4 及更高版本中可用。在 Aurora 文档中了解有关可用版本的更多信息。

Amazon RDS 蓝绿部署现已在所有适用的 AWS 区域和 AWS GovCloud 区域推出。

Amazon RDS 蓝绿部署可让您实现更安全、更简单、更快速的数据库更改。蓝绿部署非常适用于主版本或次要版本数据库引擎升级、操作系统更新、在不中断逻辑复制的情况下进行绿色环境中的架构更改（例如在表末尾添加新列或数据库参数设置更改）等应用场景。

您可以使用蓝绿部署通过单次切换同时更新多个数据库。这使您可以随时了解最新的安全补丁，提高数据库性能，并在可预测的短暂停机时间内访问更新的数据库功能。如果您只想在 Aurora 上执行次要版本升级，我们建议您使用 Aurora 零停机安装补丁（ZDP）。

在绿色实例上运行工作负载的成本与在蓝色实例上运行时相同。在蓝色和绿色实例上运行的成本包括 db.instances、存储成本、读/写 I/O 成本以及任何已启用功能的当前标准定价，如备份成本和 Amazon RDS 性能详情。 实际上，在蓝绿部署寿命周期内，您的成本大约是在 db.instance 上运行工作负载成本的 2 倍。

例如：Aurora MySQL 兼容版 5.7 集群在两个 r5.2xlarge db.instances 上运行，在 us-east-1 AWS 区域内有一个主写入器实例和一个读取器实例。每个 r5.2xlarge db.instances 配置 40 GiB 存储，每月有 2500 万 I/O。使用 Amazon RDS 蓝绿部署创建蓝色实例拓扑的克隆，运行 15 天（360 小时），在此期间每个绿色实例有 300 万 I/O 读取。然后在成功切换后删除蓝色实例。蓝色实例（写入器和读取器）15 天费用为 849.2 美元，即期票汇汇率为 1.179 美元/小时（实例 + 存储 + I/O）。绿色实例（写入器和读取器）15 天费用为 840.40 美元，即期票汇汇率为 1.167 美元/小时（实例 + 存储 + I/O）。在这 15 天内，使用 Blue/Green Deployments 的总成本为 1689.60 美元，大约是该时间段运行蓝色实例的成本的 2 倍。

Amazon RDS 蓝绿部署可帮助您进行更安全、更简单、更快速的数据库更改，如主要或次要版本升级、架构更改、实例缩放、引擎参数更改和维护更新。

在 Amazon RDS 蓝绿部署中，蓝色环境是您当前的生产环境。绿色环境是您的暂存环境，在切换后将成为您的新生产环境。

当 Amazon RDS 蓝绿部署启动切换时，它们会阻止任何对蓝色和绿色环境的写入，直到切换完成。 在切换过程中，暂存环境（或绿色环境）会跟随生产系统，确保暂存环境和生产环境之间的数据一致。一旦生产环境和暂存环境完全同步，蓝绿部署通过将流量重定向到新提升的生产环境，将暂存环境提升为新生产环境。

Amazon RDS 蓝绿部署旨在在切换完成后对绿色环境启用写入，确保切换过程中无数据丢失。

Amazon RDS 蓝绿部署不会删除旧生产环境。如果需要，您可以访问该环境进行其他验证和性能/回归测试。如果您不再需要旧生产环境，可以将其删除。标准账单费用适用于旧生产实例，直到您将其删除。

Amazon RDS 蓝绿部署切换防护机制将阻止对蓝色和绿色环境的写入，直到您的绿色环境在切换之前成功跟随。蓝绿部署还可以对蓝色和绿色环境中的主副本执行运行状况检查。它们还将执行复制运行状况检查，例如，查看复制是否已停止或是否存在错误。它们将检测蓝绿环境之间的长时间运行事务。您可以指定可忍受的最大停机时间，最短为 30 秒，如果正在进行的事务超过此时间，则切换将超时。

如果您的蓝色环境是自行管理的逻辑副本或订阅用户，我们将阻止切换。我们建议您首先停止向蓝色环境的复制，继续进行切换，然后再继续复制。相反，如果您的蓝色环境是自行管理的逻辑副本的来源或发布者，则可以继续切换。但是，您需要更新自行管理的副本，以便在切换后从绿色环境中进行复制。

是，Amazon RDS 蓝绿部署支持 Aurora Global Database。 要了解更多信息，请阅读Amazon Aurora Global Database 蓝绿部署用户指南。

否，Amazon RDS 蓝绿部署不支持 Amazon RDS 代理或跨区域只读副本。 

否，您目前无法使用 Amazon RDS 蓝绿部署回滚更改。

Trusted Language Extensions（TLE）for PostgreSQL 使开发人员能够构建高性能 PostgreSQL 扩展并在 Amazon Aurora 上安全地运行它们。通过这样做，TLE 将缩短您的上市时间，并减轻数据库管理员在认证用于生产数据库工作负载的自定义和第三方代码方面的负担。一旦您决定延期满足需求，即可继续前进。借助 TLE，独立软件供应商（ISV）可以为在 Aurora 上运行的客户提供新的 PostgreSQL 扩展。

PostgreSQL 扩展在同一进程空间中执行，以获得高性能。然而，扩展可能存在软件缺陷，从而导致数据库崩溃。

TLE for PostgreSQL 提供了多重保护来降低这种风险。TLE 旨在限制对系统资源的访问。rds_superuser 角色可以确定允许谁安装特定的扩展。然而，这些更改只能通过 TLE API 进行。TLE 旨在限制扩展缺陷对单个数据库连接的影响。除了这些安全措施之外，TLE 还旨在以 rds_superuser 角色为 DBA 提供细粒度的在线控制，控制谁可以安装扩展以及他们可以创建运行扩展所需的权限模型。只有具有足够权限的用户才能在 TLE 扩展上使用“CREATE EXTENSION”命令运行和创建。DBA 还有更复杂的扩展所需的允许列表“PostgreSQL 挂钩”，这些扩展修改数据库的内部行为，通常需要提升权限。

TLE for PostgreSQL 适用于 Amazon Aurora PostgreSQL 兼容版本 14.5 及更高版本。TLE 本身作为 PostgreSQL 扩展实施，您可以从 rds_superuser 角色激活它，与 Aurora 上支持的其他扩展类似。

您可以在 Amazon Aurora 的 PostgreSQL 14.5 或更高版本中运行 TLE for PostgreSQL。

TLE for PostgreSQL 当前已在所有 AWS 区域（不含 AWS 中国区域）和 AWS GovCloud 区域推出。

Aurora 客户可以免费使用 TLE for PostgreSQL。

Aurora 和 Amazon RDS 支持超过 85 个精选 PostgreSQL 扩展的集合。AWS 根据 AWS 责任共担模式管理每个扩展的安全风险。实施 TLE for PostgreSQL 的扩展包含在此集合中。您写入的扩展或从第三方来源获取并安装在 TLE 中的扩展被视为应用程序代码的一部分。您负责使用 TLE 扩展的应用程序的安全性。

您可以构建开发人员功能，如位图压缩和差异化隐私（如保护个人隐私的可公开访问的统计查询）。

TLE for PostgreSQL 当前支持 JavaScript、PL/pgSQL、Perl 和 SQL。

一旦 rds_superuser 角色激活 TLE for PostgreSQL，您就可以使用来自任何 PostgreSQL 客户端（例如 psql）的 SQL CREATE EXTENSION 命令部署 TLE 扩展。这类似于创建用程序语言（如 PL/pgSQL 或 PL/Perl）编写的用户定义函数的方式。您可以控制哪些用户具有部署 TLE 扩展和使用特定扩展的权限。

TLE for PostgreSQL 仅通过 TLE API 访问您的 PostgreSQL 数据库。TLE 支持的可信语言包括 PostgreSQL 服务器编程接口（SPI）的所有功能，并支持 PostgreSQL 挂钩，包括检查密码挂钩。

您可以在官方 TLE GitHub 页面了解有关 TLE for PostgreSQL 项目的更多信息。