蓝绿部署升级 RDS

type
status
date
slug
summary
tags
category
icon
password
name
😀
客户现有一批 AWS RDS MySQL 5.7 实例，需要升级至 MySQL 8.0。
由于业务为 电商核心系统，对可用性和数据一致性要求极高，因此升级过程中必须满足以下目标：
  • 业务零停机
  • 数据实时同步
  • 支持快速回滚
  • 升级过程可控、可验证
综合评估后，采用 蓝绿部署（Blue-Green Deployment） 的方式进行升级。

升级整体思路

  1. 蓝集群开启 Binlog，确保数据变更可被复制
  1. 重启 Writer / Reader 实例，使参数生效
  1. 基于蓝集群数据克隆出绿集群
  1. 绿集群升级至 MySQL 8.0
  1. 通过 RDS 原生复制机制，实现蓝 → 绿数据同步
  1. 验证复制延迟与位点一致性
  1. 切换应用代理（Endpoint / Proxy）
  1. 如异常可立即回切蓝集群，实现快速回滚
⚠️ 说明：
中间涉及 参数组（Parameter Group）、选项组（Option Group）、实例规格调整 等内容，均为环境相关配置，非核心流程，本文不再展开。

一、创建复制账号

在 蓝 MySQL 上创建专用的复制账号：
建议：
  • 复制账号仅授予 REPLICATION SLAVE 权限
  • 密码妥善保存，后续配置复制时使用

二、配置主从连接（蓝 → 绿）

在 绿 MySQL 实例上，配置外部主库信息：
参数说明：
  • Binlog 文件名 / 偏移量 可通过蓝集群 SHOW MASTER STATUS 获取
  • 确保位点准确，避免数据缺失或重复

三、启动复制

四、验证复制状态

1. 快速检查复制线程状态

期望结果：
退出 pager：

2. 复制异常排查

查看 worker 级别复制状态

忽略重复 Key 等非致命错误（慎用）

⚠️ 注意：
  • 跳过错误前需明确错误原因
  • 仅建议在确认对业务无影响的情况下使用

五、确认复制位点一致性

在蓝集群上查看当前 binlog 位点：
当 蓝 / 绿集群 binlog 文件及偏移量保持一致，且复制延迟为 0 时，说明数据已完全同步。
notion image

六、停止复制并解除主从关系

在 绿 MySQL 上执行：
随后重置外部主库配置：
此时，绿集群已具备 完整、最新的数据副本，可独立对外提供服务。

七、切换业务流量

最后一步，在 AWS RDS 控制台 中：
  • 切换应用使用的 代理地址 / Endpoint
  • 或调整 RDS Proxy / 应用配置
  • 将流量从 蓝 MySQL 切换至 绿 MySQL
 
 
Loading...

© Dreamin 2021-2026