亚马逊AWS官方博客
Amazon RDS 多可用区部署选项比较及选型建议
在公有云环境中，托管的关系数据库服务，无论是针对开源数据库还是商业数据库，所使用的数据库引擎均为业界经过多年验证且广受认可的，这些数据库在数据一致性、准确性、持久性和稳定性等方面的表现很少受到质疑。相反，我们更加关注数据库的高可用性、高性能以及可管理性，这些因素对于数据库管理员和架构师来说，是在设计和维护数据库系统时需要权衡的关键点。
高可用性指的是数据库在各种情况下均能保持可访问性，包括但不限于硬件故障、网络故障和软件故障等。云上的关系数据库服务通常采用多副本部署的方式实现高可用性。通过主副本之间的数据复制机制，确保数据同步。一旦主实例发生故障，系统能够自动切换至备用副本，从而保障数据库的持续可用。
高性能指的是数据库能够以高效的方式处理用户的各种请求，包括查询请求、写入请求等。云上关系数据库服务通常借助水平扩展、垂直扩展和数据库优化等多种技术手段来提升性能，确保系统能够高效地响应用户的操作，提高数据库整体性能水平。
可管理性关乎数据库系统配置、监控、维护和优化的便捷性。高可管理性的数据库能够简化日常运维工作，减少管理成本，并提高系统稳定性。云上关系数据库服务通常通过提供丰富的管理工具和自动化策略（如自动备份、性能监控、故障诊断、数据迁移和版本升级等）来增强其可管理性，这些功能有助于减少人为错误，提高操作效率。
在设计和部署云上的关系数据库系统时，根据业务需求、未来规划、成本预算和运维管理等因素进行综合考虑，是制定合适的数据库架构和配置的关键。亚马逊云科技（Amazon Web Services，AWS）为其托管的关系数据库服务 Amazon RDS 提供了多种部署选项，这些选项综合考虑了高可用性、高性能和可管理性，以适应不同的业务场景和需求。
本文接下来将对 Amazon RDS 的多可用区部署选项从高可用性、高性能和可管理性几个维度进行比较，并提供选型建议。同时，考虑到在不同部署选项之间可能存在的转换或迁移需求，本文也将对此进行探讨，以供读者在未来的规划和决策中参考。
Amazon RDS 多可用区部署选项概览
Amazon RDS Multi-AZ DB Instance
这个选项也是我们通常意义最早提到的 Amazon RDS 多可用区功能，此选项自动在不同可用区中配置和维护一个同步的备用副本。主数据库实例将跨可用区同步复制到备用副本，以提供数据冗余并在系统备份期间将延迟峰值降至最小。使用多可用区数据库实例可提供高可用性，但备用副本不支持读取工作负载的连接，此选项并不适合只读场景的扩容方案。
 |
Amazon RDS Multi-AZ DB Cluster
这是在 2022 年 3 月新发布的多可用区部署选项，选择这个选项会创建包含三个数据库实例的数据库集群。每个数据库实例都位于不同可用区中，包含有一个主数据库实例和两个可读的备用数据库实例。使用多可用区数据库集群可提供高可用性、增加读取工作负载的容量并降低延迟。
在此之前，Amazon RDS 提供了两种数据同步和复制选项以增强可用性和性能，一是前面提到的 Amazon RDS Multi-AZ DB Instance 可提供高可用性和跨可用区的自动故障转移功能。另一个是只读副本允许应用跨多个数据库只读实例扩展其读取能力。Amazon RDS Multi-AZ DB Cluster 结合了这两个方面的功能，在提供高可用性的同时也具备一定的读取能力的扩展，且提供了两个终端节点，方便用户使用单独的端点进行数据的写入和读取，有非常好的便利性。
 |
Amazon Aurora 预置集群
Amazon Aurora 是 AWS 历史上增长最快的服务，数十万 AWS 客户将其用于关系数据库。Aurora 数据库集群包含一个或多个数据库实例以及一个管理这些数据库实例的数据的集群卷。Aurora 集群卷由单个 AWS 区域中跨三个可用区的数据副本组成，每个可用区存放 2 个数据副本，共计 6 个副本。集群卷的数据复制基于 Quorum 协议，单个可用区的失败不会影响 Aurora 集群的数据写入。
Aurora 数据库集群由两类数据库实例组成：
- 主数据库实例：支持读取和写入操作，并执行针对集群卷的所有数据修改。每个 Aurora 数据库集群均有一个主数据库实例。
- 只读副本：连接到同一存储卷并仅支持读取操作，增加只读副本并不会消耗更多的存储 IO。除主数据库实例之外，每个 Aurora 数据库集群最多可拥有 15 个只读副本。通过将只读副本放在单独的可用区中维护高可用性，当主数据库实例不可用时，Aurora 自动故障转移到只读副本。可以为只读副本指定故障转移优先级，只读副本还可以从主数据库实例分担读取工作负载。
我们通常在不同于 Aurora 主实例所在可用区创建一个或多个只读副本，以提高 Aurora 数据库实例的高可用性。如果 Aurora 数据库集群不包含任何只读副本，则将在故障事件期间在同一可用区中重新创建主实例。将 Aurora 只读副本提升为主实例要比创建新的主实例快得多。
 |
Amazon Aurora Serverless v2
Aurora Serverless 是 Amazon Aurora 提供的一种按需自动扩展的服务配置，旨在自动监控工作负载并根据应用程序的需求调整数据库容量。这种模式允许容量根据实际使用情况自动增减，确保用户仅需为其数据库集群实际使用的资源支付费用。Aurora Serverless 保持了与 Amazon Aurora 预置集群相同的底层架构，包括数据库实例组成和数据库存储卷，但提供了无服务器的灵活性和简便性。
作为 Aurora Serverless 的进阶版本，Aurora Serverless v2 相比于其前身 Aurora Serverless v1，提供了更快的扩展速度、更细的扩展粒度和更少的运行中断。这一新版本不仅继承了 v1 的核心优点，还与 Aurora 预置集群的功能更加一致，包括但不限于支持 Aurora 只读副本、全局数据库、多可用区集群、IAM 数据库身份验证、Performance Insights 和 RDS 代理等。这些功能的支持使得 Aurora Serverless v2 成为支持更复杂和要求更高的无服务器数据库应用场景的理想选择。
Amazon RDS 多可用区部署选项比较
| 多可用区部署选项 | Amazon RDS Multi-AZ DB Instance |
Amazon RDS Multi-AZ DB Cluster |
Amazon Aurora 预置集群 |
Amazon Aurora Serverless v2 |
| 支持引擎 | Amazon RDS for PostgreSQL Amazon RDS for MySQL Amazon RDS for MariaDB Amazon RDS for SQL Server (Mirroring / Always On) Amazon RDS for Oracle Amazon RDS for DB2 |
Amazon RDS for PostgreSQL Amazon RDS for MySQL |
Aurora PostgreSQL Aurora MySQL |
Aurora PostgreSQL Aurora MySQL |
| 数据同步机制 | 基于 EBS 卷的同步数据复制（物理复制） | 使用数据库原生半同步复制（逻辑复制），只需要来自至少一个备用数据库实例的确认就能提交更改，不需要确认事务已在所有副本上完全执行和提交。 | Aurora 数据存储在使用 SSD 的集群卷中，集群卷由同一个 AWS 区域中跨三个可用区的 6 份数据副本组成，数据会自动跨可用区复制。存储层复制遵循 Quorum 协议。 | 同 Aurora 预置集群 |
| 节点数量 | 缺省创建主实例（读写） + 1 备用实例（不可读）两个节点。额外再最多创建 15 个只读副本（RDS PostgreSQL & RDS MySQL） | 缺省创建主实例（读写） + 2 备用实例（只读）三个节点。额外再最多创建 15 个只读副本 | 缺省创建主实例（读写）或主实例（读写）+ 1 个只读副本。最多创建 15 个只读副本 | 缺省创建主实例（读写）或主实例（读写）+ 1 个只读副本。最多创建 15 个只读副本 |
| 多可用区支持 | Y （2 AZ，主实例和备用实例在不同的 AZ 里） | Y（3 AZ，主实例和两个只读实例在不同的 AZ 里） | Y（3 AZ，主实例和只读副本在不同的 AZ 里） | Y（3 AZ，主实例和只读副本在不同的 AZ 里） |
| 多副本支持 | Y | Y | Y | Y |
| 存储自动扩展支持 | Y | N | Y | Y |
| 最大存储 | 64 TB (RDS SQL Server 最大 16TB) | 64 TB | 128 TB | 128 TB |
| 可扩展性 | 一般 | 中等 | 高 | 高 |
| 高可用性 | 中等 | 高 | 高 | 高 |
| 终端节点 | 一个终端节点 | 两个终端节点：一个写入端点、一个只读端点 | 两个终端节点：一个写入端点、一个只读端点 | 两个终端节点：一个写入端点、一个只读端点 |
| 故障切换 | 1. 支持自动故障转移功能，最快 60 秒即可完成，零数据丢失且无需手动干预 2. 故障转移时间与写入吞吐量无关 |
1. 支持自动故障转移功能，通常用时不超过 35 秒，不会丢失数据，无需手动干预 2. 故障转移时间取决于副本滞后的长度 |
如果 Aurora 集群具有一个或多个只读副本，则只读副本将在故障事件期间被提升为主实例。故障事件将导致短暂中断，其间的读取和写入操作将失败并引发异常，服务通常会 30-60 秒内还原。要提高 Aurora 集群的可用性，建议在两个或更多的不同的可用区中创建至少一个或多个只读副本。 | 同 Aurora 预置集群 |
| 性能 | 由于使用了同步数据复制，与单可用区部署相比，数据库实例会增加写入和提交延迟。 | 写入操作会变得更快，它提供的事务提交延迟可提速 2 倍 | Amazon Aurora 通过将数据库引擎与为数据库工作负载构建的基于 SSD 的虚拟化存储层紧密集成，从而减少至存储系统的写入操作，最大程度降低锁竞争并消除数据库进程线程所产生的延迟。 根据 SysBench 等标准基准进行的测试表明，其吞吐量最高可达到开源 MySQL 的 5 倍，在类似硬件上运行时，其吞吐量是类似硬件上运行的开源 PostgreSQL 的 3 倍。 |
同 Aurora 预置集群 |
| 需要关注的一些限制 | NA | 1. RDS MySQL 版本需要在 8.0.28 或以上，RDS PostgreSQL 版本需要在 13.7 或以上 2. 集群的三个节点都不能临时停止 3. 不支持创建 Aurora read replica 4. Reader endpoint 只路由请求到备用只读实例，不会将请求路由到新建的只读副本 5. 不支持存储自动扩展，可以手动扩展存储 6. 仅支持预置 IOPS 存储 |
NA | 1. 不支持数据库活动流（DAS） 2. 不支持 Aurora PostgreSQL 的集群缓存管理 |
Amazon RDS 多可用区部署选项选型建议
Amazon RDS Multi-AZ DB Instance
适用于工作负载相对稳定的场景。Amazon RDS Multi-AZ DB Instance 提供了简单易用的高可用性和故障转移功能，一旦主实例发生故障，系统将自动将数据库切换至备用实例，确保应用的连续运行。我们建议在生产环境中，对数据库可靠性要求较高的关键应用采用该部署模式。通过部署备用实例，可最大限度避免单点故障导致的服务中断，从而减少潜在的业务损失。如为非生产环境，并且对可用性要求不太严格，可考虑不启用 Multi-AZ 部署以节省资源开支。
Amazon RDS Multi-AZ DB Cluster
适用于工作负载相对稳定的场景。相较于 Multi-AZ DB Instance，Multi-AZ DB Cluster 能提供更强的高可用性保证，数据库实例跨三个可用区部署，可容忍更高级别的灾难发生，尤其适合对高可用性及可靠性要求更为苛刻的应用场景。另外，它支持读写分离，能够通过只读副本提高读取扩展能力，满足高并发读取需求。但由于存在一些限制条件，在使用之前建议能够做好充分的评估和制定相应的预案。
Amazon Aurora 预置集群
适用于工作负载相对稳定的场景。Amazon Aurora 预置集群专为高性能、高吞吐量的企业级应用场景而设计，能够满足处理高并发访问的性能和可扩展性需求。同时，它还提供了诸如回溯、快速克隆、全局数据库、并行查询等更多的企业级数据库功能。因此，Aurora 预置集群尤其适合对性能、高可用性和可管理性要求更高的应用或工作负载。
Amazon Aurora Serverless v2
适用于工作负载存在较大波动或难以预测的场景。Aurora Serverless v2 能够根据实际需求自动调整计算能力，为存在大幅波动工作负载的应用优化资源成本。此外，开发测试环境、新应用部署、多租户应用等场景均可使用按需付费的 Aurora Serverless v2 服务，避免全天候运行数据库导致的资源浪费。因此，对于工作负载存在较大波峰波谷变化的应用，我们强烈建议使用 Aurora Serverless v2，一方面能有效降低成本开支，另一方面也能极大提高容量管理效率。
不同选项之间进行转换或迁移的路径
可以看到上面列出的几种 Amazon RDS 多可用区部署选项之间都存在一些差异，适用场景也有区别，因此可能会有一些在不同数据库多可用区部署选项之间进行转换或迁移的需求，这里对比较常见的转换或迁移场景进行了梳理，列出了可以采用的迁移手段或路径。
先假设几个前提说明：
- 同构迁移：源端和目标端的数据库引擎相同，均为 MySQL 或 PostgreSQL
- 暂不考虑源端和目标端的数据库版本兼容性问题
- 实际迁移实施时需基于源端和目标端数据库的具体配置信息以及具体需求进行评估和确认
| 源端\目标端 | Amazon RDS Multi-AZ DB Instance |
Amazon RDS Multi-AZ DB Cluster |
Amazon Aurora 预置集群 |
Amazon Aurora Serverless v2 |
| Amazon RDS Multi-AZ DB Instance |
N/A | 1. 导出导入 2. 还原快照 3. 通过创建只读副本 |
1. 导出导入 2. DMS 3. 通过 RDS 迁移快照功能（有条件限制） 4. 通过创建 Aurora 只读副本（有条件限制） |
1. 导出导入 2. DMS |
| Amazon RDS Multi-AZ DB Cluster |
1. 导出导入 2. 还原快照 3. 通过创建只读副本 |
N/A | 1. 导出导入 2. DMS |
1. 导出导入 2. DMS |
| Amazon Aurora 预置集群 |
N/A | N/A | N/A | 1. 导出导入 2. 还原快照 3. 通过创建只读副本 |
| Amazon Aurora Serverless v2 |
N/A | N/A | 1. 导出导入 2. 还原快照 3. 通过创建只读副本 |
N/A |
在执行数据库转换或迁移过程时，需要注意一些相关的重要事项，以确保顺利完成并避免潜在的问题：
- 在数据库迁移的过程中，版本兼容性是一个需要格外关注的问题。根据以往的经验，无论使用何种转换或迁移方式，通常都要求目标数据库的主版本号与源端保持一致，次版本号则建议与源端相同或更高，这样可以最大程度避免由于版本差异带来的兼容性问题。
- 以从 RDS MySQL 迁移到 Aurora MySQL 为例，在 AWS 中国的北京及宁夏区域，如果使用 RDS 迁移快照功能或创建 Aurora 只读副本的方式，源 RDS MySQL 版本必须为 5.6 或 5.7，暂不支持 8.0 及更高版本。在 AWS 海外区域，则已支持从 8.0 版本迁移。
- 对于 RDS PostgreSQL，如果将其通过迁移快照或只读副本的方式迁移至 Aurora PostgreSQL，同样存在版本兼容性限制。因此，在操作之前，建议大家先在 AWS 控制台上仔细查看源端和目标端的版本信息，确保版本兼容，避免出现意外情况。
- 此外，在 AWS 中国区域，目前还不支持通过还原快照的方式将 RDS Multi-AZ DB Cluster 转换为 RDS Multi-AZ DB Instance 模式，大家在操作时需要注意这一点。
- 使用 AWS 数据迁移服务 DMS 进行迁移时，也可能遇到一些特殊的兼容性问题。比如从 RDS Multi-AZ DB Cluster – PostgreSQL 迁移到 Aurora PostgreSQL，由于源端数据库的 wal_sender_timeout 参数不支持修改，可能会对数据复制过程产生影响，需要提前评估并做好应对准备。同理，从 RDS Multi-AZ DB Cluster – MySQL 迁移到 Aurora MySQL 时，由于源端数据库缺少 mysql.rds_set_configuration 存储过程，将无法修改 MySQL binlog 保存时间，也可能会对数据复制过程产生影响，同样需要提前评估并做好应对准备。
- 最后，分享一下 MySQL 和 PostgreSQL 常用的导入导出工具。MySQL 常用 mysqldump 和 mydumper/myloader 进行数据迁移，后者具备更强的性能和灵活性。PostgreSQL 比较常用的则是 pg_dump 和 pg_restore。在进行数据迁移时，熟练使用这些工具可以提高效率，减少出错几率。
总结
在前文中，我们深入探讨了 Amazon RDS 的多可用区部署选项，包括 Amazon RDS Multi-AZ DB Instance、Amazon RDS Multi-AZ DB Cluster、Amazon Aurora 预置集群以及 Amazon Aurora Serverless v2。这些选项各自具有不同的特性和优势，旨在满足不同业务场景下对高可用性、高性能和可管理性的需求。通过比较这些部署选项，我们不仅详细了解了它们在数据同步机制、节点数量、多可用区支持、多副本支持、存储自动扩展支持以及性能方面的差异，还探讨了它们在提供数据库服务方面的不同侧重点。
选择正确的部署选项对于确保数据库系统的稳定性、可靠性以及性能至关重要。无论是追求极致的高可用性，还是需要满足高并发读取的场景，或者是寻找成本效益高且灵活的数据库解决方案，Amazon RDS 和 Aurora 提供的多可用区部署选项都能满足不同的业务需求。此外，我们还讨论了从一个部署选项迁移到另一个选项的可能路径和注意事项，为那些需要在不同数据库解决方案之间转换的场景提供了实用的指导。
总结而言，正确选择和使用 Amazon RDS 的多可用区部署选项，可以极大地提升数据库系统的整体可用性和性能，同时降低运维复杂性和成本。随着业务的发展和需求的变化，理解每个选项的优势和限制，以及它们之间的转换路径，将帮助数据库管理员和架构师做出更加明智的决策，确保数据库架构能够支持业务的持续增长和成功。在选择适合自己业务的数据库解决方案时，务必综合考虑高可用性、高性能、可管理性以及成本效益等多个因素，以实现最优的数据库部署策略。
参考链接
Configuring and managing a Multi-AZ deployment
Limitations for Multi-AZ DB clusters
RDS snapshot migration
Migration using Aurora Read Replica
Migrating data to Amazon Aurora with PostgreSQL compatibility
Using an AWS-managed MySQL-compatible database as a source for AWS DMS
Working with AWS-managed PostgreSQL databases as a DMS source
Amazon Aurora MySQL 兼容版性能基准指南
Amazon Aurora PostgreSQL 兼容版性能基准指南