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

🛸 其他技术问题
1

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 个赞
2

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

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

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

2 个赞
3

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

2 个赞
4

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

2 个赞
5

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

2 个赞
6

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

1 个赞
7

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

1 个赞
8

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

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

问题1： 我怎么查看， 上游 MySQL 已开启 GTID 模式？
问题2： 我怎么查看， 上游存在主从自动切换？
1 个赞
10

查看 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 个赞
11

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

1 个赞
12

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

1 个赞
13

是不是丢日志了？

14

你源端是什么库？

15

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

1 个赞
16

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

17

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