tidb dm工具,同步过程中,莫名其妙的报下面这个错误,如何解决

Could not find first log file name in binary log index file
“errors”: [
{
“ErrCode”: 36069,
“ErrClass”: “sync-unit”,
“ErrScope”: “upstream”,
“ErrLevel”: “high”,
“Message”: “get binlog event error: ERROR 1236 (HY000): Could not find first log file name in binary log index file”,
“RawCause”: “”,
“Workaround”: “Please check if the binlog file could be parsed by mysqlbinlog.”
}

2赞

1.上游查看二进制文件:
show binary logs;

2.查看task的配置文件,启始二进制文件在不在这里

这个报错是因为找不到上游二进制文件了,可能的原因
1.上游发生了主从切换
2.二进制刷新的太快

2赞

那怎么避免这种问题呢?我一个下午就出现两次这种情况了

2赞

首先确定下是什么引起的
1.如果是主从切换引起的,可以采用源端+dm源gtid的方式来避免
2.如果是同步速度跟不上,可以看看具体是什么原因,可采用的方法有
源端增加二进制保留的数量
dm开启relay-log
同步的线程数量等

2赞

主从切换引起的,可以采用源端+dm源gtid的方式来避免

2赞

检查下源库的binlog日子的格式是否符合要求,比如row

1赞

上游先别删除(自动或者手动)binlog。等你全做完再删除

1赞

能说详细点吗? 有点听不懂啊,最好带一些具体步骤

1赞
使用前提是上游 MySQL 已开启 GTID 模式。若上游存在主从自动切换,则必须使用 GTID 模式。

问题1: 我怎么查看, 上游 MySQL 已开启 GTID 模式?
问题2: 我怎么查看, 上游存在主从自动切换?
1赞

查看 GTID MODE:

SELECT @@GLOBAL.ENFORCE_GTID_CONSISTENCY;
SELECT @@GLOBAL.GTID_MODE;

可以 show master status 看看现在是不是你之前的主库。GTID 能够避免主从切换带来的 binlog position 定位问题,建议开启;dm 的任务配置也要 enable-gtid(不想开启的话,也可以手动设置一下 binlog position,然后重启 dm task)

找不到 binlog 文件的问题,有可能是上游的 binlog 已经被清理掉了(mysql 会自动清理古老的 binlog),可以开启 dm 的 relay log 功能来把没来得及同步的 binlog 先拉下来。

下面的链接是 dm 任务配置指南,你可以研究一下这些功能要怎么开启。

FYI: https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full

1赞

如果可以的话,能具体描述一下您使用 dm 的场景以及需求吗?或许有更加简单的解决方案。

1赞

数仓这边,将业务库的分库分表的数据实时同步过来

1赞

是不是丢日志了?

你源端是什么库?

了解。对于已经丢失 binlog 的更改,可以用全量+增量的方式进行同步(dm task mode 设置成 all);实时增量同步启动的位置会自动定位到全量同步开始时 binlog 的位置;后续的所有变更都能通过实时增量的方式同步到下游 TiDB 集群。

1赞

把DM同步时候 开启BINLOG本地持久化