平台业务开展前期，我司团队在Windows系统的ECS服务器上部署了MySQL服务，因版本升级不及时、同一服务器会同时用于人工操作其他业务导致存在安全隐患，需要切换为由云平台统一管理的RDS，同时为保障业务的高可用，应客户要求推进异云容灾工作。
一、核心需求
将数据从ECS服务器上的自建MySQL，迁移至移动云RDS。
接入电信云作为备库，实现异云容灾。
在预期部门无法及时配合切换的情况下，确保平滑迁移不影响业务数据流转。
二、技术方案
1、前期梳理
事实上目前为止前置库的管理一直比较混乱，明确各个数据库及帐号的归属、梳理账号权限和白名单设置情况也是本项目的任务之一。
2、准备阶段
此阶段的核心目标是在不影响现有业务的前提下，建立数据同步链路。
部署新库： 准备一个新的主RDS实例作为迁移目标。
数据同步： 使用DTS (Data Transmission Service)工具，配置从现有ECS上部署的MySQL到新主RDS的单向增量数据同步。
在此期间，所有业务系统（包括各部门业务系统和ODPS）的数据库连接保持不变，继续访问旧的MySQL。新RDS此时作为一个“影子库”，其实时性由DTS保证。
3、平滑切换阶段
考虑到不同业务系统的改造进度和依赖差异，切换过程需要分批次、平滑进行。
直接切换： 对于可以修改配置的业务系统，将其数据库连接地址直接变更为新主RDS的域名。如图中“已完成切换的部门业务系统”。
代理切换： 对于暂时无法修改配置，或尚未完成切换的业务，采用反向代理方案作为过渡。在原MySQL所在的ECS上部署Nginx，并配置TCP转发。这样，未切换的应用依然访问旧的IP地址，但请求会被Nginx透明地转发至新的主RDS。
这个阶段，新旧两种连接方式并存，但所有数据库的实际读写都已经落在新的主RDS上。
4、异云容灾与收尾
在所有业务系统都完成切换，确认不再有流量走向Nginx代理后，即可进入收尾和容灾建设阶段。
完成切换： 协调所有业务方（包括ODPS），确保其数据库连接均已改为直接访问主RDS域名。
资源释放： 下线并释放用于Nginx代理的ECS资源。
容灾建设：
灾备云对等部署所有ECS和RDS节点。
在主RDS和灾备RDS之间建立数据同步链路。
通过DNS对数据库域名进行管理。当主节点发生故障时，可通过变更DNS解析将流量切换至灾备节点，实现容灾。
三、进度计划
略。
四、沟通机制
1.、组织架构
数据局
移动云
电信云
平台运维总集
各子平台负责人
数据运维总集
数据归集、治理、共享、专题库运维业务
各区县大数据中心
部门数据专员
2.、联系人清单
略。
3、问题通报、反馈机制
五、质量及风险控制
1、影响范围
如果出现级故障，可能影响
如果出现级故障，可能影响
2、Nginx代理的风险
第二阶段的Nginx代理是一个过渡方案，但也构成了一个单点。如果它在切换窗口期内故障，会影响未切换的业务。这里或许需要评估风险或准备备用方案（如Keepalived）。
3、切换的RTO/RPO
基于DNS的故障切换，需要考虑各地DNS缓存刷新延迟，这会直接影响RTO（恢复时间目标）。同时，主备RDS之间的数据同步链路延迟决定了RPO（恢复点目标）。这两个指标需要明确。
六、附件
1. 关联部门及联系人清单
2. 各部门与前置库数据表对应关系明细
3. 各前置库数据表使用明细确认表
4. 需求确认单
5. 实施方案确认表
6. 部门参与计划确认表
7. 部门完成改造确认单
8. 数据核查记录表
9. 业务核查表
10. 验收确认单
评论区