DM dump时表并发任务如何分配且sync报invalid sequence 8 != 1

【版本】DM v2.0.6,TiDB v5.2.3, 上游mysql 8.0.23
【问题】使用DM从上游MySQL 全量同步2张表,DUMP时发现卡在一个select上
SELECT MIN(session_id),MAX(session_id) FROM skyalarm.oracle_active_sess
image
后续开始执行dump后发现使用上述SQL进行导出任务数据范围的分配,session_id字段属于主键列的第3个字段,没有该列的首列索引导致上述SQL执行很慢,同时导出任务以session_id作为条件导出,大量全表扫描导出速度很慢。导出SQL语句如下:
SELECT sample_time,instance_number,Instance_name,session_id,session_serial,blocking_session,session_type,qc_session_id,session_state,sql_id,event,wait_class,p1,p2,p3,machine,program,module,time_waited,plsql_entry_object_id,write_iops,read_iops,cpu_time,write_iomb,read_iomb,net_io,dbtime,sql_plan_hash_value,username FROM skyalarm.oracle_active_sess WHERE (session_id >= 262 AND session_id < 271) ORDER BY sample_time,Instance_name,session_id,session_serial
表结构如下:
| oracle_active_sess | CREATE TABLE oracle_active_sess (
sample_time datetime NOT NULL,
instance_number int DEFAULT NULL,
Instance_name varchar(16) NOT NULL,
session_id bigint NOT NULL,
session_serial bigint NOT NULL,
blocking_session bigint DEFAULT NULL,
session_type varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
qc_session_id bigint DEFAULT NULL,
session_state varchar(7) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
sql_id varchar(13) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
event varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
wait_class varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
p1 bigint unsigned DEFAULT NULL,
p2 bigint unsigned DEFAULT NULL,
p3 bigint unsigned DEFAULT NULL,
machine varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
program varchar(48) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
module varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
time_waited bigint unsigned DEFAULT NULL,
plsql_entry_object_id bigint DEFAULT NULL,
write_iops bigint unsigned DEFAULT NULL,
read_iops bigint unsigned DEFAULT NULL,
cpu_time bigint unsigned DEFAULT NULL,
write_iomb bigint unsigned DEFAULT NULL,
read_iomb bigint unsigned DEFAULT NULL,
net_io bigint unsigned DEFAULT NULL,
dbtime bigint DEFAULT NULL,
sql_plan_hash_value bigint DEFAULT NULL,
username varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,
PRIMARY KEY (sample_time,Instance_name,session_id,session_serial)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

DM在导出数据时任务分配逻辑是什么? 为什么会选择这样一个字段而不使用索引的首列?
将源端mysql数据truncate ,dm_meta相关任务表truncate,然后重新start-task执行任务,load完后开始sync是报错Message": “fail to restart streamer controller: start syncing binlog from remote streamer”,
“RawCause”: “invalid sequence 8 != 1”,

query-status的binlog位置
“syncerBinlog”: “(mysql2_bin.033376, 204642979)”,
“syncerBinlogGtid”: “a3c489d9-63ae-11eb-9c31-485702422bb3:1-13419301”,

binlog信息


query-status 的信息发全一些吧(上面的 分配逻辑是:主键/唯一索引,你的是组合组件,第一个字段不是 int 类型,所以选了第三个字段:猜的,一会确认一下)

上面逻辑确实是由于 dm 目前无法字符类型的切分,所以只能先用 数字类型的字段来进行拆分

后面会修复上面的逻辑(dumplings 已经修复了,但好像还没合到 DM)

预计在什么版本进行修复。下面是query-status的报错,我重新配置的 任务binlog位置已经有变化
{
“result”: true,
“msg”: “”,
“sources”: [
{
“result”: true,
“msg”: “”,
“sourceStatus”: {
“source”: “ty-69.187”,
“worker”: “dm-10.161.69.185-8265”,
“result”: null,
“relayStatus”: null
},
“subTaskStatus”: [
{
“name”: “ty_task1”,
“stage”: “Paused”,
“unit”: “Sync”,
“result”: {
“isCanceled”: false,
“errors”: [
{
“ErrCode”: 36053,
“ErrClass”: “sync-unit”,
“ErrScope”: “internal”,
“ErrLevel”: “high”,
“Message”: “fail to restart streamer controller: start syncing binlog from remote streamer”,
“RawCause”: “invalid sequence 8 != 1”,
“Workaround”: “”
}
],
“detail”: null
},
“unresolvedDDLLockID”: “”,
“sync”: {
“totalEvents”: “0”,
“totalTps”: “0”,
“recentTps”: “0”,
“masterBinlog”: “(mysql2_bin.033445, 438570295)”,
“masterBinlogGtid”: “a3c489d9-63ae-11eb-9c31-485702422bb3:1-13470188”,
“syncerBinlog”: “(mysql2_bin.033376, 204642979)”,
“syncerBinlogGtid”: “a3c489d9-63ae-11eb-9c31-485702422bb3:1-13419301”,
“blockingDDLs”: [
],
“unresolvedGroups”: [
],
“synced”: false,
“binlogType”: “remote”,
“secondsBehindMaster”: “0”
}
}
]
}
]
}

DM 下个版本应该就修复了,至于报错,你truncate 上游的表,下游的checkpoint 怎么 删除的?(重新搭建能解决问题,不过你的操作我想确认一下)

我又重新跑了次 ,操作过程 1, truncate 源端表
image
2. 清理DM_meta表任务信息
image
3. 启动任务,可以正常dump/load


4. 进入sync阶段开始报错

哦,你不能用 truncate table,checkpoint 信息你需要删除(恢复到“干净”环境)

image
drop table方式也是同样问题

2个同步任务,从另一个mysql同步的就没这问题

问一下:好的那个 mysql 版本是多少啊

8.0.17 , 你说‘干净’的环境是什么问题,什么原因。

https://github.com/pingcap/ticdc/issues/3847(上面报错的原因,预计下个版本修复)

使用native_password创建新用户授予all权限,stop souce后修改source的用户名和密码新建source正常,start task时报权限错误
image


另外operate-source 可不可以出一个test测试命令

日志报什么信息

worker改到debug级别无日志输出


你创建用户时,不带 mysql ——native 参数试试,可以不(你这里明显的报错,不像是逻辑问题,应该就是 特殊字符/空格之类的问题导致:猜的)

ok了,昨天改了下task配置文件里面的用户导致的 。

:ok_hand::ok_hand::ok_hand:

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