Aurora 集群蓝绿部署升级指南
概述
Amazon Aurora 蓝绿部署（Blue/Green Deployment）是一种零停机升级方案，通过创建同步的测试环境库版本升级、参数修改等操作，切换时停机时间通常小于 1 分钟。
适用场景：
- 主版本升级（如 MySQL 5.7 → 8.0）
- 次版本升级
- 数据库参数修改
- 架构变更测试
核心优势：
- ✅ 停机时间 < 1 分钟
- ✅ 应用零配置切换
- ✅ 自动回滚机制
- ✅ 完整的测试环境
支持的数据库引擎：
- Aurora MySQL
- Aurora PostgreSQL
流程总览
4个关键阶段：
- 创建蓝绿部署：AWS自动克隆环境（15-30分钟），Endpoint自动分离
- 测试验证：数据一致性 → 功能测试 → 性能测试 → 延迟监控
- 执行切换：AWS自动切换，停机 < 1分钟
- 切换后验证：验证功能、监控1-2小时、清理旧环境
图例说明： 🟦 用户操作 | 🟨 AWS自动执行
前提条件
📚 AWS 官方文档参考：
必须满足的条件
启用逻辑复制（Binary Logging）
Aurora MySQL 要求：
- 必须启用
binlog_format参数 - 需要使用自定义 DB 集群参数组
操作步骤：
# 步骤 1: 创建自定义集群参数组
aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora-mysql8.0 \
--db-cluster-parameter-group-name aurora-mysql80-binlog-enabled \
--description "Aurora MySQL 8.0 with binlog enabled for blue-green" \
--region ap-northeast-1
# 步骤 2: 修改参数启用 binlog
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name aurora-mysql80-binlog-enabled \
--parameters "ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=pending-reboot" \
--region ap-northeast-1
# 步骤 3: 将参数组应用到集群
aws rds modify-db-cluster \
--db-cluster-identifier your-cluster-name \
--db-cluster-parameter-group-name aurora-mysql80-binlog-enabled \
--apply-immediately \
--region ap-northeast-1
# 步骤 4: 重启集群实例使参数生效
aws rds reboot-db-instance \
--db-instance-identifier your-instance-1 \
--region ap-northeast-1
aws rds reboot-db-instance \
--db-instance-identifier your-instance-2 \
--region ap-northeast-1
# 步骤 5: 验证参数已生效
aws rds describe-db-clusters \
--db-cluster-identifier your-cluster-name \
--region ap-northeast-1 \
--query 'DBClusters[0].DBClusterMembers[*].DBClusterParameterGroupStatus'验证 binlog 已启用：
-- 连接到数据库
mysql -h your-cluster-endpoint -u admin -p
-- 检查 binlog 状态SHOW VARIABLES LIKE 'binlog_format';
-- 预期输出: ROWSHOW MASTER STATUS;
-- 应该显示 binlog 文件信息⚠️ 重要提示：
- 重启实例会导致短暂的连接中断（30-60秒）
- 建议在维护窗口执行
- 如果不启用 binlog，创建蓝绿部署时会报错：
SourceClusterNotSupportedFault: Blue/Green Deployments require
a DB cluster with logical replication enabled.实例类型兼容性
检查目标版本支持的实例类型：
# 查看支持的实例类型
aws rds describe-orderable-db-instance-options \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.10.1 \
--region ap-northeast-1 \
--query 'OrderableDBInstanceOptions[?contains(DBInstanceClass, `t3`) || contains(DBInstanceClass, `t4`)].DBInstanceClass' \
--output table常见问题：
db.t3.small可能不支持某些 Aurora 版本- 建议使用
db.t3.medium或更高规格 - 升级前验证目标版本支持当前实例类型
权限要求
IAM 权限：
{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Action": ["rds:CreateBlueGreenDeployment","rds:DeleteBlueGreenDeployment","rds:DescribeBlueGreenDeployments","rds:SwitchoverBlueGreenDeployment","rds:CreateDBClusterParameterGroup","rds:ModifyDBClusterParameterGroup","rds:ModifyDBCluster","rds:RebootDBInstance","rds:DescribeDBClusters","rds:DescribeDBInstances"],"Resource": "*"}]}网络和安全组
- DB 子网组必须包含至少 2 个不同可用区的子网
- 安全组配置允许必要的入站/出站流量
- Blue和Green环境需要能够相互通信（用于逻辑复制）
- Green环境会直接关联Blue环境的安全组（不会创建新的安全组）
备份保留期
- 备份保留期必须 ≥ 1 天
- 建议设置为 7 天以上
# 检查备份保留期
aws rds describe-db-clusters \
--db-cluster-identifier your-cluster-name \
--query 'DBClusters[0].BackupRetentionPeriod'# 如果需要修改
aws rds modify-db-cluster \
--db-cluster-identifier your-cluster-name \
--backup-retention-period 7 \
--apply-immediately前提条件检查清单
在创建蓝绿部署前，请确认：
- [ ] 集群状态为
available - [ ] 已启用 binlog（binlog_format=ROW）
- [ ] 已重启实例使参数生效
- [ ] 验证 binlog 状态正常
- [ ] 目标版本支持当前实例类型
- [ ] 备份保留期 ≥ 1 天
- [ ] 具有必要的 IAM 权限
- [ ] 网络配置正确
完整升级流程
环境定义
Blue环境（Blue Environment）
├─ 当前生产环境
├─ 处理实际业务流量
└─ 保持原有版本
Green环境（Green Environment）
├─ 克隆的测试环境
├─ 升级到新版本
├─ 通过逻辑复制保持同步
└─ 用于测试验证数据复制架构
Blue环境存储卷
↓
克隆（Copy-on-Write）
↓
Green环境存储卷（仅存储增量变化）阶段 1: 创建蓝绿部署
1.1 通过 AWS Console 创建
步骤：
- 登录 AWS Console → RDS → Databases
- 选择要升级的 Aurora 集群
- Actions → Create Blue/Green Deployment
- 配置参数：
- Blue/Green Deployment identifier:
mydb-upgrade-to-v16 - Target engine version:
Aurora MySQL 3.05.2 (compatible with MySQL 8.0.32) - DB parameter group: 选择或创建新参数组
- DB cluster parameter group: 选择或创建新参数组
1.2 或者通过 AWS CLI 创建
aws rds create-blue-green-deployment \
--blue-green-deployment-name mydb-upgrade-to-v16 \
--source-arn arn:aws:rds:ap-northeast-1:123456789012:cluster:mydb-cluster \
--target-engine-version 8.0.32 \
--target-db-parameter-group-name aurora-mysql80-params \
--region ap-northeast-11.3 创建过程说明
时间线：
T0: 开始创建
├─ 克隆Blue环境存储卷
├─ 创建Green环境集群
└─ 建立逻辑复制
T0+15-30分钟: 创建完成
├─ Green环境可用
├─ 开始同步数据
└─ 状态: Available1.4 完成后的 Endpoint
Blue环境（生产）Endpoint不变：
Cluster Writer Endpoint:
mydb-cluster.cluster-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
Cluster Reader Endpoint:
mydb-cluster.cluster-ro-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
Instance Endpoints:
mydb-instance-1.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com (Writer)
mydb-instance-2-ap-northeast-1a.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com (Reader)Green环境（测试）Endpoint：
Cluster Writer Endpoint:
mydb-cluster-green-abc123.cluster-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
Cluster Reader Endpoint:
mydb-cluster-green-abc123.cluster-ro-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
Instance Endpoints:
mydb-instance-1-green-abc123.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com (Writer)
mydb-instance-2-green-abc123-ap-northeast-1a.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com (Reader)数据流向：
生产流量 ──→ Blue环境 (v5.7)
↓
逻辑复制
↓
测试流量 ──→ Green环境 (v8.0)阶段 2: 测试验证
2.1 连接Green环境
# 使用Green环境的 Cluster Writer Endpoint
mysql -h mydb-cluster-green-abc123.cluster-czg8oooss0tt.ap-northeast-1.rds.com \
-u admin -p
# 验证版本
SELECT VERSION();2.2 数据一致性验证（首要步骤）
检查复制延迟：
# MySQL: 检查 binlog 复制延迟
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name AuroraBinlogReplicaLag \
--dimensions Name=DBClusterIdentifier,Value=mydb-cluster-green-abc123 \
--start-time 2025-11-04T00:00:00Z \
--end-time 2025-11-04T23:59:59Z \
--period 300 \
--statistics Average \
--region ap-northeast-1
# PostgreSQL: 检查逻辑复制延迟
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name OldestReplicationSlotLag \
--dimensions Name=DBClusterIdentifier,Value=mydb-cluster-green-abc123 \
--start-time 2025-11-04T00:00:00Z \
--end-time 2025-11-04T23:59:59Z \
--period 300 \
--statistics Average \
--region ap-northeast-1根据实际情况，验证数据同步结果：
-- 比对关键表的行数
SELECT COUNT(*) FROM important_table;
-- 比对最新记录的时间戳
SELECT MAX(updated_at) FROM important_table;
-- 验证关键业务数据
SELECT * FROM critical_data ORDER BY id DESC LIMIT 10;数据一致性检查清单：
- [ ] 复制延迟 < 1 秒
- [ ] 关键表行数一致
- [ ] 最新数据已同步
- [ ] 无复制错误或警告
2.3 功能测试
应用兼容性测试：
- [ ] 应用连接测试
- [ ] SQL 语句兼容性
- [ ] 存储过程/函数验证
- [ ] 触发器验证
- [ ] 字符集和排序规则
业务功能验证：
- [ ] 关键业务流程测试
- [ ] 读写操作验证
- [ ] 事务处理测试
2.4 性能测试
性能对比：
- [ ] 查询性能对比
- [ ] 写入性能对比
- [ ] 并发压力测试
- [ ] 响应时间对比
性能基准测试：
# 使用 sysbench 或其他工具进行压测
sysbench oltp_read_write \
--mysql-host=mydb-cluster-green-abc123.cluster-xxx.rds.amazonaws.com \
--mysql-user=admin \
--mysql-password=password \
--tables=10 \
--table-size=10000 \
run2.5 监控关键指标
必须监控的 CloudWatch 指标：
| 指标 | 说明 | 建议阈值 |
| AuroraBinlogReplicaLag | 复制延迟（MySQL） | < 1 秒 |
| OldestReplicationSlotLag | 复制延迟（PostgreSQL） | < 1 秒 |
| DatabaseConnections | 活动连接数 | 记录基线值 |
| ActiveTransactions | 活动事务数 | < 10 |
| CPUUtilization | CPU 使用率 | < 80% |
| FreeableMemory | 可用内存 | > 20% |
2.6 切换前检查清单
环境检查：
[ ] Green环境测试完成
[ ] 复制延迟 < 1 秒
[ ] 无长事务运行
[ ] 无长时间 DDL 操作
[ ] 应用具备连接重试机制
[ ] 集群状态为
available切换准备：
[ ] 选择业务低峰期
[ ] 通知相关团队
[ ] 准备回滚方案
[ ] 确认客户端 DNS TTL ≤ 5 秒
降低复制延迟：
# 持续监控复制延迟
watch -n 5 'aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name AuroraBinlogReplicaLag \
--dimensions Name=DBClusterIdentifier,Value=mydb-cluster-green-abc123 \
--start-time $(date -u -d "5 minutes ago" +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 60 \
--statistics Average \
--region ap-northeast-1 \
--query "Datapoints[0].Average"'临时措施（如延迟过高）：
-- 暂停非关键的批量操作
-- 减少写入压力
-- 等待复制追赶阶段 3: 执行切换（Switchover）
3.1 切换操作
通过 AWS Console：
- RDS → Blue/Green Deployments
- 选择部署 → Actions → Switch over
- 配置切换超时时间（默认 300 秒，范围 30-3600 秒）
- 确认切换
通过 AWS CLI：
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier bgd-abc123xyz \
--switchover-timeout 300 \
--region ap-northeast-13.2 切换过程详解
以下为 AWS 自动执行的 6 个步骤：
步骤 1: 运行保护检查（Guardrails）
验证蓝绿环境是否准备好切换：
├─ Green环境检查：
│ ├─ 复制健康检查
│ ├─ 复制延迟检查（必须在可接受范围内）
│ └─ 检查无活动写入
└─ Blue环境检查：
├─ 检查无外部复制配置
├─ 检查无长时间活动写入
├─ 检查无长时间 DDL 操作
└─ 检查无不支持的 PostgreSQL 变更
步骤 2: 停止写操作
设置数据库为只读模式（--read-only）:
├─ Blue环境：停止接受新的写入
└─ Green环境：停止接受新的写入
步骤 3: 断开所有连接
启用 OFFLINE_MODE 快速断开所有连接:
├─ Blue环境：断开所有数据库连接，拒绝新连接（返回 ER_SERVER_OFFLINE_MODE 错误）
└─ Green环境：断开所有数据库连接，拒绝新的连接请求
步骤 4: 等待复制追赶
└─ Green环境完全同步Blue环境的所有变更
步骤 5: 重命名集群、实例和 Endpoints
├─ 重命名Blue环境（添加 -old1 后缀）：
│ 集群：
│ mydb-cluster → mydb-cluster-old1
│ 实例：
│ mydb-instance-1 → mydb-instance-1-old1
│ mydb-instance-2 → mydb-instance-2-old1
│
└─ 重命名Green环境（接管Blue环境的名称）：
集群：
mydb-cluster-green-abc123 → mydb-cluster
实例：
mydb-instance-1-green-abc123 → mydb-instance-1
mydb-instance-2-green-abc123 → mydb-instance-2
步骤 6: 恢复连接和写入
├─ 关闭 OFFLINE_MODE，允许两个环境的数据库连接
├─ 新生产环境（原Green环境）：允许读写操作
└─ 旧环境（原Blue环境）：只允许只读操作（即使启用写入，仍保持只读直到删除蓝绿部署）3.3 Endpoint 变化 - 切换后
新生产环境（原Green，v8.0）：
Cluster Writer Endpoint:
mydb-cluster.cluster-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
（DNS 自动指向新环境）
Cluster Reader Endpoint:
mydb-cluster.cluster-ro-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
（DNS 自动指向新环境）
Instance Endpoints:
mydb-instance-1.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com (Writer)
mydb-instance-2-ap-northeast-1a.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com (Reader)旧环境（原Blue，v5.7）：
Cluster Writer Endpoint:
mydb-cluster-old1.cluster-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
（只读模式）
Cluster Reader Endpoint:
mydb-cluster-old1.cluster-ro-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
（只读模式）
Instance Endpoints:
mydb-instance-1-old1.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com
mydb-instance-2-old1-ap-northeast-1a.czg8oooss0tt.ap-northeast-1.rds.amazonaws.com应用连接变化：
应用配置（无需修改）:
DB_HOST = "mydb-cluster.cluster-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com"
切换前: 连接到Blue环境 (v5.7)
↓
DNS 自动切换（< 1 分钟）
↓
切换后: 连接到Green环境 (v8.0) ✅⚠️ 注意：
Aurora DNS的默认TTL是 5秒, 如果客户端或网络配置增加了DNS缓存TTL，会导致应用在切换后继续连接到Blue环境出现写入失败的情况。
"Make sure that your network and client configurations don't increase the DNS cache Time-To-Live (TTL) beyond five seconds, which is the default for Aurora DNS zones. Otherwise, applications will continue to send write traffic to the blue environment after switchover."
3.4 切换时间线
T0: 开始切换
├─ 保护检查通过
└─ 停止写操作
T0+10s: 断开连接
├─ 所有连接被断开
└─ 等待复制追赶
T0+20s: 重命名操作
├─ 集群重命名
├─ 实例重命名
└─ Endpoint 重命名
T0+30s: DNS 传播
└─ DNS 更新生效
T0+60s: 切换完成
├─ 新环境接受连接
├─ 应用自动重连
└─ 业务恢复正常阶段 4: 切换后验证
4.1 立即验证
连接验证：
# 验证连接到新环境
mysql -h mydb-cluster.cluster-czg8oooss0tt.ap-northeast-1.rds.amazonaws.com \
-u admin -p -e "SELECT VERSION();"# 预期输出: 8.0.32角色验证：
# 检查集群成员角色
aws rds describe-db-clusters \
--db-cluster-identifier mydb-cluster \
--region ap-northeast-1 \
--query 'DBClusters[0].DBClusterMembers[*].{Instance:DBInstanceIdentifier,IsWriter:IsClusterWriter}'应用验证：
- [ ] 应用日志无异常
- [ ] 业务功能正常
- [ ] 性能指标正常
4.2 监控关键指标
建议切换后 1 小时内持续监控：
# CPU 使用率
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name CPUUtilization \
--dimensions Name=DBClusterIdentifier,Value=mydb-cluster \
--start-time $(date -u -d "1 hour ago" +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 300 \
--statistics Average,Maximum \
--region ap-northeast-1
# 数据库连接数
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name DatabaseConnections \
--dimensions Name=DBClusterIdentifier,Value=mydb-cluster \
--start-time $(date -u -d "1 hour ago" +%Y-%m-%dT%H:%M:%S) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
--period 300 \
--statistics Average,Maximum \
--region ap-northeast-14.3 清理旧环境
等待稳定后删除：
# 建议等待 24-48 小时确认无问题后删除
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-abc123xyz \
--delete-target \
--region ap-northeast-1回滚方案
切换完成后，如果新环境（3.10.1）出现问题，需要快速回滚到旧版本（3.04.0）。
前提条件：
- 旧环境（old1）必须保留（使用
--no-delete-target删除蓝绿部署） - 旧环境已解除只读保护（删除蓝绿部署后自动解除）
- 旧环境状态为
available
应用切换旧环境（最快 2-6 分钟）⚡
操作步骤：
验证旧环境状态
# 检查旧环境是否可用
aws rds describe-db-clusters \
--db-cluster-identifier aurora-bluegreen-test-old1 \
--region ap-northeast-1 \
--query 'DBClusters[0].{Status:Status,Version:EngineVersion,Endpoint:Endpoint,ReaderEndpoint:ReaderEndpoint}'预期输出：
{"Status": "available","Version": "8.0.mysql_aurora.3.04.0","Endpoint": "aurora-bluegreen-test-old1.cluster-xxx.ap-northeast-1.rds.amazonaws.com","ReaderEndpoint": "aurora-bluegreen-test-old1.cluster-ro-xxx.ap-northeast-1.rds.amazonaws.com"}修改应用配置
当前配置（连接到新环境 3.10.1）：
# application.properties 或环境变量
DB_WRITER_ENDPOINT=aurora-bluegreen-test.cluster-xxx.ap-northeast-1.rds.amazonaws.com
DB_READER_ENDPOINT=aurora-bluegreen-test.cluster-ro-xxx.ap-northeast-1.rds.amazonaws.com修改为旧环境（回滚到 3.04.0）：
# 修改配置文件
DB_WRITER_ENDPOINT=aurora-bluegreen-test-old1.cluster-xxx.ap-northeast-1.rds.amazonaws.com
DB_READER_ENDPOINT=aurora-bluegreen-test-old1.cluster-ro-xxx.ap-northeast-1.rds.amazonaws.com重启应用或重新加载配置
# 方式 1: 重启应用（推荐）
systemctl restart your-application
# 方式 2: 热重载配置（如果应用支持）kill -HUP <application-pid>
# 方式 3: 滚动重启（Kubernetes）
kubectl rollout restart deployment/your-app验证回滚成功
# 连接到旧环境验证版本
mysql -h aurora-bluegreen-test-old1.cluster-xxx.ap-northeast-1.rds.amazonaws.com \
-u admin -p -e "SELECT VERSION();"# 预期输出: 8.0.mysql_aurora.3.04.0检查应用日志：
# 确认应用连接到旧环境tail -f /var/log/application.log | grep "Connected to database"时间线
T0: 修改配置文件（< 1 分钟）
↓
T0+1min: 重启应用
↓
T0+2-6min: 应用完全启动并连接到旧环境 ✅
↓
业务恢复正常注意事项：
- 切换后的新数据会丢失（新环境的写入不会同步到旧环境）
- 如需保留新数据，搭建绿环境(新主)到蓝环境(旧主)的复制
- 需要手动修改配置
- 应用需要重启
异常情况处理
异常 1: Writer 和 Reader 角色互换
现象描述
切换后发现：
预期:
mydb-instance-1.xxx (Writer) ✅
mydb-instance-2-ap-northeast-1a.xxx (Reader) ✅
实际:
mydb-instance-1.xxx (Reader) ❌
mydb-instance-2-ap-northeast-1a.xxx (Writer) ❌识别方法：
# 检查当前角色
aws rds describe-db-clusters \
--db-cluster-identifier mydb-cluster \
--region ap-northeast-1 \
--query 'DBClusters[0].DBClusterMembers[*].{Instance:DBInstanceIdentifier,IsWriter:IsClusterWriter,AZ:AvailabilityZone}'原因分析
可能原因 1: 切换过程中发生故障转移
切换流程:
步骤 4: 等待复制追赶
↓
Writer 实例出现问题（内存/CPU/网络）
↓
自动故障转移到 Reader
↓
步骤 5-7: 以新角色完成切换可能原因 2: Green环境测试期间发生故障转移
测试阶段:
Green环境 Writer 出现问题
↓
自动故障转移到 Reader
↓
切换时保持了这个状态可能原因 3: 手动操作导致
- 测试期间手动执行了 failover
- 切换前未恢复原始角色
诊断步骤
- 查看事件历史：
# 查看集群事件
aws rds describe-events \
--source-identifier mydb-cluster \
--source-type db-cluster \
--start-time 2025-11-04T00:00:00Z \
--region ap-northeast-1 \
--query 'Events[*].{Time:Date,Message:Message}' \
--output table关键事件标识：
Failover completed- 发生了故障转移Blue/Green Deployment switchover started- 切换开始时间Blue/Green Deployment switchover completed- 切换完成时间
- 检查 CloudWatch 日志：
# 查看切换期间的性能指标异常
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS \
--metric-name CPUUtilization \
--dimensions Name=DBInstanceIdentifier,Value=mydb-instance-1 \
--start-time 2025-11-04T14:00:00Z \
--end-time 2025-11-04T15:00:00Z \
--period 60 \
--statistics Maximum \
--region ap-northeast-1修复方案
方案 1: 使用 Cluster Endpoint（避免问题）
推荐的解决方案：
# 应用配置改为使用 Cluster Endpoint# 不再依赖 Instance Endpoint# 写操作连接
DB_WRITER_HOST = "mydb-cluster.cluster-xxx.region.rds.amazonaws.com"# 读操作连接
DB_READER_HOST = "mydb-cluster.cluster-ro-xxx.region.rds.amazonaws.com"# 优势：# ✅ 自动跟踪当前 Writer# ✅ 故障转移后无需修改# ✅ Reader 自动负载均衡但需要注意：
- ⚠️ Endpoint 名称与角色不匹配，容易混淆
- ⚠️ 未来维护时可能产生误解
- ⚠️ 监控和告警配置可能需要调整
方案 2: 手动故障转移恢复角色
步骤：
# 1. 确认目标实例（要提升为 Writer 的实例）
TARGET_INSTANCE="mydb-instance-1"# 2. 执行故障转移
aws rds failover-db-cluster \
--db-cluster-identifier mydb-cluster \
--target-db-instance-identifier $TARGET_INSTANCE \
--region ap-northeast-1
# 3. 监控故障转移状态
aws rds describe-db-clusters \
--db-cluster-identifier mydb-cluster \
--region ap-northeast-1 \
--query 'DBClusters[0].Status'# 4. 验证角色恢复
aws rds describe-db-clusters \
--db-cluster-identifier mydb-cluster \
--region ap-northeast-1 \
--query 'DBClusters[0].DBClusterMembers[*].{Instance:DBInstanceIdentifier,IsWriter:IsClusterWriter}'影响评估：
- ⏱️ 停机时间：30-60 秒
- 🔌 连接中断：所有现有连接会被断开
- 📊 性能影响：短暂的性能抖动
- 🔄 应用影响：需要连接重试机制
执行时机建议：
- 业务低峰期
- 提前通知相关团队
- 准备回滚方案
异常 2: 切换超时失败
现象描述
错误信息:
"Switchover timed out after 300 seconds. Rolling back changes."原因分析
- 复制延迟过大
- 长事务未完成
- 长时间 DDL 操作
- 网络问题
解决方案
- 增加超时时间：
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier bgd-abc123xyz \
--switchover-timeout 1800 \
--region ap-northeast-1- 优化复制延迟：
-- 暂停批量操作-- 等待复制追赶-- 确认延迟 < 1 秒后重试异常 3: 保护检查失败
常见失败原因
- 外部复制检测：
错误: "Blue environment has external replication configured"
解决:
# 临时删除外部复制
# 完成切换后重新配置- 长事务检测：
错误: "Long-running transactions detected"
解决:
# 查找长事务
SELECT * FROM information_schema.processlist
WHERE time > 300 AND command != 'Sleep';
# 终止长事务
KILL <process_id>;- DDL 操作检测：
错误: "Long-running DDL statements detected"
解决:
# 等待 DDL 完成
# 或取消 DDL 操作修改数据库集群安全组
通过Web控制台修改集群安全组
1.点击Aurora集群（例如 aurora-sg-test）的数据库实例，在『Connectivity & security』页面查看当前 VPC 和 VPC安全组 设置，例如：
2.在数据库所在VPC（例如 vpc-c08b4ca6）创建一个新的安全组，如: aurora-no-access-test
3.修改 aurora-sg-test 数据库集群配置，在『Connectivity』 部分找到新建的aurora-no-access-test 安全组
4.点击确认，并选择『Apply immediately』立即应用安全组的变更：
5.点击集群中的数据库实例确认安全组修改已生效，此时该数据库将无法被外部客户端访问。
通过AWS CLI 修改集群安全组(推荐)
1. 查看当前数据库集群的vpc(通过子网组)，将 "aurora-sg-test-instance-1" 替换为集群下的数据库实例名称。
aws rds describe-db-instances \
--db-instance-identifier aurora-sg-test-instance-1 \
--region ap-northeast-1 \
--query 'DBInstances[0].DBSubnetGroup.VpcId' \
--output text
# 输出示例：
vpc-c08b4ca62.创建新的"拒绝所有"安全组
aws ec2 create-security-group \
--group-name aurora-no-access \
--description "Block all access to old environment" \
--vpc-id vpc-c08b4ca6 \
--region ap-northeast-1
# 输出示例：
{
"GroupId": "sg-01eba9ba5a88d00d5"
}3.修改集群安全组
aws rds modify-db-cluster \
--db-cluster-identifier aurora-sg-test \
--vpc-security-group-ids sg-01eba9ba5a88d00d5 \
--apply-immediately \
--region ap-northeast-14.验证修改结果：
aws rds describe-db-clusters \
--db-cluster-identifier aurora-sg-test \
--region ap-northeast-1 \
--query 'DBClusters[0].{Status:Status,SecurityGroups:VpcSecurityGroups}'
# 输出示例：
{
"Status": "available",
"SecurityGroups": [
{
"VpcSecurityGroupId": "sg-01eba9ba5a88d00d5",
"Status": "active"
}
]
}最佳实践总结
切换前
- 充分测试Green环境
- 确保复制延迟 < 1 秒
- 创建最终快照
- 选择业务低峰期
- 通知相关团队
- 准备回滚方案
切换中
- 监控切换进度
- 准备应急响应
- 记录切换时间点
切换后
- 立即验证功能
- 持续监控 1-2 小时
- 检查应用日志
- 验证性能指标
- 24-48 小时后清理旧环境
应用配置建议
强烈建议使用 Cluster Endpoint：
- Writer: mydb-cluster.cluster-xxx.region.rds.amazonaws.com
- Reader: mydb-cluster.cluster-ro-xxx.region.rds.amazonaws.com
❌ 避免: mydb-instance-1.xxx.region.rds.amazonaws.com连接重试机制：
import time
import mysql.connector
from mysql.connector import Error
def connect_with_retry(host, max_retries=3, retry_delay=5):
for attempt in range(max_retries):
try:
connection = mysql.connector.connect(
host=host,
user='admin',
password='password',
database='mydb'
)
return connection
except Error as e:
if attempt < max_retries - 1:
time.sleep(retry_delay)
else:
raise参考资料
AWS 官方文档：
AWS CLI 参考：
