必须开启ROW格式Binlog，且binlog_format=ROW、binlog_row_image=FULL、log_bin=ON；双主架构还需log_slave_updates=ON；DMS同步依赖此配置，否则增量失败或数据不一致。
直接用 mysqldump 导出再导入，适合数据量小、能接受停机的场景；若需不停服、保证一致性，必须用 AWS DMS（Database Migration Service），且源库必须开启 ROW 格式的 Binlog。
源库必须开启并验证 ROW 格式 Binlog
这是所有持续同步方案的前提。DMS 增量捕获依赖 Binlog，而 STATEMENT 或 MIXED 格式会导致数据不一致甚至任务失败。
- 检查当前设置：
SHOW VARIABLES LIKE 'binlog_format';和SHOW VARIABLES LIKE 'binlog_row_image';，二者值必须为ROW和FULL - 若不满足，需在源库
my.cnf中添加：binlog_format = ROW、binlog_row_image = FULL，然后重启 MySQL - 确认 Binlog 已启用：
SHOW VARIABLES LIKE 'log_bin';返回ON - 特别注意：如果源库是双主架构，还必须开启
log_slave_updates = ON，否则 DMS 只能捕获部分日志
用 mysqldump 迁移时绕不开的大小写陷阱
RDS MySQL 默认将表名转为小写（lower_case_table_names = 1），而本地 Linux 环境下 MySQL 默认区分大小写。导出再导入后，原 UserOrder 表可能变成 userorder，应用查询直接报错 ERROR 1146 (42S02): Table doesn't exist。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 最稳妥做法：在创建 RDS 实例时，就将参数组中
lower_case_table_names设为0（仅限 MySQL 5.7/8.0.32 以下版本；8.4+ 不支持修改） - 若实例已存在且无法重建，导出时加
--skip-extended-insert+ 手动替换 SQL 文件中的表名（不推荐，易出错） - 导出命令建议带上
--databases和--set-gtid-purged=OFF（避免 GTID 冲突），例如：mysqldump -h 192.168.1.100 -u root -p --databases mydb --single-transaction --set-gtid-purged=OFF > dump.sql
DMS 迁移任务配置的关键校验点
DMS 控制台界面友好，但几个隐藏配置项一旦漏设，任务会在“预检查”阶段失败或后期丢数据。
- 源端连接测试通过 ≠ 预检查通过：必须确保 DMS 复制实例所在子网能访问源库的
3306端口，且源库账号有REPLICATION CLIENT和REPLICATION SLAVE权限 - 目标 RDS 的 Binlog 保留时间必须 ≥72 小时（调用
mysql.rds_set_configuration('binlog retention hours', 72)），否则增量同步中断后无法追平 - 迁移对象若含视图、存储过程，DMS 默认不迁移——需在“选择数据库对象”步骤手动勾选“其他对象”，否则结构不全
- 遇到
ORA-00942: table or view does not exist类错误，大概率是源表没主键或唯一索引；DMS 要求每张待迁移表必须有显式主键
真正容易被忽略的是网络路径和权限的双向性：DMS 复制实例既要连通源库（出方向），也要能被 RDS 安全组放行（入方向），而很多人只配了前者。另外，lower_case_table_names 的限制不是警告，是硬性约束——设成 0 后不能再切回 1，否则实例直接不可用。
