执行 Amazon Aurora 概念验证

在下文中，您可以找到有关如何为 Aurora 设置和运行概念验证的说明。概念验证是一种调查，执行此调查可了解 Aurora 是否适用于您的应用程序。概念验证可帮助您了解您自己的数据库应用程序环境中的 Aurora 功能，以及 Aurora 与您当前数据库环境相比较的情况。它还可显示移动数据、移植 SQL 代码、调整性能以及适应您当前管理过程所需完成的工作量。

在本主题中，您可以找到运行概念验证所涉高级过程和决策的概述和分步大纲，如下所示。如需详细说明，您可以使用相关链接转到特定主题的完整文档。

Aurora 概念验证概述

执行 Amazon Aurora 概念验证时，可了解将现有数据和 SQL 应用程序移植到 Aurora 需采取的措施。您可使用代表生产环境的大量数据和活动大规模练习使用 Aurora 的重要内容。这样，旨在确信 Aurora 是否能够完美应对您之前的数据库基础设施无法应对的挑战。在概念验证结束时，您可制订可靠的计划进行更大规模的性能基准测试和应用程序测试。此时，您可了解进行生产部署时所需完成的最重要的工作项。

以下最佳实践建议可帮助您避免导致基准测试出现问题的常见错误。但本主题不介绍执行基准测试和优化性能的分步过程。这些过程因工作负载和所用 Aurora 功能而异。有关详细信息，请参阅与性能相关的文档，比如管理 Aurora 数据库集群的性能和扩展、Amazon Aurora MySQL 性能增强、Amazon Aurora PostgreSQL 的性能和扩展 和在 Amazon Aurora 上使用性能详情监控数据库负载。

本主题的信息主要适用于组织写入代码、设计架构所使用的应用程序以及支持 MySQL 和 PostgreSQL 开源数据库引擎的应用程序。如果是测试商业应用程序或使用应用程序框架生成的代码，则可能无法灵活应用这些指导原则。在此类情况下，请咨询您的AWS代表，了解是否有适合您的应用程序类型的 Aurora 最佳实践或案例研究。

1. 确定目标

作为概念验证的一部分评估 Aurora 时，您可以选择要测出哪些测量值以及如何评估练习是否成功。

您必须确保应用程序的所有功能均与 Aurora 兼容。由于 Aurora 主要版本与 MySQL 和 PostgreSQL 的相应主要版本兼容，因此针对这些引擎开发的大多数应用程序也与 Aurora 兼容。不过，您仍须验证每个应用程序的兼容性。

例如，您设置 Aurora 集群时做出的某些配置选择会影响您是否可以或应该使用特定数据库功能。您可以先确定一种最通用的 Aurora 集群，即预配置集群。然后可以确定无服务器或并行查询等专用配置是否有益于您的工作负载。

使用以下问题帮助确定并量化您的目标：

花时间积累有关 Aurora 数据库引擎和平台功能的知识，并参阅本服务文档。注意有助于您达到预期结果的所有功能。其中一个功能可能是工作负载整合，有关说明信息，请参阅 AWS 数据库博客文章如何计划和优化 Amazon Aurora 与 MySQL 的兼容性以实现工作负载整合。另一个功能可能是按需扩展，有关说明信息，请参阅 Amazon Aurora 用户指南中的Amazon Aurora Auto Scaling 与 Aurora 副本结合使用。其他功能可能是性能改善或简化数据库操作等功能。

2. 了解工作负载特性

在预期的使用案例环境下评估 Aurora。Aurora 非常适用于线上事务处理 (OLTP) 工作负载。您还可以对支持实时 OLTP 数据的集群运行报告，而无需预置单独的数据仓库集群。通过核对以下特性，您可以识别您的使用案例是否属于这些类别：

影响数据库选择的一个关键因素是数据的速度。高速度包括非常频繁地插入和更新数据。这样的系统可能涉及数千个连接，数十万项并行的数据库读写查询。高速度系统中的查询所影响的行数通常比较少，并且通常是访问同一行中的多个列。

Aurora 经设计可处理高速度数据。根据工作负载，具有单个 r4.16xlarge 数据库实例的 Aurora 集群每秒可以处理 600,000 多个 SELECT 语句。这样的集群可以每秒处理 200,000 INSERT、UPDATE 和 DELETE 语句，具体同样取决于工作负载。Aurora 是一种行存储数据库，非常适用于高容量、高吞吐量和高度并行化的 OLTP 工作负载。

Aurora 还可以对处理 OLTP 工作负载的同一集群运行报告查询。Aurora 支持多达 15 个副本，每个副本平均花费不到主实例 10 - 20 毫秒的时间。分析师可以实时查询 OLTP 数据，无需将数据复制到单独的数据仓库集群。鉴于 Aurora 集群应用并行查询功能，您可以将大量处理、筛选和聚合工作分载到大规模分布式 Aurora 存储子系统。

使用此计划阶段可让自己熟悉 Aurora 的功能、其他AWS服务、AWS Management Console和 AWS CLI。此外，还可以了解这些工具如何与您打算在概念验证中使用的其他工具结合使用。

3. 使用 AWS Management Console或 AWS CLI 进行练习

下一步是使用AWS Management Console或 AWS CLI 进行练习，以熟悉这些工具和 Aurora。

使用 AWS Management Console进行练习

下面主要介绍最初使用 Aurora 数据库集群的活动，以便您熟悉AWS Management Console环境，练习设置和修改 Aurora 集群。如果将 MySQL 兼容版和 PostgreSQL 兼容版数据库引擎与 Amazon RDS 结合使用，可以在使用 Aurora 时根据这类知识执行操作。

通过利用 Aurora 共享存储模式和功能（比如复制和快照），您可以将整个数据库集群视为另一种可随意操作的对象。您可以在概念验证过程中频繁设置、拆分和更改 Aurora 集群的容量。而不会因早期做出的容量、数据库设置和物理数据布局等相关选择受到限制。

要开始使用，请设置一个空 Aurora 集群。最初试验时，可选择 provisioned (预配置) 容量类型和 regional (区域) 位置。

使用 SQL 命令行应用程序等客户端程序连接到该集群。首先，使用集群终端节点连接。连接到该终端节点可执行任何写入操作，比如数据定义语言 (DDL) 语句以及提取、转换、加载 (ETL) 流程。随后在概念验证中，可使用读取器终端节点连接查询密集型会话，该终端节点将查询工作负载分配到集群的多个数据库实例中。

通过添加更多 Aurora 副本扩展集群。有关这些步骤的信息，请参阅使用 Amazon Aurora 进行复制。通过更改 AWS 实例类扩展或缩减数据库实例。了解 Aurora 如何简化这些类型的操作，以便在初次估计的系统容量不正确时，可以随后做出调整，而无需从头开始操作。

创建快照，并将其还原到其他集群中。

检查集群指标以了解一段时间的活动，以及这些指标如何应用于集群中的数据库实例。

刚开始时，熟悉如何通过 AWS Management Console执行这些操作很有用。在了解可以使用 Aurora 执行的操作后，可以继续使用 AWS CLI 自动执行这些操作。在以下部分，您可找到有关概念验证期间这些活动的过程和最佳实践的更多详细信息。

使用 AWS CLI进行练习

我们建议自动执行部署和管理步骤，即使是在概念验证设置时也是如此。为此，请尚未熟悉 AWS CLI 的用户先熟悉相关操作。如果将 MySQL 兼容版和 PostgreSQL 兼容版数据库引擎与 Amazon RDS 结合使用，可以在使用 Aurora 时根据这类知识执行操作。

Aurora 通常包含多个排列在集群中的数据库实例组。因此，许多操作都包括确定与特定集群关联的数据库实例，然后对这些实例循环执行管理操作。

例如，您可以自动执行多个步骤，比如创建 Aurora 集群，然后使用更多实例类扩展这些集群，或使用其他数据库实例扩展这些集群。这样可帮助您在概念验证中重复任何阶段，以及使用不同种类或配置的 Aurora 集群了解假设场景。

了解 AWS CloudFormation 等基础设施部署工具的功能和限制。您可能会发现，在概念验证环境下完成的活动不适用于生产环境。例如，AWS CloudFormation 的修改行为将创建新实例，并删除当前实例，包括其数据。有关此行为的更多详细信息，请参阅 AWS CloudFormation 用户指南中的堆栈资源的更新行为。

4. 创建 Aurora 集群

使用 Aurora，可通过将数据库实例添加到集群，并将数据库实例扩展为更强大的实例类来了解假设场景。您还可以使用不同配置设置创建集群，以并行运行相同的工作负载。使用 Aurora，您可灵活设置、拆分和重新配置数据库集群。因此，在概念验证过程的早期阶段练习这些方法很有用。有关创建 Aurora 集群的常规过程，请参阅创建 Amazon Aurora 数据库集群。

如果可行，请先使用以下设置创建集群。仅在考虑使用某些特定使用案例时才跳过此步骤。例如，如果您的使用案例需要使用一种专用 Aurora 集群，您可以跳过此步骤。或者，如果您需要特定的数据库引擎和版本组合，也可以跳过此步骤。

5. 设置架构

在 Aurora 集群上，可为您的应用程序设置数据库、表、索引、外键和其他架构对象。如果是从其他 MySQL 兼容版或 PostgreSQL 兼容版数据库系统进行迁移，则要求此阶段的操作简单直接。您可以使用相同的 SQL 语法和命令行或您熟悉的适用于数据库引擎的其他客户端应用程序。

要在您的集群上发送 SQL 语句，请找到其集群终端节点，并提供该值作为连接到客户端应用程序的参数值。您可以在集群详细信息页面的 Connectivity (连接) 选项卡上找到集群终端节点。此集群终端节点是标记为 Writer 的终端节点。其他标记为 Reader 的终端节点表示只读连接，您可向运行报告或其他只读查询的最终用户提供这类连接。有关连接到集群时出现问题的帮助信息，请参阅连接到 Amazon Aurora 数据库集群。

如果是从其他数据库系统移植架构和数据，此时要求做出某些架构更改。这些架构更改要与 Aurora 中的可用 SQL 语法和功能相匹配。此时，您可能要舍弃某些列、约束、触发器或其他架构对象。如果这些对象要求改动 Aurora 兼容性，并且不能帮助您实现概念验证的目标，则这样做特别有用。

如果是从其他数据库系统迁移，且此系统使用的底层引擎与 Aurora 的不同，则需考虑使用 AWS Schema Conversion Tool (AWS SCT) 简化此过程。有关详细信息，请参阅AWS Schema Conversion Tool 用户指南。有关迁移和移植活动的一般详细信息，请参阅 AWS 白皮书《将数据库迁移到 Amazon Aurora》。

在此阶段，您可以评估您的架构设置是否存在效率低下的问题，例如在对策略或分区表等其他表结构建立索引时。在具有多数据库实例和极大工作负载的集群上部署应用程序时，这种效率低下的问题会被放大。请考虑是立即微调这类性能问题，还是在稍后的完整基准测试等活动中微调。

6. 导入数据

在概念验证期间，您需要从以前的数据库系统导入数据或代表示例。如果可行，至少在每个表中设置一些数据。这样，有助于测试所有数据类型和架构功能的兼容性。在练习使用基本 Aurora 功能后，可扩展数据量。在完成概念验证时，您应使用大得足以得出准确结论的数据集测试您的 ETL 工具、查询和全部工作负载。

您可以使用多种方法将物理或逻辑备份数据导入 Aurora。有关详细信息，请根据您在概念验证中使用的数据库引擎参阅将数据迁移到 Amazon Aurora MySQL 数据库集群或将数据迁移到与 PostgreSQL 兼容的 Amazon Aurora。

使用您考虑使用的 ETL 工具和方法试验。了解哪种工具和方法最符合您的需求。您需要考虑吞吐量和灵活性。例如，某些 ETL 工具是执行一次性传输，而其他工具是将原来系统中的数据持续复制到 Aurora。

如果是从 MySQL 兼容版系统迁移到 Aurora MySQL，可以使用本机数据传输工具。如果是从 PostgreSQL 兼容版系统迁移到 Aurora PostgreSQL，同样可应用本机数据传输工具。如果是从其他数据库系统迁移，且此系统使用的底层引擎与 Aurora 的不同，则可以使用 AWS Database Migration Service (AWS DMS) 进行试验。有关 AWS DMS 的详细信息，请参阅 AWS Database Migration Service 用户指南。

有关迁移和移植活动的详细信息，请参阅AWS白皮书的 Aurora 迁移手册。

7. 移植 SQL 代码

试验 SQL 和相关应用程序需要完成不同的工作量，具体取决于不同的案例。具体而言，工作量取决于是从 MySQL 兼容版系统还是 PostgreSQL 兼容版系统，抑或是其他类型的系统迁移。

在此阶段，您可以评估您的架构设置是否存在效率低下的问题，例如在对策略或分区表等其他表结构建立索引时。请考虑是立即微调这类性能问题，还是在稍后的完整基准测试等活动中微调。

您可以验证应用程序的数据库连接逻辑。为利用 Aurora 分布式处理，您可能需要使用单独的连接来执行读写操作，并使用相对较短的会话来完成查询操作。有关连接的信息，请参阅 9. 连接到 Aurora。

考虑是否必须妥协和取舍才能解决生产数据库中的问题。花时间研究概念验证计划，以改进您的架构设计和查询。为判定是否可以轻松提高性能、降低运营成本和提高可扩展性，可尝试在不同 Aurora 集群上并行运行原始应用程序和修改的应用程序。

有关迁移和移植活动的详细信息，请参阅AWS白皮书的 Aurora 迁移手册。

8. 指定配置设置

作为 Aurora 概念验证练习的一部分，您还可以检查您的数据库配置参数。您可能已针对性能和可扩展性在当前环境下优化了 MySQL 或 PostgreSQL 配置设置。此 Aurora 存储子系统是针对带有高速存储子系统的基于云的分布式环境进行调整和优化的。因此，许多以前的数据库引擎设置都不适用了。我们建议使用默认的 Aurora 配置设置进行初步试验。仅当您遇到性能和可扩展性瓶颈时，才重新应用您当前环境中的设置。如果您有兴趣，可在 AWS 数据库博客上的 Aurora 存储引擎简介中更深入地了解此主题。

Aurora 可让您对特定应用或使用案例轻松重用最佳配置设置。您无需为每个数据库实例编辑单独的配置文件，只需管理分配给整个集群或特定数据库实例的参数集。例如，时区设置适用于集群中的所有数据库实例，而您可以调整每个数据库实例的页面缓存大小设置。

您可先应用默认参数集之一，然后仅对需要微调的参数进行更改。有关使用参数组的详细信息，请参阅 Amazon Aurora 数据库集群和数据库实例参数。有关是否适用于 Aurora 集群的配置设置，请根据您的数据库引擎参阅 Aurora MySQL 配置参数或 Amazon Aurora PostgreSQL 参数。

9. 连接到 Aurora

您会发现，在进行初始架构和数据设置并运行示例查询时，您可以连接到 Aurora 集群中的不同终端节点。使用的终端节点取决于操作是读取（比如 SELECT 语句）还是写入（比如 CREATE 或 INSERT 语句）。在增加 Aurora 集群上的工作负载和使用 Aurora 功能试验时，请务必让应用程序向相应的终端节点分配每个操作。

通过对写入操作使用集群终端节点，您可始终连接到集群中具有读/写功能的数据库实例。默认情况下，Aurora 集群中仅一个数据库实例具有读/写功能。此数据库实例被称为主实例。如果原始主实例不可用，则 Aurora 会激活故障转移机制，并且其他数据库实例会接任主实例。

同样，通过将 SELECT 语句定向到读取器终端节点，可将处理查询的工作分布到集群的各数据库实例中。通过轮询 DNS 解析可将每个读取器连接分配给不同的数据库实例。在只读数据库 Aurora 副本上完成大部分查询工作，可减少主实例的负载，让其能够处理 DDL 和 DML 语句。

使用这些终端节点可减少对硬编码主机名的依赖，并可帮助您的应用程序更快速地从数据库实例故障中恢复。

Aurora 副本会受副本滞后影响，即使该滞后通常是 10 到 20 毫秒。您可以监控复制滞后，并确定该值是否在数据一致性要求的范围内。在某些情况下，读取查询可能要求严格的读取一致性（先写后读一致性）。在这些情况下，您可以继续对其使用集群终端节点，而不是读取器终端节点。

为充分利用 Aurora 功能实现分布式并行执行，您可能需要更改连接逻辑。目的是避免将所有读取请求发送到主实例。只读 Aurora 副本将使用所有相同的数据待命，准备处理 SELECT 语句。对应用逻辑编码可对每种操作使用相应的终端节点。请遵循以下一般准则：

有关 Aurora 连接管理和终端节点的一般信息，请参阅连接到 Amazon Aurora 数据库集群。有关此主题的深入分析，请参阅 Aurora MySQL 数据库管理员手册 – 连接管理。

10. 运行工作负载

在准备好架构、数据和配置设置后，可以通过运行工作负载开始练习使用集群。在概念验证中使用反映生产工作负载主要内容的工作负载。我们建议始终使用实际测试和工作负载而非 sysbench 或 TPC-C 等合成基准做出性能相关决策。如果可行，请根据自己的架构、查询模式和用量收集测量值。

只要可行，请复制应用程序运行所依据的实际条件。例如，您通常在与 Aurora 集群相同的AWS区域和相同的 Virtual Private Cloud (VPC) 中的 Amazon EC2 实例中运行应用程序代码。如果您的生产应用程序是在跨多可用区的多个 EC2 实例中运行，请按同样的条件设置概念验证环境。有关AWS区域的更多信息，请参阅 Amazon RDS 用户指南中的区域和可用区。要了解有关 Amazon VPC 服务的更多信息，请参阅 Amazon VPC 用户指南 中的什么是 Amazon VPC？

在验证应用程序的基本功能是否有效并且是否可以通过 Aurora 访问数据后，可以练习使用 Aurora 集群的内容。您可能要尝试使用的某些功能包括具有负载均衡功能的并发连接、并发事务和自动复制。

现在，您应该熟悉数据传输机制了，因此可以使用更大比例的示例数据运行测试。

在此阶段，您可以看到更改配置设置（比如内存限制和连接限制）的效果。您可以重新访问 8. 指定配置设置中所探讨的过程。

您还可以使用创建和还原快照等机制试验。例如，您可以使用不同 AWS 实例类、AWS 副本编号等创建集群。然后在每个集群上，您可以还原相同的快照，其中包含架构和所有数据。有关该循环操作的详细信息，请参阅创建数据库集群快照和从数据库集群快照还原。

11. 衡量性能

此操作范围的最佳实践可确保设置所有适用工具和流程，以便在工作负载操作期间快速隔离异常行为。此外，您还可通过设置这些对象来了解是否可以可靠地确定所有适用原因。

您始终可以通过检查 Monitoring (监控) 选项卡，了解集群的当前状态，或检查一段时间的趋势。此选项卡位于每个 Aurora 集群或数据库实例的控制台详细信息页面中。其中以图表形式显示 Amazon CloudWatch 监控服务中的指标。您可以按名称、数据库实例和时间段筛选这些指标。

要在 Monitoring (监控) 选项卡上使用更多选项，请在集群设置中启用“Enhanced Monitoring (增强监控)”和 Performance Insights。如果在设置集群时未选择这些选项，您也可以以后启用这些选项。

为测量性能，通常需依赖显示全部 Aurora 集群活动的图表。您可以验证 Aurora 副本的负载和响应时间是否相似。您还可以了解读写主实例和只读 Aurora 副本之间的工作是如何划分的。如果数据库实例之间的负载不均衡，或存在仅影响一个数据库实例的问题，您可以针对该特定实例检查 Monitoring (监控) 选项卡。

在设置环境和实际工作负载以模拟生产应用程序后，可以测量 Aurora 的运行性能。要了解的最重要的问题如下：

要查看吞吐量和延迟指标，请在 Amazon RDS 控制台中查看给定 Aurora 集群的监控选项卡。以下屏幕截图显示了监控选项卡上选择延迟、DML 延迟、选择吞吐量和 DML 吞吐量指标的示例。

如果可以创建这些指标的基准值，请在当前环境下执行此操作。如果不可行，可通过执行等同于生产应用程序的工作负载来构建 Aurora 集群的相关基准。例如，运行并行用户数量和查询数量相当的 Aurora 工作负载。然后观察使用不同实例类、集群大小、配置设置等试验时这些值的变化情况。

如果吞吐量数值低于预期值，可针对工作负载进一步调查影响数据库性能的因素。同样，如果延迟数值高于预期值，也可以进一步调查。为此，需监控数据库服务器的二级指标（CPU、内存等）。您可以了解这些数据库实例是否接近其限制。您还可以了解数据库实例可使用多少附加容量来处理更多并行查询，对更大的表运行查询等。

在评估理想的 Aurora 集群大小和容量时，您可以找到既能达到应用程序性能峰值又不会超额配置资源的配置。其中一个重要因素是，为 Aurora 集群中的数据库实例找到适宜的大小。首先，选择一个实例大小，其 CPU 和内存容量与您当前生产环境的配置相似。为该实例大小的工作负载收集吞吐量和延迟数值。然后，将实例扩展到更大规模。了解吞吐量数值是否会增长，延迟数值是否会降低。您也可以缩减实例大小，然后了解延迟和吞吐量数值是否保持不变。目的是在可能最小的实例中实现最高的吞吐量和最短的延迟。

确保性能测试运行时间足够长，以便在热稳定状态下测量数据库性能。您可能需要运行工作负载几分钟，甚至几小时才能达到此稳定状态。运行开始时出现一些差异是正常的。出现这样的差异是因为每个 Aurora 副本都会根据所处理的 SELECT 查询预热其缓存。

Aurora 最适合处理涉及多个并行用户和查询的事务型工作负载。为确保以最佳性能驱动足够多的负载，您可运行使用多线程的基准测试，或同时运行多个实例的性能测试。测量使用数百个，甚至数千个并行客户端线程时的性能。模拟您希望在生产环境下使用的并行线程的数量。您还可以使用更多线程执行额外的压力测试，以测量 Aurora 可扩展性。

12. 练习使用 Aurora 高可用性

许多主要的 Aurora 功能都涉及高可用性。这些功能包括自动复制、自动故障转移、自动备份及时间点还原，以及将数据库实例添加到集群的功能。这类功能的安全性与可靠性对任务关键型应用程序极重要。

评估这些功能需要应用特定思维模式。在性能测量等早期活动中，您已观察了系统正常运行时的性能。测试高可用性要求您全面考虑最糟糕情况下的行为。您必须考虑到各种故障，即使很少出现这样的情况。您可以故意引发问题，以确保系统快速准确地恢复正常。

我们建议在每个 Aurora 集群中至少使用两个实例。Aurora 集群中的数据库实例最多可跨三个可用区 (AZ)。前两个或前三个数据库实例各自位于不同的 AZ 中。在开始使用更大的集群时，可将数据库实例分布到 AWS 区域的所有 AZ 中。这样可提高容错能力。即使某问题影响到某个 AZ，Aurora 也可以将故障转移到其他 AZ 的数据库实例。如果您运行的集群所包含的实例超过三个，请将这些数据库实例尽可能均匀地分布到三个 AZ 上。

要了解如何模拟失败条件以测试高可用性功能，请参阅使用错误注入查询测试 Amazon Aurora MySQL。

作为概念验证练习的一部分，其中一个目标是找到理想的数据库实例数量，并为这些数据库实例找到最佳实例类。这样需要平衡高可用性和性能要求。

对于 Aurora，集群中的数据库实例越多，高可用性的优势越大。增加数据库实例，还可提高读取密集型应用程序的可扩展性。Aurora 可以在只读的 Aurora 副本中分发多个 SELECT 连接查询。

而另一方面，限制数据库实例的数量会减少主节点的复制流量。复制流量会消耗网络带宽，这涉及总体性能和可扩展性问题。因此，对于写入密集型 OLTP 应用程序，宁可使用较少数量的大数据库实例，也不要使用大量小数据库实例。

在典型的 Aurora 集群中，一个数据库实例（主实例）处理所有 DDL 和 DML 语句。而其他数据库实例（Aurora 副本）仅处理 SELECT 语句。尽管这些数据库实例的工作量并不完全相同，我们还是建议对集群中的所有数据库实例使用相同的实例类。这样，在发生故障并且 Aurora 将其中一个只读数据库实例提升为新的主实例时，此主实例的容量才会与之前的容量相同。

如果需要在同一集群中使用不同容量的数据库实例，请为这些数据库实例设置故障转移层。这些故障转移层可确定根据故障转移机制提升 Aurora 副本的顺序。将比其他数据库实例大得多或小得多的数据库实例放到较低的故障转移层。这样可确保提升时最后选择这些数据库实例。

练习使用 Aurora 的数据恢复功能，比如自动执行时间点还原、手动快照和还原以及集群回溯。如果适用，可将快照复制到其他 AWS 区域，还原到其他 AWS 区域以模拟 DR 场景。

调查您所在组织的还原时间目标 (RTO)、还原点目标 (RPO) 和地理冗余的要求。大多数组织将这些项目分类到灾难恢复这一大类下。您可在灾难恢复过程中评估本节介绍的 Aurora 高可用性功能，以确保满足您的 RTO 和 RPO 要求。

13. 后续操作

在概念验证过程成功结束时，您可根据预期工作负载确认 Aurora 是否是适合您的解决方案。在前面的过程中，您已确定 Aurora 在实际操作环境中的工作情况，并根据成功标准对其进行评估。

在构建数据库环境并使用 Aurora 运行后，您可以继续执行更详细的评估步骤，从而实现最终迁移和生产部署。根据个人情况，其他步骤可能包含也可能包含在概念验证过程中。有关迁移和移植活动的详细信息，请参阅AWS白皮书的 Aurora 迁移手册。

在下一步中，需考虑工作负载的相关安全配置，并设法满足生产环境的安全要求。计划要采用的控制措施，以保护对 Aurora 集群主用户凭证的访问权限。定义数据库用户的角色和责任，以控制对 Aurora 集群中存储数据的访问权限。考虑数据库访问应用程序、脚本和第三方工具或服务的要求。了解AWS服务和功能，比如 AWS Secrets Manager 和 AWS Identity and Access Management（IAM）身份验证。

现在，您应该了解使用 Aurora 运行基准测试的过程和最佳实践。您可能发现需要执行更多性能优化操作。有关详细信息，请参阅管理 Aurora 数据库集群的性能和扩展、Amazon Aurora MySQL 性能增强、Amazon Aurora PostgreSQL 的性能和扩展 和在 Amazon Aurora 上使用性能详情监控数据库负载。如果执行更多优化操作，请确保熟悉您在概念验证期间收集的指标。对于下一步，您可能要使用不同的配置设置、数据库引擎和数据库版本选项创建新集群。或者，您可能要创建多种专用的 Aurora 集群来满足特定使用案例的需求。

例如，您可以针对混合事务/分析处理 (HTAP) 应用程序探索 Aurora 并行查询集群。如果广泛的地理分布对灾难恢复至关重要或者可最大程度缩短延迟，您可探索 Aurora 全局数据库。如果工作负载是间歇性的，或者您是在开发/测试场景中使用 Aurora，则可探索 Aurora Serverless 集群。

此外，生产集群也可能需要处理大量传入连接。要了解这些技术，请参阅AWS白皮书 Aurora MySQL 数据库管理员手册 - 连接管理。

如果在概念验证后确定您的使用案例不适合使用 Aurora，请考虑使用以下AWS服务：