Aurora MySQL部署模式对比

文档属性

• 难度等级: 中级
• 预计时间: 20分钟阅读

任务目标

• 理解Aurora Provisioned和Serverless v2的核心差异
• 根据工作负载特征选择合适的部署模式
• 掌握两种模式的成本优化策略
• 了解性能权衡和最佳实践

使用环境

• AWS账号具备Aurora创建权限
• 已完成业务负载分析（峰值/平均值、波动模式）

前置条件

• 理解基础的Aurora架构概念
• 已收集现有数据库的性能指标（CPU、内存使用率）

---

1. 核心架构差异

Provisioned（预配置实例）

固定规格的数据库实例，需要预先选择实例类型（如db.r6g.2xlarge）。

特点：

• 实例持续运行，即使空闲也计费
• 容量固定，扩展需要修改实例类型（需重启）
• 支持Reserved Instance优惠（最高节省72%）

Serverless v2（弹性容量）

按需自动伸缩的计算容量，以ACU（Aurora Capacity Unit）为单位。

特点：

• 容量在0.5-128 ACU范围内自动调整
• 按秒计费，仅支付实际使用的容量
• 无Reserved Instance选项，纯按需定价

1 ACU约等于：2 GiB内存 + 对应的CPU和网络资源

graph LR
    A[Aurora MySQL] --> B[Provisioned模式]
    A --> C[Serverless v2模式]
    
    B --> D[固定实例<br/>db.r6g.xlarge<br/>32GB内存]
    C --> E[弹性ACU<br/>0.5-128 ACU<br/>1-256GB内存]
    
    D --> F[按小时计费<br/>支持RI折扣]
    E --> G[按秒计费<br/>无RI选项]

---

2. 性能对比

计算性能

维度	Provisioned	Serverless v2
峰值性能	固定（实例规格决定）	动态（当前ACU决定）
扩展速度	需要修改实例类型（分钟级）	自动扩展（秒级至分钟级）
性能稳定性	完全一致	受扩展行为影响
Buffer Pool	固定大小	随ACU动态调整

扩展延迟实测数据

根据AWS官方文档和社区测试：

Serverless v2扩展时间：

• 增加1-5 ACU：数秒内完成
• 大幅扩展（如5→30 ACU）：数十秒至1分钟
• 缩容速度：比v1快15倍（约1分钟内完成）

关键影响因素：

• 当前容量越高，扩展速度越快
• 建议设置合理的最小ACU以保证扩展响应速度

性能陷阱案例

场景：查询在Provisioned上运行0.2秒，在Serverless v2上需10秒

根本原因：

• Serverless v2缩容时会清空Buffer Pool
• 查询命中冷数据，需重新加载到内存
• 最小ACU设置过低导致内存不足

解决方案：

1. 提高最小ACU至足够容纳工作数据集
2. 使用Aurora I/O-Optimized配置
3. 预热Buffer Pool（在低峰期执行关键查询）

---

3. 伸缩性对比

Provisioned扩展机制

垂直扩展（修改实例类型）：

• 需要短暂停机（数分钟）
• 手动操作或通过CloudWatch告警触发
• 适合可预测的增长模式

水平扩展（添加读副本）：

• 支持最多15个读副本
• 读副本Auto Scaling：根据CPU/连接数自动增减
• 无停机，但需修改应用连接逻辑

Serverless v2扩展机制

自动垂直扩展：

• 监控CPU、内存、网络使用率
• 以0.5 ACU为单位增减
• 无需应用感知（连接保持）

水平扩展：

• 同样支持最多15个读副本
• 每个副本独立扩展（0.5-128 ACU）
• 理论上支持最高96,000并发连接（15副本×128 ACU）

扩展限制：

• 不会缩容至0 ACU（最小0.5 ACU）
• 最大128 ACU可能不足极端高负载
• Global Database需要最小8 ACU

混合部署模式

Aurora支持在同一集群内混用两种模式：

典型配置：

• 写实例：Provisioned（稳定性优先）
• 读副本：Serverless v2（弹性应对突发读流量）

优势：

• 核心写负载性能可预测
• 读流量波动由Serverless自动处理
• 成本优化与性能保障兼顾

%%{init: {'theme':'base', 'elk': {'algorithm': 'layered', 'direction': 'RIGHT'}}}%%
graph LR
    A[应用层] --> B[写流量]
    A --> C[读流量]
    
    B --> D[Provisioned Writer<br/>db.r6g.xlarge<br/>固定32GB]
    
    C --> E[Serverless v2 Reader 1<br/>2-32 ACU动态]
    C --> F[Serverless v2 Reader 2<br/>2-32 ACU动态]
    
    D --> G[Aurora存储层<br/>跨3 AZ复制]
    E --> G
    F --> G

---

4. 价格对比分析

定价模型

Provisioned（以US East-N.Virginia为例）：

• db.r6g.large（16GB）：$0.29/小时 = $210.4/月
• db.r6g.xlarge（32GB）：$0.58/小时 = $420.8/月
• db.r6g.2xlarge（64GB）：$1.16/小时 = $841.6/月

Serverless v2（US East-N.Virginia）：

• $0.12/ACU/小时
• 16 ACU（32GB）：$0.12×16 = $1.92/小时 = $1,392/月

存储和I/O（两种模式相同）：

• 存储：$0.10/GB/月
• I/O：$0.20/百万请求（Standard配置）

成本对比场景

场景A：稳定负载（24/7运行）

需求：64GB内存，全天候运行

Provisioned：

• db.r6g.2xlarge按需：$841.6/月
• 使用3年RI（全预付）：$293.7/月（节省65%）

Serverless v2：

• 固定32 ACU：$2,764.8/月
• 无RI选项

结论：稳定负载下Provisioned + RI成本更低

场景B：波动负载（峰谷差异大）

需求：

• 峰值：64GB（2小时/天）
• 中负载：32GB（10小时/天）
• 低负载：6.4GB（12小时/天）

Provisioned：

• 必须按峰值配置db.r6g.2xlarge：$841.6/月
• 加1个读副本（高可用）：$1,683.2/月

Serverless v2：

• 单集群弹性扩展：
  • (32 ACU × 2h × 1.0 + 16 ACU × 10h × 1.0 + 3.2 ACU × 12h × 1.0) × $0.12 × 30
  • = $1,566.72/月

结论：波动负载下Serverless v2节省约30%

场景C：开发测试环境

需求：工作时间使用（8小时/天，22天/月）

Provisioned：

• db.r6g.large：$210.4/月（即使停止实例，存储仍计费）
• 手动启停操作成本

Serverless v2：

• 最小0.5 ACU空闲，工作时4 ACU
• (4 ACU × 8h × 22 + 0.5 ACU × 16h × 22) × $0.12
• = $105.6/月

结论：开发环境Serverless v2成本更低且免运维

成本临界点分析

单实例负载率阈值：

• 负载率 > 60%：Provisioned + RI更经济
• 负载率 < 40%：Serverless v2可能更优
• 40-60%区间：需详细计算实际使用模式

多副本场景：

• Provisioned需要为每个副本付费（即使低负载）
• Serverless v2各副本独立扩展，总成本更可控

隐性成本：

• Provisioned：容量规划、手动扩展的运维时间
• Serverless v2：更高的单位价格（ACU是RI价格的2-3倍）

---

5. 适用场景决策

强烈推荐Provisioned的场景

1. 负载稳定可预测

   • 24/7运行，波动<20%
   • 示例：核心业务ERP、生产环境OLTP

2. 极致性能要求

   • 延迟敏感（毫秒级要求）
   • Buffer Pool需要完全预热
   • 示例：高频交易系统、实时风控

3. 预算可控性优先

   • 长期运行（>1年）
   • 可使用RI节省成本
   • 示例：SaaS平台数据库

4. 超大内存需求

   • 需要>256GB内存（超过Serverless 128 ACU上限）
   • 示例：大型数据仓库查询层

强烈推荐Serverless v2的场景

1. 高度波动负载

   • 峰谷差异>5倍
   • 不可预测的突发流量
   • 示例：电商促销、新闻网站

2. 间歇性使用

   • 工作时间段使用（如BI报表）
   • 开发测试环境
   • 示例：数据分析平台、Staging环境

3. 多租户SaaS

   • 租户活跃度差异大
   • 需要为每个租户独立扩展
   • 示例：B2B SaaS应用

4. 新项目初期

   • 无法准确预估负载
   • 需要快速验证概念
   • 示例：MVP产品、创业项目

混合部署场景

1. 写少读多应用

   • Writer：Provisioned（稳定写性能）
   • Reader：Serverless v2（弹性读扩展）
   • 示例：内容分发平台、日志查询系统

2. 跨区域复制

   • 主区域：Provisioned（低延迟）
   • 灾备区域：Serverless v2（最小0.5 ACU待命）
   • 示例：Global Database架构

决策流程图

%%{init: {'theme':'base', 'themeVariables': {'fontSize':'14px'}}}%%
graph TB
    A[评估数据库需求] --> B{负载是否稳定?}
    
    B -->|是 波动小于20%| C{长期运行?}
    B -->|否 波动大于50%| D[Serverless v2]
    
    C -->|大于1年| E[Provisioned + RI]
    C -->|小于1年| F{性能敏感?}
    
    F -->|是| E
    F -->|否| G[Provisioned按需或<br/>Serverless v2]
    
    D --> H{峰值需求}
    H -->|大于256GB| I[Provisioned<br/>Serverless上限不足]
    H -->|小于256GB| J[Serverless v2最佳]
    
    E --> K[推荐配置:<br/>3年RI全预付]
    J --> L[推荐配置:<br/>设置合理最小ACU]

---

6. 配置最佳实践

Provisioned最佳配置

实例选择：

• 优先Graviton2实例（r6g系列）：性价比高20%
• 避免过度配置：从小实例开始，监控后调整
• 高可用：至少1个Reader副本在不同AZ

成本优化：

• 生产环境：3年RI全预付（最高72%折扣）
• 测试环境：按需或1年RI部分预付
• 定期审查CloudWatch指标，右适化实例大小

监控指标：

• CPU使用率目标：50-70%（留扩展空间）
• 内存：Freeable Memory > 20%
• 连接数：< max_connections的80%

Serverless v2最佳配置

容量规划：

• 最小ACU设置原则：

  • 开发环境：0.5 ACU
  • 生产环境：能容纳工作数据集（建议≥2 ACU）
  • Global Database：≥8 ACU

• 最大ACU设置原则：

  • 等于或略高于历史峰值
  • 避免无上限（防止成本失控）

性能优化：

• 启用Aurora I/O-Optimized（高I/O负载）
• 设置最小ACU足够高以保证扩展速度
• 使用RDS Proxy管理连接池

成本控制：

• 设置CloudWatch告警监控ACU使用
• 定期分析ServerlessDatabaseCapacity指标
• 考虑是否应切换到Provisioned + RI

监控指标：

• ServerlessDatabaseCapacity：实时ACU值
• ACUUtilization：ACU利用率
• DatabaseConnections：连接数趋势

混合模式配置示例

场景：电商平台（读多写少）

集群配置：
├── Writer Instance
│   └── Provisioned: db.r6g.xlarge (32GB)
│       - 稳定写性能
│       - 3年RI全预付
│
├── Reader Instance 1
│   └── Serverless v2: 2-16 ACU (4-32GB)
│       - 优先级0（故障转移第一候选）
│       - 处理常规读流量
│
└── Reader Instance 2
    └── Serverless v2: 0.5-32 ACU (1-64GB)
        - 优先级2（独立扩展）
        - 应对促销期突发流量

预期成本（US East区域）：

• Writer：$147/月（3年RI）
• Reader 1：平均8 ACU = $691/月
• Reader 2：平均2 ACU = $172.8/月
• 总计：约$1,010/月

---

7. 迁移与切换

Provisioned → Serverless v2

步骤：

1. 在现有集群添加Serverless v2读副本
2. 测试应用读流量性能
3. 故障转移提升Serverless为Writer
4. 删除原Provisioned实例

零停机迁移：使用故障转移机制，中断<30秒

注意事项：

• 确保最小ACU≥Provisioned实例内存容量的10%
• 读副本优先级设置为0或1（保证故障转移性能）
• 生产环境建议先测试后迁移

Serverless v2 → Provisioned

步骤：

1. 监控ACU使用峰值
2. 选择匹配的Provisioned实例类型
3. 添加Provisioned读副本
4. 故障转移切换
5. 删除Serverless实例

适用场景：

• 发现负载稳定后切换到RI节省成本
• 性能要求提高需要固定Buffer Pool

参数调整差异

关键参数：

• max_connections：Serverless基于最大ACU计算
• shared_buffers：Serverless动态调整
• 自定义参数：某些参数Serverless会覆盖

兼容性验证：

• 使用相同的DB Parameter Group
• 部分参数在Serverless下只读

---

8. 常见问题

Q: Serverless v2能否完全替代Provisioned？
A: 不能。对于稳定负载和极致性能要求，Provisioned + RI仍然是最优选择。Serverless更适合波动负载。

Q: 混合部署时故障转移会影响性能吗？
A: 如果Serverless读副本优先级设为0或1，故障转移时容量会跟随Writer，性能无影响。优先级≥2的副本可能短暂性能下降。

Q: Serverless v2的扩展是否真的”毫秒级”？
A: 官方称”秒级”，实测小幅扩展（1-5 ACU）确实数秒完成，大幅扩展需数十秒至1分钟。不是真正的毫秒级。

Q: 为何Serverless v2的ACU价格是v1的两倍？
A: v2提供更细粒度扩展（0.5 ACU增量 vs v1的倍增）、更快扩展速度（15倍）和更多功能（Global Database、Multi-AZ等）。

Q: 如何防止Serverless v2成本失控？
A:

1. 设置合理的最大ACU上限
2. CloudWatch告警监控ACU使用
3. 定期审查ServerlessDatabaseCapacity趋势
4. 考虑使用AWS Budgets设置预算限制

Q: Buffer Pool清空导致性能下降怎么办？
A: 提高最小ACU至能容纳工作数据集，或在低峰期预热关键查询，或切换到Provisioned模式。

Q: 开发环境应该用哪种模式？
A: Serverless v2更合适。可设置最小0.5 ACU，工作时间自动扩展，成本远低于Provisioned且无需手动启停。

Q: 能否在Global Database中混用两种模式？
A: 可以。主区域用Provisioned保证低延迟，次区域用Serverless v2最小容量待命，故障时快速扩展。

---

扩展阅读

• Aurora Serverless v2官方文档
• Aurora性能和扩展最佳实践
• 评估Provisioned vs Serverless工作负载
• Aurora定价计算器