数据传输服务DTS(Data Transmission Service)支持两个PolarDB MySQL版集群间的双向数据同步,适用于异地多活、异地容灾等多种应用场景。本文介绍双向数据同步的配置步骤。
前提条件
- 已购买源和目标PolarDB MySQL版集群(简称PolarDB集群),详情请参见购买按量付费集群。
- 源和目标PolarDB MySQL版集群已开启Binlog,详情请参见如何开启Binlog。
注意事项
- DTS在执行全量数据初始化时将占用源库和目标库一定的读写资源,可能会导致数据库的负载上升,在数据库性能较差、规格较低或业务量较大的情况下(例如源库有大量慢SQL、存在无主键表或目标库存在死锁等),可能会加重数据库压力,甚至导致数据库服务不可用。因此您需要在执行数据同步前评估源库和目标库的性能,同时建议您在业务低峰期执行数据同步(例如源库和目标库的CPU负载在30%以下)。
- 全量初始化过程中,并发INSERT会导致目标集群的表碎片,全量初始化完成后,目标集群的表空间比源集群的表空间大。
- 如果数据同步的源集群没有主键或唯一约束,且记录的全字段没有唯一性,可能会出现重复数据。
- 如双向同步任务的源实例或目标实例位于海外地域,则仅支持同地域的双向同步,不支持跨地域的双向同步。例如,支持日本地域间的双向同步,不支持日本地域与法兰克福地域间的双向同步。
费用说明
同步类型 | 链路配置费用 |
---|---|
库表结构同步和全量数据同步 | 不收费。 |
增量数据同步 | 收费,详情请参见计费概述。 |
功能限制
- 目前DTS仅支持一对一双向同步,暂不支持多个PolarDB MySQL版集群间的双向同步。
- 数据同步时,请勿对源库的同步对象使用gh-ost或pt-online-schema-change等类似工具执行在线DDL变更,否则会导致同步失败。
- 不兼容触发器
当同步对象为整个库,且库中的触发器(TRIGGER)会更新库内某个表时,可能导致源和目标库的数据不一致。相关解决方案请参见源库存在触发器时如何配置同步作业。
- RENAME TABLE限制
RENAME TABLE操作可能导致同步数据不一致。例如同步对象只包含某个表,如果同步过程中源实例对该表执行了重命名操作,那么该表的数据将不会同步到目标库。为避免该问题,您可以在数据同步配置时将该表所属的整个数据库作为同步对象。
- DDL语法同步方向限制
为保障双向同步链路的稳定性,DDL更新只能在其中一个同步方向进行同步。即一旦某个同步方向配置了DDL同步,则在反方向上不支持DDL同步,只进行DML同步。
支持同步的SQL操作
操作类型 | SQL操作语句 |
---|---|
DML | INSERT、UPDATE、DELETE、REPLACE |
DDL |
|
支持的冲突检测
为保障同步数据的一致性,您需要确保同一个主键、业务主键或唯一键的记录只在一个PolarDB集群上执行更新。如果发生了误操作,在两个PolarDB MySQL版集群上均执行更新,那么将出现同步冲突。
DTS通过冲突检测和修复最大程度地维护双向同步实例的稳定性。目前DTS支持进行检测的冲突类型包括:
- INSERT导致的唯一性冲突
同步INSERT语句时违背了唯一性约束,例如双向同步的两个节点同时或者在极为接近的时间新增了某个主键值相同的记录,那么同步到对端时,会因为已经存在相同主键值的记录,导致INSERT操作的同步失败。
- UPDATE更新的记录不完全匹配
- UPDATE要更新的记录在同步目标集群中不存在时,DTS会自动转化为INSERT,此时可能会出现唯一键的唯一性冲突。
- UPDATE要更新的记录出现主键或唯一键冲突。
- DELETE对应的记录不存在
DELETE要删除的记录在同步的目标集群中不存在。出现这种冲突时,不论配置何种冲突修复策略,DTS都会自动忽略DELETE操作。
重要
- 由于数据同步两端的系统时间可能存在差异、同步存在延时等多种因素,DTS无法完全保证冲突检测机制能够完全防止数据的冲突。在使用双向同步时,您需要在业务层面配合进行相应的改造,保证同一个主键、业务主键或唯一键的记录只在双向同步的某个节点进行更新。
- 对于上述数据同步的冲突,DTS提供了修复策略,您可以在配置双向同步时选择。