MySQL Bugs: #71340: GTID 5.6.15 replication fails with master has purged binary logs

Bug #71340	GTID 5.6.15 replication fails with master has purged binary logs
Submitted:	10 Jan 2014 9:27	Modified:	21 Jan 2014 6:27
Reporter:	lalit Choudhary	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S1 (Critical)
Version:	5.6.15	OS:	Linux (any)
Assigned to:		CPU Architecture:	Any
Tags:	5.6 GTID, MySQL, replication

Description:
mysql 5.6.15 GTID replication 'Got fatal error 1236 from master when reading data from binary log'

I Checked SHOW SLAVE STATUS error is "'Got fatal error 1236 from master when reading data from binary log: ''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.''

i am suspecting it happens because of master old binary log (7 days before) deleted form master as we are using expire_logs_days=7 option and slave still looking for this old binary log for some GTID reference to replicate with master.

I tried following link solution ,

http://www.mysqlperformanceblog.com/2013/02/08/how-to-createrestore-a-slave-using-gtid-rep...

but it still not working.

Note :using mysql 5.6.15

How to repeat:
setup master  slave with  GTID based replication. delete old binary  logs  from master.

whenever  slave get  restarted  replication failed  with  error "'Got fatal error 1236 from master when reading data from binary log: ''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.''

Suggested fix:
only option to re-create new slave by taking mysqldump from master.

Hello Lalit,

Thank you for the report.
This is most likely a duplicate of Bug #71376
Do you use any *replicate-ignore-db* filters on slave?

Thanks,
Umesh

Yes , we have configured   replicate-ignore-db and replicate-do-db filters on slave.

Thank you for confirming, duplicate of Bug #71376