RDS 与数据库实战

📖 RDS 基础知识

Amazon Relational Database Service (RDS) 是 AWS 的托管数据库服务，让您可以更轻松地部署和扩展数据库。

📒 官方文档 ∙ 用户指南 ∙ FAQ ∙ 定价 ∙ 实例对比

🖼️ RDS 图解补充

看图重点：RDS 可达性问题常见根因在子网路由与安全边界。

看图重点：涉及 IAM 数据库认证时要按策略评估链路排查。

看图重点：Multi-AZ 的本质是跨 AZ 高可用，不是读扩展。

看图重点：跨区复制与备份策略会直接影响数据库网络成本。

看图重点：数据库费用应拆到环境和业务线，避免成本黑盒。

支持的数据库引擎

引擎	版本	适用场景
MySQL	5.7, 8.0	Web 应用、CMS
PostgreSQL	12-16	复杂查询、GIS、扩展
MariaDB	10.x	MySQL 社区分支替代方案
Oracle	12c-19c	企业应用
SQL Server	2016-2022	.NET 应用
Aurora	MySQL/PostgreSQL	高性能云原生

看图重点：先区分实例层与存储层，再理解备份、监控和高可用组件如何协同。

其他托管数据库选择

如果需要 MongoDB、Cassandra 等非关系型数据库的托管服务，可以考虑：

• Amazon DocumentDB - MongoDB 兼容
• Amazon Keyspaces - Cassandra 兼容
• 第三方服务：Compose、InstaClustr

Aurora 深入解析

Aurora 是什么？

Aurora 是 AWS 专有的云原生数据库，提供分布式、容错的存储系统，具有自愈存储和自动扩展功能。

Aurora 存储架构
├── 分布式存储层
│   ├── 自动维护 6 个数据副本
│   └── 跨 3 个可用区分布
├── Log-structured 存储（非 B-tree）
│   └── 提高写入性能
├── 独立的缓冲池进程
│   └── 重启实例不会清空缓冲池
└── 共享存储读副本
    └── 极低复制延迟，零数据丢失故障转移

Aurora vs 标准 RDS

Aurora MySQL:
├── 性能: 比标准 MySQL 快 3-5 倍（高并发场景）
├── 存储: 自动扩展到 128 TB（10GB 增量）
├── 可用性: 跨 3 个 AZ 自动 6 副本复制
├── 只读副本: 最多 15 个，共享存储层
├── 故障转移: 更快，因为使用共享存储
└── 复制延迟: 毫秒级（共享存储，无需传输 binlog）

标准 RDS MySQL:
├── 性能: 标准数据库性能
├── 存储: 最大 64 TB（需预配置）
├── 可用性: 需配置 Multi-AZ
├── 只读副本: 最多 5 个，独立存储
├── 故障转移: 约 60-120 秒
└── 复制延迟: 依赖 binlog 传输

看图重点：Multi-AZ 是高可用主备切换，不是读扩展；读扩展需要 Read Replica。

Aurora 高并发优化

# Aurora 设计用于高并发场景
# 测试显示可以支持高达 5,000 个并发连接

# 最佳实践：
# 1. 使用大型连接池
# 2. 尽可能多地并发执行查询
# 3. Aurora 需要大实例才能发挥最佳性能

# Aurora 对于多 CPU 扩展效果好
# 可能需要选择大实例类型以获得最佳性能

Aurora 迁移路径

# 迁移到 Aurora 的方法（从易到难）：

# 1. 从 MySQL 5.6/5.7 快照恢复（最简单）
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier my-aurora-cluster \
  --snapshot-identifier my-mysql-snapshot \
  --engine aurora-mysql

# 2. 从 MySQL dump 导入
mysqldump -h source-mysql ... | mysql -h aurora-endpoint ...

# 3. 设置 Aurora 作为 MySQL 副本（低停机迁移）
# 适用于需要最小化停机时间的场景

# 4. AWS Database Migration Service (DMS)
# 付费服务，适用于复杂迁移

引擎选择指南

MySQL vs MariaDB vs Aurora

# 如果是新项目，使用 MySQL 风格数据库，应该考虑：

# 1. Aurora MySQL
#    - 高可用性和自动扩展
#    - 高并发场景最佳
#    - 某些工作负载可能没有 5 倍提升

# 2. MariaDB
#    - MySQL 的现代社区分支
#    - 某些方面已超越 MySQL
#    - 完全兼容 MySQL

# 3. MySQL
#    - 经典选择
#    - 生态系统成熟
#    - 但 MariaDB 可能更好

选择建议

场景	推荐	原因
高并发生产环境	Aurora	自动扩展、高可用
成本敏感的开发环境	RDS MySQL/MariaDB	价格更低
企业遗留应用	RDS Oracle/SQL Server	许可证兼容
地理空间应用	RDS PostgreSQL	PostGIS 扩展
最新 PostgreSQL 特性	RDS PostgreSQL	Aurora 版本可能滞后

Multi-AZ vs Read Replica

Multi-AZ 部署

用于高可用，同步复制到备用实例：

        写入/读取
           │
     ┌─────┴─────┐
     │  主实例   │  AZ-a
     │ (Primary) │
     └─────┬─────┘
           │ 同步复制 (DRBD)
     ┌─────┴─────┐
     │  备用实例  │  AZ-b
     │ (Standby) │
     └───────────┘

• 故障转移: 自动切换，约 60-120 秒
• 用途: 灾难恢复
• 读取: 备用实例不可读
• 备份: MySQL Multi-AZ 的自动备份从备用实例运行，减少主实例延迟

Read Replica

用于读取扩展，异步复制到只读副本：

        写入
          │
    ┌─────┴─────┐
    │   主实例   │
    └─────┬─────┘
          │ 异步复制 (binlog)
    ┌─────┼─────┐
    │     │     │
  ┌─┴─┐ ┌─┴─┐ ┌─┴─┐
  │ R1│ │ R2│ │ R3│  只读副本
  └───┘ └───┘ └───┘
    │     │     │
  读取  读取  读取

看图重点：Read Replica 是为了分担读流量，不承担主备故障切换职责。

看图重点：Standby 主要服务高可用，Read Replica 主要服务读扩展，这两个职责不要混用。

• 扩展: 最多 5 个副本 (Aurora 15 个)
• 跨区域: 副本可以跨 5 个区域
• 延迟: 毫秒级复制延迟

对比总结

特性	Multi-AZ	Read Replica
目的	高可用	读取扩展
复制	同步	异步
可读	否	是
跨区域	否	可以
Aurora 需要	通常不需要	推荐使用

💡 Aurora 提示: Aurora 只读副本相当于 Multi-AZ 备份，可配置为零数据丢失故障转移目标。因此使用 Aurora 时很少需要配置 Multi-AZ。

💡 RDS 最佳实践

1. 创建自定义参数组

# ❗ 默认参数组不允许动态配置更改！
# 必须创建自定义参数组

aws rds create-db-parameter-group \
  --db-parameter-group-name my-custom-params \
  --db-parameter-group-family mysql8.0 \
  --description "Custom params for production"

# 修改参数
aws rds modify-db-parameter-group \
  --db-parameter-group-name my-custom-params \
  --parameters "ParameterName=max_connections,ParameterValue=500,ApplyMethod=pending-reboot"

2. 时区配置

# RDS 实例默认时区是 UTC
# 如果需要，可以更改为其他时区

# 方法 1: 通过参数组设置
# time_zone = 'Australia/Sydney'

# 方法 2: 创建时指定
aws rds create-db-instance \
  --timezone "Australia/Sydney" \
  ...

3. 成本优化 - 停止未使用的实例

# 使用 Instance Scheduler 自动停止/启动 RDS
# https://aws.amazon.com/solutions/implementations/instance-scheduler/

# 例如：开发环境只在工作时间运行
# 可节省约 60% 的成本

4. MySQL Binary Logs

# MySQL RDS 允许访问 binary logs
# 用于：复制、数据恢复、审计

# 启用 binlog
# 通过参数组设置 binlog_format = ROW

# 注意：Multi-AZ MySQL 使用 DRBD 进行透明复制
# 备份从备用实例运行，减少主实例延迟

5. Performance Schema

# ⚠️ Performance Schema 在 RDS 中默认禁用！
# (尽管 MySQL 5.6.6+ 默认启用)

# 启用需要：
# 1. 在参数组中设置 performance_schema = 1
# 2. 重启 RDS 实例

数据库大小限制

数据库引擎	最大存储
Aurora	128 TB (10GB 自动增量)
MySQL/MariaDB/PostgreSQL	64 TB
Oracle	64 TB
SQL Server	16 TB (非 Express)

SQL Server 特殊限制:

• 最小存储：Web/Express 20GB，Standard/Enterprise 200GB
• 每个实例最多 30 个数据库
• 存储无法扩展，需要恢复到新实例

性能优化

实例类型选择

db.t3.micro    - 开发/测试 (2 vCPU, 1GB)
db.t3.medium   - 小型生产 (2 vCPU, 4GB)
db.r5.large    - 中型生产 (2 vCPU, 16GB)
db.r5.2xlarge  - 大型生产 (8 vCPU, 64GB)
db.r6g.*       - Graviton2，更好性价比

存储类型

类型	IOPS	适用场景
gp2	3,000 baseline	通用负载
gp3	3,000-16,000（可配置）	灵活配置
io1/io2	64,000	高性能 OLTP

⏱ 注意: RDS 实例运行在 EBS 卷上，因此受 EBS 性能限制。如果需要更好性能，必须配置 Provisioned IOPS SSD。

参数优化

-- 连接池设置
max_connections = 实例内存(GB) * 50

-- 缓冲池大小 (MySQL)
innodb_buffer_pool_size = 实例内存 * 0.75

-- 查询缓存 (谨慎使用)
query_cache_size = 0  -- MySQL 8.0 已移除

备份策略

自动备份

# 启用自动备份
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --backup-retention-period 7 \
  --preferred-backup-window "03:00-04:00"

# ⚠️ 注意：导入数据时如果备份正在运行
# 导入时间会大大延长！

手动快照

# 创建快照
aws rds create-db-snapshot \
  --db-instance-identifier mydb \
  --db-snapshot-identifier mydb-snapshot-20240101

备份建议

环境	保留期	备份窗口
生产	14-35 天	低峰期（避免维护窗口）
开发	7 天	任意
测试	1 天	任意

安全配置

加密

# 启用存储加密 (创建时)
aws rds create-db-instance \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:...

# 传输加密
--require-ssl

网络隔离

VPC
├── 私有子网 (数据库)
│   └── RDS 实例
├── 安全组
│   └── 只允许应用服务器访问
└── 不要分配公有 IP

⚠️ RDS 常见陷阱

1. 功能限制

# 🔸 RDS 不是完整的数据库服务器！
# 某些功能可能不可用

# PostgreSQL：检查支持的扩展
# https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html

# MySQL：没有 SUPER 权限
# 需要使用 AWS 提供的存储过程

# 如果需要的功能不支持，只能自建数据库

2. DNS 故障转移问题

# 🔸 RDS 故障转移基于 DNS 变更！
# 确保客户端正确处理 DNS 变化

# Java 特别注意：JVM DNS TTL 默认配置可能导致问题
# 参考：https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html

# 建议：设置较短的 DNS TTL
networkaddress.cache.ttl=60

3. MySQL 特定限制

# 🔸 没有 SUPER 权限
# 使用 AWS 提供的存储过程来启动/停止复制

# 🔸 复制到非 RDS 实例
# AZ 故障转移时复制会中断！

# 🔸 无法手动 CHANGE MASTER
# 主库故障转移后，所有副本需要重建

# 🔸 MyISAM 表不支持时间点恢复
# 快照前必须锁定并刷新表

4. PostgreSQL 特定限制

# 🔸 没有 superuser 权限
# 提供 rds_superuser 角色，但有限制

# 🔸 某些功能滞后于开源版本
# Aurora PostgreSQL 滞后更明显

# 🔸 难以排查性能问题
# 没有主机访问权限

# 🔸 某些维护工具需要命令行
# 可以使用外部 EC2 服务器

5. SQL Server 特定限制

# 🔸 存储无法扩展！
# 需要恢复到更大存储的新实例

# 🔸 每个实例最多 30 个数据库

# 🔸 只有 db_owner 权限

# ✅ 好消息：支持原生备份/恢复到 S3
# 可用于灾难恢复

6. Aurora 限制

# 🔸 Aurora 1.x 基于 MySQL 5.6.x
# 缺少大多数 5.7 特性

# 🔸 Aurora 2.x 基于 MySQL 5.7.x

# 🔸 不支持 GTID 事务

# 🔸 Aurora PostgreSQL 版本滞后
# 如需最新 PostgreSQL 特性，用标准 RDS

7. 存储空间不足

# 启用存储自动扩展
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --max-allocated-storage 1000

8. 连接数耗尽

# 使用连接池或 RDS Proxy

# RDS Proxy 特别适合：
# - Lambda 等无服务器应用
# - 避免连接数爆炸
# - 提高故障转移速度

ElastiCache 补充

如果需要缓存层，考虑 ElastiCache：

引擎	特点	适用场景
Redis	支持复杂数据结构	Session、排行榜、消息队列
Memcached	简单 key/value，更快	纯缓存，可水平扩展

# 选择建议：
# - 需要持久化、发布订阅、复杂数据类型 → Redis
# - 纯粹的缓存，需要最大性能 → Memcached

📚 本章小结

• RDS 简化数据库运维，但有功能限制
• Aurora 是高并发场景首选，共享存储架构提供更好的可用性
• 必须创建自定义参数组，默认参数组不允许动态更改
• Multi-AZ 用于高可用（同步），Read Replica 用于读扩展（异步）
• Aurora 只读副本相当于 Multi-AZ，通常不需要额外配置
• 注意 DNS 故障转移问题，特别是 Java 应用
• 不同引擎有不同限制，选择前需要验证功能支持
• 备份和安全配置不可忽视
• 考虑 RDS Proxy 解决连接池问题