迁移工具DMS数据同步功能测试

AWS迁移： 迁移工具DMS数据同步功能测试

准备⼯作

AWS DMS Replication Instance(dms.t3.large，ap-southeast-1c)

Source Mysql:

新加坡：172.31.28.171（master），172.31.22.6（slave）

Target Mysql:

新加坡：172.31.31.36（master），172.31.16.222（slave）

法兰克福：172.31.29.255（master），172.31.19.219（slave）

1    数据同步测试

1.1    功能测试

1.1.1    表级别全量数据单向同步

测试场景：新建单表数据单向同步操作

测试⽬标：测试表级别全量数据单向同步功能测试环境：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：

先在Source Mysql（172.31.28.171:3456）中的sampledb.t_order表写⼊100W数据，开启同步任务导⼊存量数据，耗时8s。

1.1.2    库级别全量数据单向同步测试场景：新建库数据同步操作

测试⽬标：测试库级别全量数据单向同步功能

测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：先在Source Mysql（172.31.28.171:3456）中的sampledb.t_order表和sampledb.t_item分别写⼊100W数据，然后开启同步任务导⼊存量数据，sampledb.t_order表数据量100W，full load耗时10s，sampledb.t_item表数据量100W，耗时9s，总耗时13s。

测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：先在Source Mysql（172.31.28.171:3456）中的sampledb.t_order表和sampledb.t_item分别写⼊100W

数据，然后开启同步任务导⼊存量数据，sampledb.t_order表数据量100W，full load耗时：4m10s；sampledb.t_item表数据量100W，full load耗时4m27s，总耗时4m38s。

1.1.3    表级别数据单向增量同步测试场景：单表INERT操作

测试⽬标：测试表级别数据单向同步功能测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒在Source Mysql中sampledb.t_item执⾏4条批量INSERT，数据能够正确同步到Target Mysql，同步时延⼤概4秒左右。

测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：每秒在Source Mysql中sampledb.t_item执⾏4条批量INSERT，数据能够正确同步到Target Mysql，同步时延⼤概7秒左右。

测试场景：单表UPDATE操作

测试⽬标：测试表级别数据单向同步功能测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒在Source Mysql中sampledb.t_item执⾏4条UPDATE，数据能够正确同步到Target Mysql，同步时延⼤概4秒左右。

测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：每秒在Source Mysql中sampledb.t_item执⾏4条UPDATE，数据能够正确同步到Target Mysql，同步时延⼤概7秒左右。

测试场景：单表事务操作

测试⽬标：测试单表事务操作同步功能测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒在Source Mysql中sampledb.t_order执⾏批量2条INSERT和1条UPDATE，数据能够正确同步到

Target Mysql，同步时延⼤概4秒左右。测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：每秒在Source Mysql中sampledb.t_order执⾏批量2条INSERT和1条UPDATE，数据能够正确同步到Target Mysql，同步时延⼤概7秒左右。

1.1.4    库级别数据单向同步（增量）测试场景：多表INERT操作

测试⽬标：测试库级别数据单向同步功能测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏批量2条INSERT，数据能够正确同步到Target Mysql，同步时延⼤概4秒左右。

测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏批量2条INSERT，数据能够正确同步到Target Mysql，同步时延⼤概7秒左右。

测试场景：多表UPDATE操作

测试⽬标：测试库级别数据单向同步功能测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏批量2条Update，数据能够正确同步到Target Mysql，同步时延⼤概4秒左右。

测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏批量2条Update，数据能够正确同步到Target Mysql，同步时延⼤概7秒左右。

测试场景：多表事务操作

测试⽬标：测试多表事务操作数据单向同步功能

测试环境1：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏2条批量INSERT和2条UPDATE，数据能够正确同步到Target Mysql，同步时延⼤概4秒左右。

测试环境2：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）Target Mysql（欧洲法兰克福）: 172.31.29.255:3456（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏2条批量INSERT和2条UPDATE，数据能够正确同步到Target Mysql，同步时延⼤概7秒左右。

1.1.5    DDL同步

测试场景：常⽤DDL操作

测试⽬标：测试表增加字段单向同步功能测试环境：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：⽀持的DDL

代码块

PlainText

复制

CREATE TABLE XXX;

ALTER TABLE XXX ADD COLUMN XXX;（不⽀持指定位置）

ALTER TABLE XXX DROP COLUMN XXX; TRUNCATE TABLE XXX;

DROP TABLE XXX;

不⽀持的DDL代码块PlainText

复制

CREATE view, procedure, function, trigger; CREATE [UNIQUE] INDEX XXX ON XXX;

ALTER TABLE XXX DROP [UNIQUE] INDEX XXX; RENAME TABLE XXX;

1.2    性能测试

测试场景：单表批量INERT操作

测试⽬标：测试表级别异地数据单向同步性能测试环境（同region）：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒在Source Mysql中sampledb.t_item执⾏1000条批量INSERT，数据能够正确同步到Target Mysql，同步时延⼤概6秒左右。

测试场景：多表批量INERT操作

测试⽬标：测试库级别异地数据单向同步性能测试环境（同region）：

AWS DMS（亚太新加坡）：dms.t3.large，2CPUs 4GiB Memory

Source Mysql（亚太新加坡）: 172.31.28.171:3456（master）

Target Mysql（亚太新加坡）: 172.31.31.36（master）

测试结果：每秒分别在Source Mysql中sampledb.t_order和sampledb.t_item执⾏批量500条INSERT，数据能够正确同步到Target Mysql，同步时延⼤概6秒左右。

1.3    异常测试

测试场景：源数据异常（宕机、断⽹）后恢复测试⽬的：测试源数据同步断开后恢复的处理测试环境：

AWS DMS（dms.t3.large，新加坡）

Source Mysql（新加坡）: 172.31.28.171:3456(master)

Target Mysql（新加坡）: 172.31.31.36:3456（master）

测试结果：⼿动停⽌Source Master Mysql（172.31.28.171:3456）一段时间后，将其恢复正常， AWS DMS能够在最后一次的CDC checkpoint继续进⾏复制。

测试场景：⽬标数据库异常（宕机、断⽹）后恢复测试⽬的：测试⽬标数据同步断开后恢复的处理

测试环境：

AWS DMS（dms.t3.large，新加坡）

Source Mysql（新加坡）: 172.31.28.171:3456(master)

Target Mysql（新加坡）: 172.31.31.36:3456（master）

测试结果：⼿动停⽌Target Master Mysql（172.31.31.36:3456）一段时间后，将其恢复正常， AWS DMS能够在最后一次的CDC checkpoint继续进⾏复制。

测试场景：数据同步系统（DTS）异常（宕机、断⽹）后恢复测试⽬的：测试数据同步系统（DTS）异常后恢复的处理

测试环境：

AWS DMS（dms.t3.large，新加坡）

Source Mysql（新加坡）: 172.31.28.171:3456(master)

Target Mysql（新加坡）: 172.31.31.36:3456（master）

测试结果：在持续复制过程中关闭任务一段时间，然后继续任务，AWS DMS能够在最后一次的CDC checkpoint继续进⾏复制。

测试场景：源数据库宕机发⽣主备切换

测试⽬的：测试源数据库发⽣主备切换数据同步的处理测试环境：

AWS DMS（dms.t3.large，新加坡）

Source Mysql（新加坡）: 172.31.28.171:3456(master)，172.31.22.6:3456(slave)

Target Mysql（新加坡）: 172.31.31.36:3456（master）

测试结果：⼿动停⽌Source Master Mysql（172.31.28.171:3456），将Source Slave Mysql（172.31.22.6:3456）提升为master， AWS DMS能够在最后一次的CDC checkpoint继续进⾏复制。

测试场景：⽬标数据库宕机发⽣主备切换

测试⽬的：测试⽬标数据库发⽣主备切换数据同步的处理测试环境：

AWS DMS（dms.t3.large，新加坡）

Source Mysql（新加坡）: 172.31.28.171:3456（master）

Target Mysql（新加坡）: 172.31.31.36:3456（master），172.31.16.222:3456（slave）

测试结果：⼿动停⽌Target Master Mysql（172.31.31.36:3456），将Target Slave Mysql（172.31.16.222:3456）提升为master， AWS DMS能够在最后一次的CDC checkpoint继续进⾏复制。

2    测试结论

增量数据较大时，增量同步延时较⼤。跨region的同步，⽬前测试采⽤公⽹进⾏，所以延时较⼤。

将DMS的规格由T3.large调整为c5.xlarge以及调整同步任务相关参数之后，在两张同时进⾏写⼊操作（12左右TPS）的场景下，同区域（内⽹）下的增量同步CDC Latency Source降低为1秒， CDC Latency Target（数据同步延时）降低为1秒多。

不同区域（公⽹）CDC Latency Target（数据同步延时）有7秒多，还需要进一步寻找优化空间。

3    最佳实践建议

不使⽤LOB字段

通过业务架构设计，尽量将不同区域数据分开来（减少同步数据）

需要同步的表都有唯一的主键，有唯一约束的字段保证全局唯一

部分同步场景⽐如更新同步延时，但对一致性要求降低等场景可以关闭⽇志或数据校验，或者通过单独的任务进⾏数据校验

最好不要有事务，做到单表同步最优