阿里云DTS踩坑经验分享系列｜数据不一致修复大法

2024-05-29 262

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

数据管理 DMS，安全协同 3个实例 3个月

数据传输服务 DTS，数据迁移 small 3个月

数据传输服务 DTS，数据同步 1个月

简介： 阿里云数据传输服务DTS在帮助用户迁移数据、同步数据时，在某些复杂场景下会出现源库与目标库数据不一致的问题，造成数据错误，给用户带来困扰。由于数据不一致的问题很难完全避免，为了及时修复不一致的数据，DTS产品推出数据订正功能，保障用户在同步\迁移数据时的数据一致性。本文介绍了产生数据不一致的一些典型场景，并重点阐述了如何使用DTS数据订正功能来修复不一致的数据。

阿里云DTS作为数据世界高速传输通道的建造者，每周为您分享一个避坑技巧，助力数据之旅更加快捷、便利、安全。

点击【立即体验MySQL->ClickHouse同步链路】

1、导读

阿里云数据传输服务DTS在帮助用户迁移数据、同步数据时，在某些复杂场景下会出现源库与目标库数据不一致的问题，造成数据错误，给用户带来困扰。由于数据不一致的问题很难完全避免，为了及时修复不一致的数据，DTS产品推出数据订正功能，保障用户在同步\迁移数据时的数据一致性。本文介绍了产生数据不一致的一些典型场景，并重点阐述了如何使用DTS数据订正功能来修复不一致的数据。

2、DTS数据不一致场景

在同步\迁移数据过程中产生数据不一致场景的原因很复杂，我们可以通过下面的三个典型例子来看下为什么会出现数据不一致的情况。

2.1 字段类型不一致

例如用户在源库中有表A，表结构定义如下，其中 id 为自增主键，user_id 表示用户id，words表示用户的评论

CREATE TABLE `Example`.`A` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id',
  `user_id` int DEFAULT NULL COMMENt 'user_id', 
  `words` text CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci COMMENT 'words',
  Primary Key (`id`)
) ENGINE=InnoDB

在目标库中，用户已经创建了一张需要同步的表A，表结构定义如下

CREATE TABLE `Example`.`A` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id',
  `user_id` int DEFAULT NULL COMMENt 'user_id',
  `words` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci COMMENT 'words',
  Primary Key (`id`)
) ENGINE=InnoDB

如果此时在源端插入一条数据，id = 1, user_id = 123456, words = 'Welcome to use data transmission service!' 如下所示：

INSERT INTO `Example`.`A` (`id`, `user_id`, `words`) VALUES (1, 123456, 'Welcome to use data transmission service!')

在源端这条数据能够被正确地写入，但是在目标端，由于detail字段的类型设置为varchar(20)，写入时会产生截断，最终在目标端写入的数据就会变成：

id = 1, user_id = 123456, words = 'Welcome to use data '

显然，此种情况下目标端的words字段与源端的words字段不一致了。

2.2 业务双写场景

再比如，（接着上面的例子）假设用户在使用DTS进行数据同步的过程中，由于某些原因将部分业务流量切换到了目标端，导致目标端删除了 user_id = 123456 的数据，如下所示：

DELETE FROM `Example`.`A` WHERE `user_id` = 123456

此时目标端的该记录显然会被删除，但由于这是一条单向同步链路，两端业务双写导致源端 user_id = 123456 的记录依然存在，因此产生了数据不一致的情况。

2.3 用户侧非标准操作

DTS无法限制用户的行为，这在一些场景中也会造成数据不一致。例如，DTS支持从自建MySQL数据库同步到RDS MySQL数据库，并支持RENAME TABLE的操作。但如果用户配置任务时选择了仅同步表A，却在同步过程中执行了以下语句：

RENAME TABLE A TO B

此时数据库中实际存在的表为表B，但用户的同步任务配置的却是表A，那么在RENAME TABLE后所有对表B进行的数据变更都不会同步到目标端，造成了数据不一致。（正确操作是配置库级别同步~）

其实对于类似有风险的行为，DTS会在文档中进行说明，用户在配置任务前需要确认这些风险点。详细内容请参考：配置数据同步任务

2.4 小结

实际生产中，产生数据不一致的场景还有很多，尤其是在源端和目标端数据库异构的情况下，DTS研发同学难以在文档中列举出所有可能导致数据不一致的场景，只能在日常运维中 case by case 地分析定位原因。为了及时修复不一致数据，DTS推出了数据订正功能，最大限度确保数据最终一致性。

3、DTS数据订正功能原理

DTS数据订正功能采用校验+订正的模式，即：先校验出不一致的数据，然后将这些不一致的数据进行订正。具体流程如下图所示：

需要指出的是，由于数据订正过程中迁移/同步任务可能还在继续，这有可能导致订正结束之后仍然存在数据不一致，因此在订正的最后会复检订正的数据是否已经完全一致了，DTS也会根据复检的结果来判断是否需要二次订正，直至订正结果显示所有订正的数据在源端和目的端均已保持一致。

此外，由于数据订正是一个高危的操作，为了保证出现问题时的数据可恢复性，DTS会保存所有执行的Insert/Delete/Update等数据操作用于回滚数据。

4、如何使用数据订正功能

4.1 检查数据一致性

检查数据是否一致通常有两种方式：

用户自行检查：通过业务逻辑来判断数据同步是否成功，或者随机地抽取一些数据进行检查。

DTS数据校验：目前DTS的数据校验包括全量校验和增量校验，能精准判断出在数据迁移/同步过程中是否出现了数据不一致，并且能够提供不一致数据的具体内容。

如果用户发现了数据不一致，需要联系DTS的运维同学，排查出数据不一致的原因并进行数据订正。由于数据订正功能属于高危操作，会对用户数据直接进行修改，因此该功能并不直接开放给用户，而是在用户授权的情况下，由研发同学结合实际情况，在后台使用数据订正功能来帮助用户订正数据。

4.2 确认数据订正条件

找到DTS同学之后，DTS同学会及时帮助用户分析数据不一致的原因，并在需要的情况下帮用户订正数据。在数据订正之前需要说明的是，数据订正是有风险的，为了避免造成用户损失，DTS通常会根据过往经验总结一些数据订正条件让用户确认（以下仅为举例说明，以DTS实际提出的订正条件为准）

如果不满足上述订正前置条件，为了避免出现数据订正失败且无法回滚的情况，DTS不会帮助用户进行数据订正。

在满足上述条件之后，用户还需要向DTS同学口头授权同意订正，这样一来DTS同学才可以进行数据订正操作。

4.3 验证订正结果

订正的过程完全由DTS负责，因此用户在发出订正需求之后就不需要进行其它操作了。但在数据订正之后，DTS通常建议用户自己再进行一次全量校验以检查数据是否一致，避免后续产生纠纷。

如果用户对订正的数据有疑问，DTS也可以提供进行数据订正的全部SQL语句。

5、总结

阿里云DTS提供了完整的数据校验+数据订正能力，确保用户在进行数据迁移/同步过程中出现数据不一致时，能够快速发现问题并解决问题，最大限度确保数据最终一致性。

6、快来关注

数据传输服务（Data Transmission Service，简称DTS）支持关系型数据库、NoSQL、大数据（OLAP）等数据源，集数据迁移、订阅、实时同步、校验功能于一体，能够解决公共云、混合云场景下，远距离、秒级异步数据传输难题。其底层基础设施采用阿里双11异地多活架构，为数千下游应用提供实时数据流，已在线上稳定运行7年之久，是一款沉淀了丰富实践经验的可靠产品。点击了解更多DTS相关信息

欢迎加入钉群讨论交流：