dm集群开启 enable-gtid

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】DMV1.0.6

【问题描述】生产环境的DM在部署的时候没有开启enable-gtid,昨晚想通过以下方法开启该参数:
vi ~/dm-ansible/inventory.ini
新增参数
enable_gtid=true

滚动升级
ansible-playbook rolling_update.yml --tags=dm-worker

执行滚动升级后发现dm-worker报错了

问题:
1、这种情况是否先停止dm-worker,然后修改relay.meta文件里面的gtid,接着再重启dm-worker可以解决?
2、上游mysql的gtid一直是变化的,如何确定relay.meta的gtid信息?

谢谢!!


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

理论上没问题。先停,修改 relay.meta,在启动。

可以看下 relay_log 中的 binlog 信息,从最后一个位点的 gtid 开始拉取上游 binlog

应该是需要这个点位的gtid,是通过解析binlog文件来获取gtid吗?

查到的gtid是 435ff17c-aa51-11ea-8ff5-fa71fe870b00:131422276 ,那么在relay.meta中,gtid是填写
435ff17c-aa51-11ea-8ff5-fa71fe870b00:131422276 还是填写 435ff17c-aa51-11ea-8ff5-fa71fe870b00:1-131422276

以上的问题无需回复,这边已经验证好了。

最后一个关键的问题:
如果以前dm部署没有开启gtid,现在需要开启,是否有不报错就可以开启的方法?
按照上面的方法,处理起来不是特别方便。

抱歉,我看了下 1.0 这块暂时没有相关文档,您这边如果有测试环境的话,可以测试下以下方式
先停掉 dm-worker
1.修改 inventory
2.执行 deploy 操作推送配置到部署节点
3.修改 relay.meta 中的 gtid
4.启动 dm-worker 然后看下是否正常。

好的,找个机会试一下,多谢

:ok_hand::ok_hand:

最后一步不是启动worker,而是要滚动升级,否则conf配置中的gtid还是false,其他问题不大。
ansible-playbook start.yml --tags=dm-worker -l dm-worker1

mark一下。

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