【 TiDB 使用环境】生产环境
【 TiDB 版本】6.51
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
原数据源之前没有开启GTID，开启之后，重新配置数据源开启GTID之后就报错了
我这边的操作是先停掉当前数据源上面的所有任务，然后销毁数据源，修改数据源配置之后再重启数据源，再启动任务
看报错是说GTID编码异常
这里得看你上游开启GTID的步骤了，看一下那一串全是0的GTID是怎么产生的。
MySQL在开启GTID时候，需要有3个阶段，其中两个阶段貌似是兼容模式，可能产生的GTID格式不正常。（你可以使用mysqlbinlog解析一下上游MySQL的binlog，看GTID到底是什么）
我建议是DM先不开启GTID，等过了变更GTID的这个时间段，再改为GTID模式
1 个赞
我现在操作了在syncer_checkpoint中的gtid栏位置空之后再重新启动任务，现在没有报这种错误，但是这种行为会不会导致数据不准？
你这串-000 的gtid怎么产生的，神奇啊
是不是 产生的GTID格式不正常？用mysqlbinlog解析一下binlog看GTID到底是什么？
产生的GTID格式不正常吧
GTID编码异常
神奇了，这一串0
插个眼看看
任务正常同步，现实源发生主从切换，原来是主数据源，切换到备数据源，在停掉任务，关闭数据源，修改数据源配置，开启GTID，在开启任务，就生成了
怀疑是默认值
因为一开始是没有开启的，所以 checkpoint 是没有 GTID 的；
后续开启之后，由于 checkpoint 还没更新，取到的值就是默认值（空），所以就都是 0 了
1 个赞
建议，可以去查看下日志，看看到底啥导致的报错
有的，你说的这种方式我这边也是操作的，还是会报这种错误
目前解决方案还是先把dm_meta库中对应任务的sync表，把里面的GTID的栏位置空，在开启任务就可以了
1 个赞
这个确实奇怪。到sync阶段了。哪位大佬遇到过。要我就试试看看能不能跳过去了。 