Getting ERROR 1236 while trying to use GTID-based sync

[dobegor]

[2021/03/12 14:17:31] [info] dump.go:199 skip dump, use last binlog replication pos (, 0) or GTID set e50bd2d3-6ad7-11e9-890c-42010af0017c:1-5291126581,04dc7e08-cdb9-11ea-85e2-42010af000f0:1-529516242,6b72c712-568d-11eb-9376-4201c0a83018:1-262736262,884f7ff2-5f06-11e8-9c1f-42010af0016e:1-5801379409,946eb7a2-8009-11e6-858e-42010af0109b:1-3964676522
[2021/03/12 14:17:31] [info] binlogsyncer.go:378 begin to sync binlog from GTID set 884f7ff2-5f06-11e8-9c1f-42010af0016e:1-5801379409,946eb7a2-8009-11e6-858e-42010af0109b:1-3964676522,e50bd2d3-6ad7-11e9-890c-42010af0017c:1-5291126581,04dc7e08-cdb9-11ea-85e2-42010af000f0:1-529516242,6b72c712-568d-11eb-9376-4201c0a83018:1-262736262
[2021/03/12 14:17:31] [info] sync.go:33 start sync binlog at GTID set 946eb7a2-8009-11e6-858e-42010af0109b:1-3964676522,e50bd2d3-6ad7-11e9-890c-42010af0017c:1-5291126581,04dc7e08-cdb9-11ea-85e2-42010af000f0:1-529516242,6b72c712-568d-11eb-9376-4201c0a83018:1-262736262,884f7ff2-5f06-11e8-9c1f-42010af0016e:1-5801379409
[2021/03/12 14:17:31] [error] binlogstreamer.go:77 close sync with err: 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. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period. The GTID sets and the missing purged transactions are too long to print in this message. For more information, please see the master's error log or the manual for GTID_SUBTRACT.

GTID set that was passed: 884f7ff2-5f06-11e8-9c1f-42010af0016e:1-5801379409,946eb7a2-8009-11e6-858e-42010af0109b:1-3964676522,e50bd2d3-6ad7-11e9-890c-42010af0017c:1-5291126581,04dc7e08-cdb9-11ea-85e2-42010af000f0:1-529516242,6b72c712-568d-11eb-9376-4201c0a83018:1-262736262

mysql.gtid_executed table:

source_uuid	interval_start	interval_end
04dc7e08-cdb9-11ea-85e2-42010af000f0	1	529516242
6b72c712-568d-11eb-9376-4201c0a83018	1	263112632
884f7ff2-5f06-11e8-9c1f-42010af0016e	1	5801379409
946eb7a2-8009-11e6-858e-42010af0109b	1	3964676522
e50bd2d3-6ad7-11e9-890c-42010af0017c	1	5291126581
e50bd2d3-6ad7-11e9-890c-42010af0017c	5291126583	5323107666

Set was parsed using mysql.ParseGTIDSet and passed into StartFromGTID.
@siddontang I've only found one similar issue - #114 - and it seems that my case is not related?

[dobegor]

Forgot to mention that GTID set was saved after the first OnPosSynced received during the dump.

[dobegor]

I've edited GTID set manually (added the missing 5291126583-5323107666 interval) and replication successfully started. And more to that, OnPosSynced now receives correct GTID set:

04dc7e08-cdb9-11ea-85e2-42010af000f0:1-529516242,
6b72c712-568d-11eb-9376-4201c0a83018:1-262905290,
e50bd2d3-6ad7-11e9-890c-42010af0017c:1-5291126581:5291126583-5323107666,
884f7ff2-5f06-11e8-9c1f-42010af0016e:1-5801379409,
946eb7a2-8009-11e6-858e-42010af0109b:1-3964676522

It might be that GTID set gets incorrectly parsed during dump.

[dobegor]

Closed in #551.