上游RDS MySQL变更规格，下游DM同步出错

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

"result": {
                       "isCanceled": false,
                       "errors": [
                           {
                               "ErrCode": 36069,
                               "ErrClass": "sync-unit",
                               "ErrScope": "upstream",
                               "ErrLevel": "high",
                               "Message": "get binlog event error: ERROR 1236 (HY000): Client requested master to start replication from position \u003e file size",
                               "RawCause": "",
                               "Workaround": "Please check if the binlog file could be parsed by `mysqlbinlog`."
                           }
                       ],
                       "detail": null

上游变更完后，尝试了resume-task没有恢复。由于表不大，直接把任务给stop-task了，然后把TiDB里同步的表名rename table，重新start-task任务了，问题是这种基于GTID的为啥上游变更（规格，主从切换）会无法继续同步呢？

2

看一下上游的binlog还在不

3

Please check if the binlog file could be parsed by mysqlbinlog
看起来是binlog文件不存在

4

最快的方式是重新全量同步

5

需要安装文档进行操作
https://docs.pingcap.com/zh/tidb/v6.5/usage-scenario-master-slave-switch#切换-dm-worker-与上游-mysql-实例的连接

6

binlog没了吧

7

报错这不是说 binlog文件不存在了

8

RDS变更规格一般是自动新创建一个新规格的从库，等数据追平之后主从切换，然后销毁原主库，按上面链接里主从切换的场景来处理就行，实在不行就重新做一次同步。

9

binlog没了

10

我的理解是，既然是基于GTID，在重启任务时就应该能找到正确的GTID对应的Binlog文件，除非要拉取的gtid所在的binlog丢失

11

获取binlog失败，至于什么原因，不详了

12

没使用gtid方式，主从切换，那dm肯定要重建任务了指定binlog和pos值，GTID的话，主从切换，他根据gtid的值去找对应的binlog吧。但是binlog名字不一样了。除非主从binlog名字一样。

1 个赞
13

果然数据源里没有启用gtid

enable-gtid 是否使用 GTID 方式从上游拉取 binlog，默认值为 false。一般情况下不需要手动配置，如果上游数据库启用了 GTID 支持，且需要做主从切换，则将该配置项设置为 true。