DM在事务执行期间丢失数据

下游数据库是TIDB 4.0版本,上游是mysql 5.6,之前使用dm-ansible部署的dm1.0上同步数据没有出现这个问题。12月3日后升级到2.0版本,并通过import将之前的任务和配置导入了tiup,随后发现,在开启事务后下游的TIDB数据库丢失了数据,详细情况如下:
1.上游数据库和下游数据库已在线,部署了dm-worker并通过start-task开启了同步任务,子任务状态为running,sync为true,显示已经追上,此时新建一个表:

CREATE TABLE `t_test_cycle_plan` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `create_time` datetime DEFAULT NULL,
  `modify_time` datetime DEFAULT NULL,
  `memo` varchar(5000) DEFAULT NULL,
  `planned_begin_time` date NOT NULL,
  `planned_end_time` date NOT NULL,
  `status` int(11) DEFAULT NULL,
  `creator` bigint(20) DEFAULT NULL,
  `modifier` bigint(20) DEFAULT NULL,
  `test_cycle` bigint(20) DEFAULT NULL,
  `tester` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10000 DEFAULT CHARSET=utf8;

该DDL操作可以正常同步到下游的TIDB数据库,然后向上游表中插入数据,sql如下:

start transaction;
INSERT INTO t_test_cycle_plan (create_time,creator,modifier,modify_time,memo,planned_begin_time,planned_end_time,status,test_cycle_tester) VALUES ('2020-12-10 11:16:53', NULL,NULL,NULL,NULL,'2020-12-10','2020-12-11',1,59293,2098);
INSERT INTO t_test_cycle_plan (create_time,creator,modifier,modify_time,memo,planned_begin_time,planned_end_time,status,test_cycle_tester) VALUES ('2020-12-10 11:16:53', NULL,NULL,NULL,NULL,'2020-12-10','2020-12-11',1,59293,2098);
INSERT INTO t_test_cycle_plan (create_time,creator,modifier,modify_time,memo,planned_begin_time,planned_end_time,status,test_cycle_tester) VALUES ('2020-12-10 11:16:53', NULL,NULL,NULL,NULL,'2020-12-10','2020-12-11',1,59293,2098);
commit;

半小时后
在上游数据库查询:

SELECT * FROM t_test_cycle_plan WHERE test_cycle = 59293;

上游数据库显示:

id    crewate_time    modify_time    memo    planned_begin_time    planned_end_time    status    creator    modifier    test_cycle    tester
453165    2020-12-10 11:16:53    NULL    NULL    2020-12-10    2020-12-11    1    NULL    NULL    59293    2098
453166    2020-12-10 11:16:53    NULL    NULL    2020-12-10    2020-12-11    1    NULL    NULL    59293    2098
453167    2020-12-10 11:16:53    NULL    NULL    2020-12-10    2020-12-11    1    NULL    NULL    59293    2098

下游数据库显示:

id    crewate_time    modify_time    memo    planned_begin_time    planned_end_time    status    creator    modifier    test_cycle    tester
453165    2020-12-10 11:16:53    NULL    NULL    2020-12-10    2020-12-11    1    NULL    NULL    59293    2098

dm-worker开启了debug日志级别,且上游mysql的binlog可以看到三条INSERT INTO t_test_cycle_plan记录,但是dm-worker日志上只有第一条的INSERT INTO记录,从查询结果上看,同事务的后面两个sql没有同步,debug日志也没有报错。
这个任务在1.0版本上执行时没有出现这个问题,最近升级的2.0才出现,而且,尝试创建的新的任务,也会丢失同事务的后续操作,只有第一个sql会执行。

之前为了修复dm-worker因为task中的表过多会异常退出的bug,建议修复方案是升级到了nightly版本

集群环境如下:

tidb@Monitor-01:~$ tiup dm display dm-cluster
Starting component `dm`: /home/tidb/.tiup/components/dm/v1.2.5/tiup-dm display dm-cluster
Cluster type:    dm
Cluster name:    dm-cluster
Cluster version: nightly
SSH type:        builtin
ID                  Role          Host           Ports      OS/Arch       Status     Data Dir                                                              Deploy Dir
--                  ----          ----           -----      -------       ------     --------                                                              ----------
10.66.193.60:9193   alertmanager  10.66.193.60   9193/9094  linux/x86_64  Up         /home/tidb/data/dm_monitor/deploy/alertmanager/data.alertmanager      /home/tidb/data/dm_monitor/deploy/alertmanager/alertmanager-9193
10.66.193.60:8261   dm-master     10.66.193.60   8261/8291  linux/x86_64  Healthy|L  /home/tidb/data/dm_master/deploy/dm-master-8261/data                  /home/tidb/data/dm_master/deploy/dm-master-8261
10.66.193.57:8262   dm-worker     10.66.193.57   8262       linux/x86_64  Bound      /home/tidb/dm-deploy/dm-worker-8262/data                              /home/tidb/dm-deploy/dm-worker-8262
10.66.193.58:8262   dm-worker     10.66.193.58   8262       linux/x86_64  Bound      /home/tidb/data/dm_worker/deploy/data                                 /home/tidb/data/dm_worker/deploy
10.66.193.59:8262   dm-worker     10.66.193.59   8262       linux/x86_64  Bound      /home/tidb/data/dm_worker/deploy/data                                 /home/tidb/data/dm_worker/deploy
10.66.205.211:8262  dm-worker     10.66.205.211  8262       linux/x86_64  Bound      /home/tidb/data/dm_worker/deploy/data                                 /home/tidb/data/dm_worker/deploy
10.66.193.60:9000   grafana       10.66.193.60   9000       linux/x86_64  Up         -                                                                     /home/tidb/data/dm_monitor/deploy/grafana/grafana-9000
10.66.193.60:9190   prometheus    10.66.193.60   9190       linux/x86_64  Up         /home/tidb/data/dm_monitor/deploy/prometheus/prometheus.data.metrics  /home/tidb/data/dm_monitor/deploy/prometheus/prometheus-9190
Total nodes: 8

查询任务状态如下:

» query-status test
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "sourceStatus": {
                "source": "mysql-replica-04",
                "worker": "dm-10.66.193.57-8262",
                "result": null,
                "relayStatus": null
            },
            "subTaskStatus": [
                {
                    "name": "test",
                    "stage": "Running",
                    "unit": "Sync",
                    "result": null,
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "20",
                        "totalTps": "0",
                        "recentTps": "0",
                        "masterBinlog": "(mysql-bin.000117, 9854)",
                        "masterBinlogGtid": "",
                        "syncerBinlog": "(mysql-bin.000117, 9854)",
                        "syncerBinlogGtid": "",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": true,
                        "binlogType": "remote"
                    }
                }
            ]
        }
    ]
}

你好,内部已复现该问题,经测试,去掉 begin commit; 执行时下游同步三条数据,正常同步。原因我们再查一下。

你好,尝试去掉begin commit的话,事务内的sql相当于拆分成了多个小事务执行,测试过这种情况下是会正常同步的,然而这样破坏了事务完整性,显然是不可取的。事务隔离级别这个问题,应该属于比较高级别的问题了,数据同步部分丢失后,这个有方法重做吗?通过safe-mode设置为true后,是否可以把binlog position回退到一个较早期的位置?发现这个问题引起的数据不一致有多处,正在排查。目前的解决方案只能是回退到1.0版本,重新部署。可能优先保证生产环境上的功能。是否有更好的建议?期望问题早日修复。

这个是 nightly 版本才有的问题,具体是由 https://github.com/pingcap/dm/pull/1303 这个pr导致的,
https://github.com/pingcap/dm/pull/1329 这个 pr 进行修复。即影响 11 月 26 日之后的 nightly 版本,你这边如果有记录 2.0 升级到 nightly 时的 checkpoint 位点信息,可以把 binlog position 回退。
另外也可以使用 sync-diff 来对比上下游数据不一致的情况,将缺失数据导入到下游。

https://docs.pingcap.com/zh/tidb/stable/sync-diff-inspector-overview

1 个赞

如线上环境,是否可以填写下表单?

你好,该 bug 已修复,可拉取最新的 nightly 版本测试。生产环境暂时不建议使用。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。