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

[10 Jan 2014 9:27] lalit Choudhary
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.
[20 Jan 2014 17:08] MySQL Verification Team
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
[21 Jan 2014 6:14] lalit Choudhary
Yes , we have configured   replicate-ignore-db and replicate-do-db filters on slave.
[21 Jan 2014 6:24] MySQL Verification Team
Thank you for confirming, duplicate of Bug #71376

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.043 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.