跳至主要内容

Amazon Aurora

Amazon Aurora 常见问题

页面主题

一般性问题

全部打开

Amazon Aurora 是一种关系数据库引擎，既具有高端商用数据库的速度和可靠性，又具有开源数据库的简单性和成本效益。Amazon Aurora MySQL 的性能最高可以是 MySQL 的五倍，且无需对大多数 MySQL 应用程序进行任何更改；同样，Amazon Aurora PostgreSQL 的性能最高可以是 PostgreSQL. 的三倍。Amazon RDS 管理您的 Amazon Aurora 数据库，同时处理耗时型任务，如预置、修补、备份、恢复、故障检测和修复。您只需为使用的每个 Amazon Aurora 数据库实例支付单项月费即可。无需缴纳预付款或签订长期合同。

它表示您目前已用于 MySQL 数据库的大多数代码、应用程序、驱动程序和工具可与 Aurora 配合使用，只需对其进行少量更改或不需要更改。Amazon Aurora 数据库引擎设计旨在能使用 InnoDB 存储引擎与 MySQL 5.6 和 5.7 接线兼容。MyISAM 存储引擎之类的特定 MySQL 功能不可用于 Amazon Aurora。

它表示您目前已用于 PostgreSQL 数据库的大多数代码、应用程序、驱动程序和工具可与 Aurora 配合使用，只需对其进行少量更改或不需要更改。Amazon Aurora 数据库引擎设计旨在与 PostgreSQL 9.6 和更高版本接线兼容，且支持的一组 PostgreSQL 扩展与 RDS for PostgreSQL 9.6 及更高版本所支持的 PostgreSQL 扩展相同，以便轻松在两个引擎之间移动应用程序。

要试用 Amazon Aurora，请登录亚马逊云科技控制台，选择“数据库”类别下的 RDS，然后选择 Amazon Aurora 作为您的数据库引擎。

请查看我们的定价页面，了解有关区域和价格的最新信息。

您有多种选择。您可以使用标准的 mysqldump 实用工具将数据从 MySQL 中导出，并用 mysqlimport 实用工具将数据导入 Amazon Aurora，反之亦然。您还可以使用 Amazon RDS 的数据库快照迁移功能通过亚马逊云科技管理控制台将 RDS MySQL 数据库快照迁移到 Amazon Aurora 中。虽然持续时间取决于格式和数据集大小，但对于大多数客户而言，迁移过程可在一小时内完成。 

您有多种选择。您可以使用标准的 pg_dump 实用工具将数据从 PostgreSQL 中导出，并用 pg_restore 实用工具将数据导入 Amazon Aurora，反之亦然。您还可以使用 Amazon RDS 的数据库快照迁移功能通过亚马逊云科技管理控制台将 RDS PostgreSQL 数据库快照迁移到 Amazon Aurora 中。虽然持续时间取决于格式和数据集大小，但对于大多数客户而言，迁移过程可在一小时内完成。

不需要。Amazon Aurora 支持标准 PostgreSQL 数据库驱动程序。

性能

全部打开

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

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

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

CloudWatch 数据库洞察的主要优势包括：

  1. 轻松收集遥测数据：自动收集数据库指标、日志和跟踪，最大限度地缩短设置时间。

  2. 精选的洞察：提供预先构建的控制面板、警报和洞察，以监控和优化数据库性能，只需最少的配置即可开始使用。

  3. 统一的 CloudWatch 视图：将来自多个数据库的遥测数据合并到一个视图中，以简化监控

  4. 人工智能/机器学习功能：使用 AI/ML 检测异常，减少手动故障排除工作

  5. 应用程序上下文监控：允许用户将数据库性能与应用程序性能关联起来。

  6. 实例集和实例级别的视图：提供高级实例集监控和用于根本原因分析的详细实例视图。

  7. 无缝的 Amazon 集成：与 Amazon CloudWatch Application Signals 和 Amazon X-Ray 集成，带来全面的可观测性体验

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

计费

全部打开

请参阅 Aurora 定价页面，了解最新定价信息。

目前，由西云数据运营的亚马逊云科技中国（宁夏）区域免费套餐不包括 Aurora。但是，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 为单位进行计数。例如，1024 字节的日志记录计为一个写入 I/O 操作。但是，如果日志记录超过 4KB，则将需要多个写入 I/O 操作才能将其保留。

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

您可以在亚马逊云科技管理控制台看到 Aurora 实例消耗的 I/O 请求数量。要查询 I/O 消耗，请转到控制台的 Amazon RDS 部分，查看您的实例列表，选择 Aurora 实例，然后在监控部分查找“计费的读取操作”和“计费的写入操作”指标。

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

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

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

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

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

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

每 30 天，您可以将现有数据库集群切换到 Aurora I/O 优化版一次。您可以随时切换回 Aurora 标准版。

是的，Aurora I/O 优化版适用于现有的 Aurora 预留实例。Aurora 会自动计算 Aurora 标准版和 Aurora I/O 优化版预留实例之间的价格差异。使用 Aurora I/O 优化版的预留实例折扣，您可以节省更多 I/O 支出。

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

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

硬件和扩展

全部打开

最小存储为 10GB。根据您的数据库使用情况，您的 Amazon Aurora 存储将以 10GB 增量自动增长，最多可达 128 TB，且不会影响数据库性能。无需提前预置存储。

在亚马逊云科技管理控制台中，选择所需的数据库实例并点击“修改”按钮，即可扩展分配至数据库实例的计算资源。通过更改数据库实例类来修改内存和 CPU 资源。

修改数据库实例类时，系统将在指定的维护时段内应用您请求的更改。或者，您可以使用“立即应用”标记立即应用您的扩展请求。执行扩展操作时，这两种选项均会造成几分钟的可用性影响。请注意，任何其他待定的系统更改也将同时应用。

备份和还原

全部打开

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

可以，拍摄快照不会影响性能。请注意，从数据库快照中还原数据需要新建数据库实例。

Amazon Aurora 会在 3 个可用区自动维护 6 个数据副本，并会自动尝试在正常的可用区恢复您的数据库且不会丢失数据。您的数据在 Amazon Aurora 存储内不可用的情况不太可能出现，您可以从数据库快照中进行还原或对新实例执行时间点还原操作。请注意，时间点还原操作的最新可还原时间为过去 5 分钟。

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

可以。借助 Aurora，您可以创建数据库快照，以便在以后用于还原数据库。您可以与其他亚马逊云科技账户共享快照，收件人账户的所有者可以使用您的快照还原包含您的数据的数据库。您甚至可以选择公开快照，也就是说，任何人都能还原包含您的（公开）数据的数据库。您可以使用此功能在拥有不同亚马逊云科技账户的各种环境（生产、开发/测试、分阶段等）之间共享数据，也可以将所有数据的备份安全保存到一个单独的账户中，以防主亚马逊云科技账户遭受攻击。

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

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

您可以将手动快照共享给最多 20 个亚马逊云科技账户 ID。如果您需要将快照共享给 20 个以上的账户，则可以将快照作为公开快照进行共享，或联系支持人员要求增加配额。

您可以在 Aurora 可用的所有亚马逊云科技区域共享您的 Aurora 快照。

不能。您共享的 Aurora 快照将只能由与共享快照的账户位于同一区域的账户访问。

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

高可用性和复制

全部打开

Amazon Aurora 会自动将您的数据库卷分成分散在很多个磁盘上的 10GB 的区段。每 10GB 的数据库卷组块都能在三个可用区间用六种方法进行复制。Amazon Aurora 旨在以透明方式应对多达两个数据副本丢失的情况，而不会影响数据库写入可用性，还能在不影响读取可用性的情况下应对多达三个副本丢失的情况。Amazon Aurora 存储还具有自我修复能力。数据块和磁盘会不断进行扫描以查看是否存在任何错误，并自动修复。

与其他数据库不同的是，在数据库崩溃之后，Amazon Aurora 不需要重放最后一个数据库检查点（通常为 5 分钟）的重做日志，且不需要在数据库可用于操作之前确认所有更改都已应用。在大多数情况下，这会将数据库的重启时间缩短到 60 秒以内。Amazon Aurora 会将缓冲区缓存移出数据库进程，并使其能够在重启时立即可用。这可以防止在缓存重新填充之前必须限制访问，以避免资源耗尽。

Amazon Aurora MySQL 和 Amazon Aurora PostgreSQL 都支持 Amazon Aurora 副本，这些副本与同一亚马逊云科技中国区域内的主实例共享相同的底层卷。主实例进行的更新对所有 Amazon Aurora 副本可见。借助 Amazon Aurora MySQL，您还可以根据 MySQL 基于二进制日志的复制引擎创建跨区域复制的 MySQL 只读副本。在 MySQL 只读副本中，您的主实例中的数据会作为事务在您的副本上重放。对于大多数使用案例，包括读取扩展和高可用性，我们推荐使用 Amazon Aurora 副本。
您可以根据应用程序需求灵活地混合搭配这两种副本类型：

功能

Amazon Aurora 副本

MySQL 副本

副本数量

最多 15 个

最多 5 个

复制类型

异步（毫秒）

异步（秒）

对主实例的性能影响

低

高

副本位置

区域内

跨区域

作为故障转移目标

是（无数据损失）

是（可能有几分钟的数据损失）

自动故障转移

是

否

支持用户定义的复制延迟

否

是

支持不同的数据或架构与主实例

否

是


能，您可以通过物理或逻辑复制功能来设置跨区域 Aurora 副本。物理复制也称为 Aurora Global Database，它使用专用基础设施，使您的数据库完全可用于为应用程序提供服务。它可用于 Aurora MySQL 和 Aurora PostgreSQL。对于低延迟全球读取和灾难恢复，我们建议使用 Aurora Global Database。Aurora 支持各种数据库引擎的原生逻辑复制（MySQL 的二进制日志以及 PostgreSQL 的 PostgreSQL 复制槽），因此您可以复制到 Aurora 和非 Aurora 数据库，甚至可以跨区域复制。Aurora MySQL 还提供方便易用的逻辑跨区域只读副本功能，可支持亚马逊云科技中国区域，包括由光环新网运营的亚马逊云科技中国（北京）区域和由西云数据运营的亚马逊云科技中国（宁夏）区域。此功能基于单线程的 MySQL 二进制日志复制操作，因此复制滞后时间会受到更改/应用速度以及所选特定区域之间的网络通信延迟影响。

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

是的，您可以通过 RDS 控制台将跨区域副本提升为新的主副本。对于逻辑（二进制日志）复制，提升过程通常需要几分钟，具体视您的工作负载而定。启动提升过程后，跨区域复制将停止。使用 Aurora Global Database，您可以在一分钟内提升辅助区域以获取完整的读/写工作负载。

可以。您可以为集群中的每个实例指定一个提升优先级分层。如果主实例发生故障，Amazon RDS 会将优先级最高的副本提升为主实例。 如果两个或更多 Aurora 副本共享相同的优先级，则 Amazon RDS 将提升最大的副本。如果两个或更多 Aurora 副本共享相同的优先级和大小，则 Amazon RDS 将提升同一提升分层中的任意副本。有关故障转移逻辑的更多信息，请阅读 Amazon Aurora 用户指南。

是的，您可以随时修改实例的优先级分层。单纯地修改优先级分层并不会触发故障转移。

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

您可以添加 Amazon Aurora 副本。同一亚马逊云科技中国区域中的 Aurora 副本与主实例共享相同的底层存储。任何 Aurora 副本都可在不丢失任何数据的情况下被提升为主实例，因此，它可用于在主数据库实例发生故障时提高容错能力。要提高数据库可用性，只需在 3 个可用区的任何一个创建 1 到 15 个副本，Amazon RDS 将在数据库运行中断时将这些副本纳入故障转移主选择中。

如果您希望数据库跨越多个亚马逊云科技中国区域，可以使用 Aurora Global Database。这样可以在不影响数据库性能的情况下复制您的数据，并在区域范围的中断时提供灾难恢复。

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

  • 如果您在相同或不同的可用区中有 Amazon Aurora 副本，当进行故障转移时，Aurora 会翻转您的数据库实例的别名记录 (CNAME)，以指向运行状态正常的副本；相应地，此副本会提升为新的主实例。从开始到结束，故障转移通常会在 30 秒内完成。
  • 如果您运行的是 Aurora Serverless，当数据库实例或可用区不可用时，Aurora 将自动在不同的可用区重新创建该数据库实例。
  • 如果您没有 Amazon Aurora 副本（即单个实例），也未运行 Aurora Serverless，则 Aurora 将尝试在与原始实例相同的可用区中创建新数据库实例。原始实例的这种替换是尽最大努力进行的，可能不会成功，例如，如果存在广泛影响可用区的问题。

您的应用程序应在连接中断时重新尝试发出数据库连接。

跨区域进行灾难恢复是一个手动过程，在此期间，您可以提升辅助区域以获取读/写工作负载。

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

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

Amazon Aurora 副本与同一亚马逊云科技中国区域内的主实例共享同一个数据卷，因此几乎没有复制滞后。据我们观察，滞后时间一般在 10 毫秒内。对于 MySQL 只读副本，复制滞后可根据更改/应用速度以及网络通信的延迟无限增长。不过，一般情况下，1 分钟以内的复制滞后是很常见的。

对于使用逻辑复制的跨区域副本，其滞后时间会受到更改/应用速度以及所选特定区域之间的网络通信延迟的影响。使用 Aurora Global Database 的跨区域副本通常有不到一秒的滞后时间。

是的，您可以在 Aurora MySQL 实例和外部 MySQL 数据库之间设置二进制日志复制。另一个数据库可以在 Amazon RDS 上运行，或作为自我管理的数据库在亚马逊云科技上运行，或完全在亚马逊云科技之外运行。

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

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

此功能可用于 Aurora MySQL 和 Aurora PostgreSQL。

您只需在 Amazon RDS 管理控制台中点击几下，即可创建 Aurora Global Database。或者，您也可以使用 SDK 或 CLI。您需要在 Aurora Global Database 中为每个区域预置至少一个实例。

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

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

不会。如果您的主区域不可用，您可以手动从 Aurora Global Database 中删除辅助区域，并对其进行提升以获取完全的读取和写入。您还需要将应用程序指向新提升的区域。

安全性

全部打开

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

可以。Amazon Aurora 使用 SSL (AES-256) 保护数据库实例与应用程序之间的连接。Amazon Aurora 允许您使用通过 Amazon Key Management Service (KMS) 管理的密钥加密数据库。在使用 Amazon Aurora 加密来运行的数据库实例上，静态存储于底层存储的数据都将加密，同一集群中的自动备份、快照和副本也是如此。加密和解密操作的处理都是无缝的。有关将 KMS 与 Amazon Aurora 一起使用的更多信息，请参阅 Amazon RDS 用户指南。

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

必须通过您在创建数据库时输入的数据库端口访问 Amazon Aurora 数据库。这样做可以为您的数据再添一重安全保障。

可以，MySQL 和 PostgreSQL 兼容版的 Aurora 符合 HIPAA 要求，因此您可以基于与亚马逊云科技签署的《业务合作协议》(Associate Agreement, BAA)，使用它们构建 HIPAA 合规应用程序并存储医疗保健相关信息（包括受保护的健康信息 [PHI]）。如果您已签署 BAA，可以立即开始在 BAA 协议涵盖的账户内使用这些服务。 

无服务器

全部打开

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

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

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

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

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

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

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

在 Aurora Serverless 中，数据库容量以 ACU 为单位计量。您按每秒 ACU 使用量的固定费率付费。在 Aurora Serverless 上运行工作负载的计算成本将取决于您选择的数据库集群配置：Aurora 标准版或 Aurora I/O 优化版。访问 Aurora 定价页面，了解有关定价和区域可用性的信息。

Parallel Query

全部打开

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

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

更快的性能：Parallel Query 可将分析查询的运行速度提高多达 2 个数量级。

操作简易性和数据新鲜度：您可以直接对 Aurora 集群中的当前事务数据发出查询。

同一数据库上的事务工作负载和分析工作负载：借助 Parallel Query 功能，Aurora 可以在处理并行分析查询的同时保持较高的事务吞吐量。

对不在缓冲池中的大型数据集的大多数查询都有望受益。初始版本的 Parallel Query 可以向下推送并横向扩展超过 200 个 SQL 函数、等值连接和投影的处理。

特定查询的性能改进具体视有多少查询计划可以向下推送到 Aurora 存储层而定。据客户报告，查询延迟缩短了不止一个数量级。

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

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

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

不会。除了您已经支付的实例、IO 和存储费用之外，无需再支付任何费用。

不会，查询产生的 IO 费用在存储层进行计量，启用 Parallel Query 后，该费用可能保持不变，也可能会增加。您可以获得的好处是查询性能提高了。

使用 Parallel Query 后，有两个原因可能会导致 IO 费用增加。首先，即使表中的一些数据在缓冲池中，PQ 也要求在存储层扫描所有数据，从而产生 IO。其次，避免缓冲池中资源争用的副作用是运行 PQ 查询不会预热缓冲池。因此，连续运行相同的 PQ 查询将产生完整 IO 费用。

Parallel Query 适用于兼容 MySQL 5.6 的 Amazon Aurora 版本，从 v1.18.0 开始。我们计划将 Parallel Query 的支持范围扩大到兼容 MySQL 5.7 的 Aurora 和兼容 PostgreSQL 的 Aurora。

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

最初并不兼容。目前，您只能针对未运行 Serverless 或 Backtrack 功能的数据库集群启用该功能。此外，Parallel Query 不支持兼容 MySQL 5.7 的 Aurora 的特定功能。

否。虽然我们预期 Parallel Query 在大多数情况下都可以改善查询延迟，但 IO 费用可能会增加。建议您分别在启用和禁用该功能的情况下充分测试您的工作负载；如果您确信 Parallel Query 是正确的选择，则可以依靠查询优化器自动决定哪些查询将使用 PQ。在极少数情况下，优化器无法做出最佳选择，此时您可以覆盖该设置。

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

零 ETL 集成

全部打开

当您需要近乎实时地访问交易数据时，应当使用 Amazon Aurora 与 Amazon Redshift 的零 ETL 集成。借助这一集成，您可以通过简单的 SQL 命令使用 Amazon Redshift 机器学习。

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

使用 Aurora 与 Amazon Redshift 的零 ETL 集成，您无需构建和维护复杂的数据管道。您可以将来自各个 Aurora 数据库集群的多个表的数据整合到单个 Amazon Redshift 数据库集群中，并使用 Amazon Redshift 对来自 Aurora 的 PB 级交易数据执行近乎实时的分析和机器学习。您可以选择要从 Aurora 复制到 Amazon Redshift 的数据库和表。根据您的分析需求，对特定数据库和表进行数据筛选，这样有助于选择性地将数据导入到 Amazon Redshift。

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

要开始使用零 ETL 集成，您可以使用 Amazon RDS 控制台，通过指定 Aurora 来源和 Amazon Redshift 目的地来创建零 ETL 集成。一旦创建此集成，Aurora 数据库将复制到 Amazon Redshift，完成初始播种之后，您就可以开始查询数据了。有关更多信息，请阅读 Aurora 与 Amazon Redshift 的零 ETL 集成入门指南。

零 ETL 集成对数据变更进行持续处理，且不收取额外费用。您需要为现有的 Amazon RDS 和 Amazon Redshift 资源付费，这些资源用来创建和处理作为零 ETL 集成的一部分而生成的变更数据。这些资源可能包括：

  • 通过启用增强型二进制日志而使用的其他 I/O 和存储
  • 负责为您的 Amazon Redshift 数据库提供种子的初始数据导出操作产生的快照导出成本
  • 用来存储复制的数据的其他 Amazon Redshift 存储
  • 用来处理数据复制操作的其他 Amazon Redshift 计算
  • 将数据从来源转移到目标时产生的跨可用区数据传输成本

要了解更多信息，请访问 Aurora 定价页面。

是，对于 Aurora 与 Amazon Redshift 的零 ETL 集成所需的资源，您可以使用 Amazon CloudFormation 来管理和自动完成它们的配置和部署。要了解更多信息，请访问具有零 ETL 集成的 CloudFormation 模板。

Trusted Language Extensions for PostgreSQL

全部打开

Trusted Language Extensions（TLE）for PostgreSQL 使开发人员能够构建高性能 PostgreSQL 扩展，并在 Amazon Aurora 和 Amazon RDS 上安全地运行它们。这样，TLE 可以缩短您的上市时间，无需数据库管理员认证用于生产数据库工作负载的自定义代码和第三方代码。一旦您确定某个扩展能够满足您的需求，您就可以开始使用它。通过 TLE，独立软件供应商（ISV）可以向在 Aurora 和 Amazon RDS 上运行的客户提供新的 PostgreSQL 扩展。

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

TLE for PostgreSQL 提供了多层保护来缓解这种风险。TLE 能够限制对系统资源的访问。rds_superuser 角色可以决定谁有权安装特定的扩展。但是，这些更改只能通过 TLE API 进行。TLE 能够将扩展缺陷的影响限制在单个数据库连接的范围内。除了这些保障措施外，TLE 还能够为 rds_superuser 角色的数据库管理员提供对谁可以安装扩展的精细在线控制，并让他们可以创建运行扩展的权限模型。只有具有足够权限的用户才能在 TLE 扩展上使用“CREATE EXTENSION”命令运行和创建。数据库管理员还可以允许会修改数据库内部行为且通常需要提升权限的更复杂扩展所需的“PostgreSQL 挂钩”。

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

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

TLE for PostgreSQL 现已在所有亚马逊云科技区域推出，其中包括由光环新网运营的亚马逊云科技中国（北京）区域和由西云数据运营的亚马逊云科技中国（宁夏）区域。

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

Aurora 和 Amazon RDS 支持一组数量超过 85 个的精选 PostgreSQL 扩展。亚马逊云科技根据亚马逊云科技责任共担模式管理其中每个扩展的安全风险。这一组扩展中包含实现 TLE for PostgreSQL 的扩展。您编写的扩展或从第三方源获取并安装在 TLE 中的扩展将被视为应用程序代码的组成部分。您需要对使用 TLE 扩展的应用程序的安全性负责。

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

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

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

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

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

Amazon RDS 蓝绿部署

全部打开

Amazon RDS 蓝绿部署可用于 Amazon Aurora MySQL 兼容版、Amazon RDS for MySQL 和 Amazon RDS for MariaDB。

Amazon RDS 蓝绿部署可用于 Amazon Aurora MySQL 兼容版 5.6 及更高版本、RDS for MySQL 5.7 及更高版本，以及 RDS for MariaDB 10.2 及更高版本。有关可用版本的更多信息，请参阅 Aurora、RDS for MySQL 和 RDS for MariaDB 文档。

Amazon RDS 蓝绿部署现已在所有亚马逊云科技区域推出，其中包括由光环新网运营的亚马逊云科技中国（北京）区域和由西云数据运营的亚马逊云科技中国（宁夏）区域。

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

例如：您有一个 RDS for MySQL 5.7 数据库在采用多可用区（MAZ）配置的亚马逊云科技中国（宁夏）区域的两个 r5.2xlarge db.instance（一个主数据库实例和一个只读副本）上运行。每个 r5.2xlarge db.instance 都配置了 20 GiB 通用 Amazon Elastic Block Storage（EBS）。您使用 Amazon RDS 蓝绿部署创建蓝色实例拓扑的克隆，运行 15 天（360 小时），然后在成功切换后删除蓝色实例。以按需费率 13.34 元/小时（实例 + EBS 成本）计算，15 天的蓝色实例的成本为 4802.85 元。在这 15 天内，使用蓝绿部署的总成本为 9605.7 元，即该时间段内运行蓝色实例成本的 2 倍。

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

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

当 Amazon RDS 蓝绿部署启动切换时，对蓝色和绿色环境的写入会被阻止，直至切换完成。在切换期间，模拟环境（即绿色环境）会跟上生产系统进度，从而确保模拟环境和生产环境之间的数据保持一致。生产和模拟环境完全同步后，蓝绿部署会通过将流量重定向到新提升的生产环境，来将模拟环境提升为新的生产环境。蓝绿部署设计为在切换完成后再启用对绿色环境的写入，从而确保在切换过程中实现零数据丢失。

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

Amazon RDS 蓝绿部署切换防护机制会阻止对您的蓝色和绿色环境进行的写入，直到绿色环境跟上进度，然后再切换。蓝绿部署还会对蓝色和绿色环境中的主实例和副本实例执行运行状况检查。例如，它们还会执行复制运行状况检查，以查看复制是否已停止或是否存在错误。它们会检测在蓝色与绿色环境之间长时间运行的事务。您可以指定允许的最长停机时间（最短可为 30 秒）。一旦正在进行的事务超过此值，则切换将超时。

否，Amazon RDS 蓝绿部署不支持全球数据库、Amazon RDS 代理、跨区域只读副本或级联只读副本。

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