【TiDB 版本】：3.0.9
【DM版本】：v1.0.5 Git Commit Hash: a8e9f53f91e29756b09a22cdc37a6a6efcdfe55b
主要错误
code=30015:class=relay-unit:scope=upstream:level=high] TCPReader get relay event with error: ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires

根据提示和tidb官方论坛的反馈，主要原因是上游binlog获取不到，可能原因是binlog被清楚下面是部分错误图

官方论坛给的方法是：

• 停止 dm-worker
• 删除 relay-log 目录（则拉取 binlog 时会从 inventory 中记录的位点开始拉取）或者 修改 relay.meta 文件中的位点，从指定位点开始拉取上游 binlog
• 启动 dm-worker
  • 注意顺序，如操作顺序先修改 relay.meta，重启 dm-worker，该操作错误，原 gtid 信息会将 修改的 gtid 信息覆盖掉

但是此方法并不奏效，我上面错误图就是最新的binlog（mysql-bin.024355）和最pos(4)，用的最新的gitd
启动后还是30015

解决过程：

一次执行 query-status 突然看到masterBinlog 与 masterBinlogGtid
原图没有了，但是我记下了当时的pos和gitd（截取部分）
“relayStatus”: {
“masterBinlog”: “(mysql-bin.024408, 110936093)”,
“masterBinlogGtid”: “678e197a-f60e-11e9-94f9-b8599f37f3d0:1-264381,706de50e-075e-11ea-9909-7cd30adb2d50:1-100298,d2aee377-0e66-11ea-b85a-7cd30aeb1510:1-17598173755”
突发奇想，如果使用此位置开始同步会怎么样。于是我去查上游库的binlog

这样就对应上了，pos和gtid都在binlog找到了，但是tidb的masterBinlogGtid分为三部分（三个逗号，姑且认为3部分）：
678e197a-f60e-11e9-94f9-b8599f37f3d0:1-264381,
706de50e-075e-11ea-9909-7cd30adb2d50:1-100298,
d2aee377-0e66-11ea-b85a-7cd30aeb1510:1-17598173755
后两个好说，可以通过binlog获取到，第二行：把下面图100243改为 1 。
但是第一行一直是个固定值，不知道是哪里得到的，还得官方解答。

这样拉完整的binlog就好配置了，
下面是取值：

最终的relay.meta
“relayStatus”: {
“masterBinlog”: “(mysql-bin.024408, 904)”,
“masterBinlogGtid”: “678e197a-f60e-11e9-94f9-b8599f37f3d0:1-264381,706de50e-075e-11ea-9909-7cd30adb2d50:1-100298,d2aee377-0e66-11ea-b85a-7cd30aeb1510:1-17598026233”

这样binlog从024408拉，已经正常使用了。