生产环境Amazon RDS MySQL无停机修改数据库collate方案咨询

传统影子表变更方案（创建同结构新表→修改新表目标Collation→导入存量数据→创建索引等配套对象→原表重命名加_old后缀→新表重命名为业务名→补全切表窗口期增量数据）在单表数据量过大、业务写入峰值高的场景下，切表后的增量补数阶段很容易出现锁等待堆积、数据库延迟飙升，最终引发业务读写不可用，且多表场景下手动操作成本极高，无法支撑全库批量变更。
基于AWS DMS的无停机变更流程可以完全规避上述问题，具体操作步骤如下：

• 前置元数据准备：新建一套和源实例数据库版本完全一致的目标RDS实例，从源库导出全量表结构、视图、存储过程等元数据，批量修改所有表、字符型字段的Collation为目标值后，导入目标RDS；此阶段仅导入元数据，不导入业务存量数据，暂时不创建二级索引以提升后续数据导入效率。
• 配置DMS同步任务：创建规格匹配业务数据量的DMS复制实例，分别配置指向源RDS、目标RDS的连接端点，创建全量初始化+持续增量捕获的同步任务，同步范围覆盖全库所有业务表；任务配置阶段关闭目标端外键约束检查，仅保留主键索引，最大化全量数据加载速度。
• 同步阶段校验：待全量数据初始化完成后，监控DMS任务的同步延迟指标，待延迟降到0（即源端所有增量写入都已经同步到目标端），再在目标端批量创建所有需要的二级索引、约束、触发器等配套对象；建索引期间DMS会自动缓存源端产生的增量日志，不会中断同步链路。
• 业务切流：索引创建完成、DMS同步延迟再次降至0后，先将业务读写流量按小比例灰度切流到目标RDS，持续观察业务指标、做数据一致性校验，确认无异常后逐步放大流量直到100%切流，整个切流过程仅存在秒级连接闪断，无传统方案的增量补数窗口风险。
• 回滚兜底：切流完成后源RDS保留7-14天只读状态作为回滚备份，确认业务运行稳定无异常后即可下线旧实例。

两个RDS数据库间的双向持续同步是可以实现的，核心基于AWS DMS的双向同步链路搭建，注意做好以下配置即可保证链路稳定运行：

• 基础链路搭建：分别创建两个独立的DMS增量同步任务，第一个任务以数据库A为源、数据库B为目标，开启全量初始化+持续增量同步；第二个任务以数据库B为源、数据库A为目标，同样开启全量+增量同步模式，初始全量同步完成后即可实现两边新增数据的自动互相同步。
• 避坑配置项：
  • 两个实例必须配置错开的自增主键规则：比如数据库A设置自增起始值为1、自增步长为2，数据库B设置自增起始值为2、自增步长为2，从根源上避免双向同步时出现主键冲突。
  • 两个DMS同步任务都要开启循环事务过滤功能，自动识别DMS写入目标端的事务日志，不会将对端同步过来的数据再次回放到源端，避免无限循环复制。
  • 提前配置冲突处理规则：可根据业务需求设置唯一键冲突时的处理逻辑，比如以更新时间更晚的记录为准、按业务优先级保留指定侧的写入，避免同步任务因冲突中断。
• 场景注意事项：双向同步适合多活部署、跨区域容灾类场景，业务侧最好按维度做写入分片（比如按用户地域、业务线拆分写入节点），避免两个节点同时修改同一条记录引发的数据不一致问题。

内容的提问来源于stack exchange，提问作者Msv