一、核心需求
将数据从ECS服务器上的自建MySQL，迁移至XX云RDS。
接入XX云作为备库，实现异云容灾。
在预期部门无法及时配合切换的情况下，确保平滑迁移不影响业务数据流转。
二、技术方案
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代理的风险
略
3、切换的RTO/RPO
略
六、附件
1. 关联部门及联系人清单
2. 各部门与前置库数据表对应关系明细
3. 各前置库数据表使用明细确认表
4. 需求确认单
5. 实施方案确认表
6. 部门参与计划确认表
7. 部门完成改造确认单
8. 数据核查记录表
9. 业务核查表
10. 验收确认单
评论区