Amazon Aurora 简介与架构详解

Amazon Aurora 是 AWS 托管的关系型云数据库，兼容 MySQL 与 PostgreSQL，本文详解其存储/计算分离架构、集群组成、高可用与读写分离等关键特性。

AuroraAuroraNewSQL2026/10/07

Amazon Aurora 简介与架构详解

重要前置说明：Amazon Aurora 为 AWS 云托管数据库，无法在本地私有化部署，本文为概念与架构详解。Aurora 只能在 AWS 云环境中创建与使用，不具备可在本机/私有集群独立安装的发行包或部署流程，故本文不涉及任何安装部署、命令行启动或容器化操作。

一、Aurora 定位

Amazon Aurora（以下简称 Aurora）是 AWS（Amazon Web Services，亚马逊云服务）提供的全托管关系型数据库引擎，属于 Amazon RDS（Relational Database Service）托管数据库服务家族的一员。其核心定位如下：

维度说明
数据库类型关系型数据库（Relational Database）
兼容性与 MySQL、PostgreSQL 高度兼容
服务形态完全托管的云数据库（Managed Cloud Database）
归属于Amazon RDS 托管服务
性能官方宣称在同类硬件上最多可提供约 6 倍于原生 MySQL/PostgreSQL 的吞吐量
管理方式通过 AWS 管理控制台、AWS CLI 或 Amazon RDS API 进行控制

Aurora 专为 AWS 云的分布式存储基础设施做了深度定制，其 MySQL 兼容引擎与 PostgreSQL 兼容引擎并非原样照搬开源代码，而是经过重新实现的专用存储引擎，以利用其高性能的分布式存储子系统。

💡 说明：Aurora 与开源的 MySQL/PostgreSQL 保持协议与客户端兼容，现有基于这两种数据库的代码、工具与应用程序大多无需改动即可迁移到 Aurora。

二、核心架构

Aurora 最核心的架构思想是存储层（Storage）与计算层（Compute）分离，这一设计与传统单体式数据库（数据与计算绑在同一台服务器上）有本质区别。

2.1 存储层（集群卷 Cluster Volume）

架构要素说明
存储形态单一块虚拟卷（Cluster Volume），底层为 SSD 固态存储
副本数量在同一 AWS 区域内的三个可用区（AZ）分布 6 份数据副本
数据内容用户数据、schema 对象、系统表、二进制日志（binary log）等
扩容方式随着数据量增长自动扩容，几乎无需人工干预
缩容方式删除表/索引后，分配的空间可被释放回收（视 Aurora 版本）
容量上限集群卷最大可达 256 TiB（视具体引擎版本而定）
计费方式仅按实际使用空间计费，而非按分配容量计费

Aurora 将数据同步复制到与集群卷关联的 6 个存储节点上，分布在 3 个可用区中。这一机制带来以下收益：

  • 高持久性：数据在不同可用区间自动复制，降低数据丢失风险。
  • 高可用性：发生故障转移时，其他可用区中的副本已就绪，可继续提供服务，无需重新拷贝数据。
  • 写入性能：写入采用「多数派」确认机制，分散 I/O，消除写入放大。
  • 备份友好：备份基于分布式存储完成，不阻塞在线读写，避免 I/O 冻结与延迟尖峰。

2.2 计算层（DB 实例）

计算层由多个 DB 实例（DB Instance）组成，它们共同连接并读写同一个共享的集群卷，也就是说数据独立于任一台 DB 实例。

实例角色别名职责
主实例（Primary / Writer）写入实例处理全部 DDL、DML、INSERT 等写操作
读副本（Aurora Replica / Reader）只读实例处理只读 SELECT 查询，异步复制主实例数据
数量限制—一个集群最多可创建 15 个读副本

💡 说明：因为所有 DB 实例共享同一个集群卷，所以新增读副本时不会复制一份新的表数据，读副本直接挂载到已有共享卷即可，这也是 Aurora 快速横向扩展读能力的原因。

2.3 存储与计算分离带来的好处

  • 计算与存储可独立扩缩容。
  • 新增/移除 DB 实例不影响底层数据。
  • 数据天然跨多可用区冗余，故障转移无需重新搭建数据副本。
  • 数据库集群化与复制自动化，极大简化运维。

三、集群组成与 Endpoint

Aurora 以 DB 集群（DB Cluster）为单位组织资源，一个集群由集群卷 + 主实例 + 若干读副本组成。客户端通过名为 Endpoint（端点） 的中间层进行连接，不必硬编码具体副本主机名，也不必自己实现连接负载均衡与故障重路由逻辑。

Endpoint 类型用途
Cluster Endpoint（集群端点 / 写入端点）恒指向当前主实例，用于读写操作、开发测试、DDL/DML/ETL
Reader Endpoint（读端点）对所有读副本自动做连接均衡，用于查询类只读流量
Instance Endpoint（实例端点）指向某台具体 DB 实例，用于诊断、调优
Custom Endpoint（自定义端点）指向集群内某一组指定 DB 实例，用于不同容量/配置的实例分组
Global Endpoint（全局数据库端点）用于 Aurora Global Database 跨区域场景，写入/读取总指向当前主区域

⚠️ 注意：在高可用场景下，建议读写连接使用 Cluster Endpoint、只读连接使用 Reader Endpoint。二者在主实例故障时会自动切换所指向的 DB 实例；而 Instance Endpoint 不会自动切换，需自行处理故障重连逻辑。

四、关键特性

4.1 自动故障转移与高可用

  • 数据层：集群卷跨 3 个可用区保留多副本，可承受单个可用区整体故障而不丢数据。
  • 实例层：主实例故障时，Aurora 自动将其提升为新的主实例——优先从已有读副本中挑选唯一读副本进行提升，若无读副本则在原可用区重建主实例。
  • 故障转移耗时：有读副本时服务通常在 60 秒内恢复，多数情况不足 30 秒；无读副本重建主实例通常约 10 分钟内恢复。
  • 提升优先级：可给读副本设置故障提升优先级（0 最高 ~ 15 最低），也可形成多个同优先级的提升梯队（Promotion Tier）。

💡 说明：Aurora MySQL 下，集群内存在多个读副本时，故障转移期间仅重启写实例与接管的读实例，其余读副本仍可通过读端点继续对外服务。

4.2 读写分离

  • 写流量全部走主实例（Cluster Endpoint）。
  • 只读查询通过 Reader Endpoint 分发到最多 15 个读副本，自动完成连接均衡。
  • 读副本之间采用异步复制，不拖累主实例性能。

4.3 Serverless（无缝扩缩容）

  • Aurora Serverless v2：按需自动调整数据库容量，以 ACU（Aurora Capacity Unit，Aurora 容量单位） 为最小扩缩容粒度，秒级伸缩，适用于业务负载起伏明显的场景。
  • 每 ACU 约包含一定计算内存与对应的计算资源，用户可设定最小/最大 ACU 范围，由服务自动在范围内伸缩，无需手动预置实例规格。

4.4 备份与恢复

备份/恢复能力说明
自动备份默认开启，自动创建数据库备份
保留周期自动备份保留期最长 35 天
时间点恢复（PITR）可在备份保留期内恢复到任意时间点
手动快照可随时创建手动快照，持久保存，不受保留期限制
Backtrack（回溯）Aurora MySQL 支持无需恢复即可将集群快进/回退到历史时间点（受回溯窗口限制）
跨区域副本支持 Aurora Global Database 从主区域异步复制到多个次要区域，用于全局低延迟读与灾备

4.5 安全与加密

  • 网络隔离：运行在 VPC（虚拟私有云）内，通过安全组（Security Group）与子网配置访问控制。
  • 加密：支持通过 AWS KMS 对数据库进行静态加密（存储、备份加密）。
  • 传输加密：支持 TLS/SSL 加密连接。

五、Aurora MySQL 与 Aurora PostgreSQL 差异

对比项Aurora MySQLAurora PostgreSQL
协议/兼容目标MySQL 兼容PostgreSQL 兼容
常见版本线MySQL 5.7 / 8.0 语义对应PostgreSQL 对应若干大版本
语法兼容兼容 MySQL 语法/驱动/工具兼容 PostgreSQL 语法/驱动/扩展
Backtrack 回溯支持不支持
特有扩展兼容 MySQL 生态的多项特性支持 pg_hint_plan、pgAudit 等 PostgreSQL 扩展
适用场景原有 MySQL 应用、电商、内容类原有 PostgreSQL 应用、复杂查询/OLAP、地理信息等
底层存储引擎共享同一套 Aurora 分布式存储与集群机制与 Aurora MySQL 相同的分布式存储与集群机制

⚠️ 注意：Aurora 的两种引擎都基于同一套 Aurora 分布式存储与高可用机制，差异主要体现在 SQL 方言、协议与功能集上；且 Aurora 并非 100% 与开源 MySQL/PostgreSQL 完全一致，个别存储引擎、插件、系统参数的可用范围存在差异，迁移前建议查阅 AWS 官方「引擎原生特性支持」文档确认。

六、与自建 MySQL/RDS MySQL/本地 MySQL 的对比

6.1 Aurora 的主要优势

优势说明
高可用内置化跨多可用区多副本、自动故障转移，降低运维复杂度
共享存储计算与存储分离，读副本秒级扩展，新增实例无需复制数据
读扩展最多 15 个只读副本，天然支持读写分离
存储自动扩缩集群卷自动增长至最大 256 TiB，无需预分配磁盘
性能官方口径最高约 6 倍于原生 MySQL/PostgreSQL 吞吐
全托管补丁、备份、故障检测与修复由 RDS 托管处理
Serverless负载波动时级弹性伸缩，降低成本

6.2 Aurora 的限制与不足

限制项说明
仅限 AWS 云只能在 AWS 区域与可用区中运行，无法本地或其他云部署
专有引擎Aurora 存储引擎为 AWS 专有实现，非开源，存在云厂商锁定
非完全等价与开源 MySQL/PostgreSQL 某些高级特性/参数不完全一致
计费模型按时计费（计算/存储/I/O），长期高 I/O 场景需关注成本（可选 I/O-Optimized 计费）
依赖 AWS 环境需 AWS 账号、VPC、区域/可用区等基础设施前提

6.3 与自建数据库对比（部署与运维视角）

维度自建 MySQL/PostgreSQL（本机/VPS）Amazon Aurora（云托管）
安装部署需自行安装、配置、编译/二进制包无需安装，控制台/CLI 创建即用
高可用需自建主从复制、VIP、故障切换脚本内置跨可用区多副本与自动故障转移
备份恢复需自行做 mysqldump/xtrabackup 等内置自动备份、快照、时间点恢复
扩容需人工扩磁盘、加副本存储自动扩容，读副本按需添加
运维需自行打补丁、监控、修复由 AWS 托管补丁与故障处理
可控性完全自主可控、可离线受云服务约束，无法离线

💡 说明：二者并非简单优劣关系。若追求深度可控、离线/私有化、规避云锁定、成本极致敏感，自建数据库仍具价值；若追求快速上线、高可用免运维、弹性扩缩容，Aurora 这类云托管数据库优势明显。

七、使用前置条件

在 AWS 上创建与使用 Aurora 前，需要具备以下前提：

前置项说明
AWS 账号注册并开通 AWS 账户
IAM 权限账户具备创建/管理 RDS 与相关网络资源的权限
区域与可用区选择部署的 AWS 区域，确认该区域支持 Aurora
VPC 与子网配置虚拟私有云，通常在多个可用区规划子网以支撑跨可用区高可用
安全组（Security Group）配置入站/出站规则，放行应用访问数据库的端口（MySQL 3306 / PostgreSQL 5432）
引擎选择在创建集群时选择 Aurora MySQL 或 Aurora PostgreSQL 引擎版本
存储配置按需选择 Aurora Standard 或 Aurora I/O-Optimized 存储计费配置
加密密钥（可选）如需静态加密，可配置 AWS KMS 密钥

⚠️ 注意：Aurora 的创建、扩缩容、备份恢复等全部依赖 AWS 云服务，创建后直接提供 Endpoint 供应用连接，不存在本地下载安装包或自行启动数据库进程的流程。

八、无法本地部署说明

Amazon Aurora 不具备任何形式的离线安装、私有化部署能力，也从不存在可供下载到本机运行的发行包，因此：

  • 无 Docker / 容器概念：针对 Aurora 不存在官方镜像或容器化部署方式；即便在本地模拟，也无法复现其依赖 AWS 分布式存储与托管控制面的架构。
  • 无单机/集群安装流程：Aurora 没有 yum/apt 安装、基于配置文件的启停、systemd 托管等传统数据库部署流程。
  • 无 CLI 自建命令：aws rds 等命令仅用于在 AWS 云中创建、描述与管理 Aurora 集群，而非在本地启动数据库。
  • 结论：若需在本地/私有环境运行 MySQL 或 PostgreSQL，应改用可自研部署的开源数据库；Aurora 的价值在于使用 AWS 云托管能力获得内置高可用、自动扩缩容与免运维体验。

九、参考链接（AWS 官方文档）