DTS支持将源DRDS实例同步或迁移至目标库。但是由于直接使用DRDS作为源实例配置DTS任务,当该实例下挂载的RDS MySQL数量超过2个时,可能会产生性能瓶颈,稳定性风险,最终可能会对业务造成影响。为了更好保障任务的性能和稳定性,DTS建议您在配置时,根据DRDS下挂载的RDS MySQL实例,分别配置DTS任务。

前提条件

您已阅读源为DRDS的功能规范和约束说明,已确保遵循相关规范,了解注意事项。

任务配置方案

方案 配置方式 特点总结
方案一 针对DRDS下的多个RDS MySQL实例,配置多个同步或迁移至目标实例的DTS任务,并且在配置过程中,需将多个RDS MySQL的数据库表名都映射成目标实例的库表名。

该方案相比于直接配置DRDS至目标实例的同步或迁移任务,更能保障性能和稳定性。

注意 该方案仅支持表级别同步或迁移。
推荐您使用方案一,其在性能、稳定性方面均优于方案二,且对DRDS下挂载的RDS MySQL数量没有限制。
方案二 直接使用DRDS作为源实例配置同步或迁移至目标实例任务,当该实例下挂载的RDS MySQL实例数量超过2个后,可能会对DTS任务的稳定性、操作性产生较大影响,严重时甚至将影响业务。 使用方案二时,如源DRDS下挂载的RDS MySQL实例超过2个时,DTS任务可能会有性能和稳定性风险。

方案对比

对比项 方案一 方案二
性能 拆分成多个DTS任务,性能成倍增长,可承载大规模的DRDS数据写入, 仅配置一个以DRDS为源的DTS任务,当业务系统写入源实例数据量较大时,会存在性能瓶颈。
稳定性 稳定性较强。

配置DRDS下多个RDS MySQL至目标库的DTS任务,如其中一个DTS任务发生故障,则不影响其他DTS任务的运行,且只需恢复发生故障的DTS任务即可。

稳定性一般。

仅配置一个以DRDS为源的DTS任务,如该DTS任务发生故障,则整个DTS任务会失败。

易用性 需配置多次,相对较繁琐。需要拆分成独立的任务,且每次配置均需做库表名映射,将源实例多个RDS MySQL的库表名映射成目标实例中库表的名称,如源实例中RDS MySQL实例的数量和库表数量较多,则需配置多次的映射。 配置方便,仅需配置一个DRDS为源的DTS任务。
资源占用 拆分成n个独立的DTS任务,消耗n个DTS实例。 消耗1个DTS实例。

两种方案如何实现DDL同步或增量迁移

目前DRDS为源的同步或迁移任务,暂不支持同步或增量迁移DDL操作,如源DRDS在同步或迁移时执行DDL操作,为避免数据写入目标端失败,一般解决方案如下:

  1. 释放DTS任务。
  2. 清空目标库。
  3. 重新配置任务。

DRDS为源的部分同步或迁移场景中,支持在保留DTS任务的同时,实现同步或增量迁移DDL操作,具体场景及对应的操作,如下所示:

场景 操作
使用方案一,仅支持表级别同步。
  • 支持通过修改同步对象来实现加表的操作。
  • 目前仅DRDS间的同步,支持加列、减列的操作,且需按如下操作执行:
    1. 修改同步对象,使其包含或删除列。
    2. 先在目标库手动进行加列或减列,然后在源端执行对应的加列或减列操作。当目标库已经存在这个列时,则DTS会忽略这个报错,且不会显示写入失败。
使用方案二,且同步或迁移对象为整库。
  • 仅支持加表的操作,且需先在目标库手动加上新表,然后在源端执行加表的操作。
  • 不支持加列、减列的操作。
    警告 在源DRDS执行加列操作,可能会导致底层多个物理表不一致,有的缺少该列,有的包含该列。从而DTS在拼装的SQL语句,可能会找不到该列,或者丢失该列的数据。
使用方案二,且同步对象为非整库。
  • 仅支持加表的操作,且需按如下操作执行:
    1. 修改同步对象,使其包含该新表。
    2. 先在目标库手动加上新表,然后在源端执行加表的操作。
  • 不支持加列、减列的操作。