Amazon Aurora 常见问题

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

Aurora 采用一种有容错能力并且可以自我修复的分布式存储系统，这一系统与计算资源分离并可以把每个数据库实例自动扩展到最高 128 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 开源数据库采用嵌入式兼容，还会定期实现对新版本的支持。这意味着您可以使用标准导入/导出工具或者快照将 PostgreSQL 数据库轻松迁移到和迁移出 Aurora。它意味着，您已用于 PostgreSQL 数据库的大多数代码、应用程序、驱动程序和工具可与 Aurora 配合使用，只需对其进行少量更改或无需更改。

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

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

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

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

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

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

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

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

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

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

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

不需要，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% 大小的的备份，您无需支付任何费用。在为数据库集群配置的备份保留期内，您也不需要为快照付费。

不是，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-Optimized 时，无需为读取和写入 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-Optimized 为所有应用程序提供可预测的定价，因为读取和写入 I/O 操作不收取任何费用，这使得该配置非常适合 I/O 可变性大的工作负载。

当您需要为任何应用程序提供可预测的成本时，Aurora I/O-Optimized 是理想的选择。它为需要高写入吞吐量或运行处理大量数据的分析查询的 I/O 密集型应用程序提供了更高的性价比。对于 I/O 支出超过 Aurora 账单 25% 的客户，使用 Aurora I/O-Optimized 最多可使 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-Optimized 实现的预留实例折扣，您可以进一步节省 I/O 支出。

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

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

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

最低存储为 10 GB。根据您的数据库使用量，您的 Amazon Aurora 存储将以 10 GB 的增量自动增长到 128 TiB，而不会影响数据库的性能。无需提前预置存储。

有两种方法可以扩展与我的 Amazon Aurora 数据库实例关联的计算资源：通过 Aurora Serverless 和通过手动调整。

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

您还可以通过在 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 v1，当数据库实例或可用区不可用时，Aurora 会自动在不同的可用区重新创建该数据库实例。Aurora Serverless v2 的工作方式与为失效转移和其他高可用性功能配置的一样。有关更多信息，请参阅 Aurora Serverless v2 和高可用性。 
• 如果您没有 Aurora 副本（即单个实例），也未运行 Aurora Serverless，则 Aurora 会先尝试在原始实例的可用区中新建数据库实例。原实例会尽量替换，但可能不会成功，例如出现全面影响该可用区的问题时。
  

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

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

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

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

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

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

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

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

您只需在 Amazon RDS 控制台上单击几下即可创建 Aurora Global Database。此外，你可以使用 AWS 软件开发工具包（SDK）或 AWS Command-Line Interface（CLI）。您需要在 Amazon Aurora Global Database 中为每个区域预置至少一个实例。

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

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

不会。如果您的主区域不可用，您可以手动从 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 支持每种类型的数据库工作负载，包括具有不频繁、间歇性或不可预见工作负载的开发和测试环境、网站和应用程序，以及要求极高的需要大规模和高可用性的业务关键型应用程序。它通过添加更多的 CPU 和内存来适当扩展，而不必将数据库故障转移到更大或更小的数据库实例。因此，即使存在长时间运行的事务、表锁等，它也可以扩展。

此外，它还以小至 0.5 个 Aurora 容量单位（ACU）的增量扩缩数据库容量，从而使您的数据库容量与应用程序的需求密切匹配。

Aurora Serverless v1 是一种简单且更具成本效益的选择，适用于不频繁、间歇性或不可预测的工作负载。它可以自动启动，扩缩计算容量以匹配应用程序的使用，并在不使用时关闭。要了解更多信息，请访问 Aurora 用户指南。

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

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

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

是，您可以从 Aurora Serverless v1 迁移到 Aurora Serverless v2。要了解更多信息，请参阅 Aurora 用户指南。

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

适用于 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 兼容版本提供支持。

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

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

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

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

Aurora 与 Amazon Redshift 的零 ETL 集成在以下区域的 Aurora MySQL 兼容版上提供，适用于 Aurora MySQL 3.05 版本（与 MySQL 8.0.32 兼容）及更高版本：美国东部（俄亥俄州）、美国东部（弗吉尼亚州北部）、美国西部（俄勒冈州）、亚太地区（新加坡）、亚太地区（悉尼）、亚太地区（东京）、欧洲地区（法兰克福）、欧洲地区（爱尔兰）和欧洲地区（斯德哥尔摩）。Aurora 与 Amazon Redshift 的零 ETL 集成在美国东部（俄亥俄州）区域的 Aurora PostgreSQL 兼容版本 Aurora PostgreSQL 15.4 上提供。

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

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

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

零 ETL 和对数据更改的持续处理无需额外付费。您需要为现有的 Amazon RDS 和 Amazon Redshift 资源付费，这些资源用于创建和处理在零 ETL 集成过程中生成的变更数据。这些资源可能包括：

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

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

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 Performance Insights（PI）收集的遥测数据。DevOps Guru for RDS 在其分析中不使用任何存储在数据库中的数据。PI 度量数据负载，这是一个度量指标，用于描述应用程序在数据库上耗费的时间和数据库生成的已选指标，例如 MySQL 和 PostgreSQL 中的 pg_stat 表。

开始使用 DevOps Guru for RDS，要确保通过 RDS 控制台启用 Performance Insights，然后为您的 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 Performance Insights 是一项数据库性能优化和监控功能，收集并可视化 Amazon RDS 数据库性能指标，帮助您迅速评估数据库负载，并确定在何时、何处采取行动。Amazon DevOps Guru for RDS 旨在监控这些指标，检测您的数据库何时发生性能问题，分析这些指标，并告诉您发生哪些问题以及可以采取的措施。

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

有关 Aurora Serverless v2 和 Aurora 预配置实例的数据 API AWS 区域和数据库版本可用性，请访问我们的文档。我们鼓励当前使用 Aurora Serverless v1 数据 API 的客户迁移到 Aurora Serverless v2，以利用重新设计的数据 API 和 Aurora Serverless v2 更精细的扩展。

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

Aurora Serverless v1 的现有数据 API 将仍然是 Aurora 的 PostgreSQL 兼容版和 MySQL 兼容版的 Aurora Serverless v1 功能。Aurora Serverless v2 和 Aurora 预置实例的数据 API 不支持 Aurora Serverless v1。Aurora Serverless v2 和 Aurora 配置实例的数据 API 支持 Aurora 全局数据库写入器实例。

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

Aurora Serverless v1 的数据 API 仍然可用，无需额外付费。Aurora Serverless v2 和 Aurora 预置实例的数据 API 按 API 请求量定价，如 Aurora 定价页面所述。Aurora Serverless v2 和 Aurora 预置实例的数据 API 使用 AWS CloudTrail 数据面板事件，而不是和 Aurora Serverless v1 的数据 API 一样，使用管理事件来记录活动。

如果您想跟踪此活动，您可以通过 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 Performance Insights。 实际上，在蓝绿部署生命周期内，您的成本大约是在 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 蓝绿部署不支持 Amazon Aurora Global Database、Amazon RDS 代理或跨区域只读副本。

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

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