Bug #72247 reset gtid_executed on a replica set without the need of "reset master"
Submitted: 4 Apr 2014 22:40 Modified: 5 Apr 2014 4:43
Reporter: Santosh Praneeth Banda Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.6.16 OS:Any
Assigned to: CPU Architecture:Any

[4 Apr 2014 22:40] Santosh Praneeth Banda 
Description:
Currently gtid_executed set can become very large after lots of dead master promotions. It would be a great feature to reset the gtid_executed on all the servers in a replica set without the need of "reset master". And this feature shouldn't break replication or cause any downtime.

How to repeat:
see description

Suggested fix:
command like 'reset gtid_executed' should be provided. This will be executed on master and logged to binary log and received by all the slaves. On seeing this event slaves must reset their own gtid_executed set.
[4 Apr 2014 22:41] Santosh Praneeth Banda 
This is more than a feature request actually.
[5 Apr 2014 4:43] MySQL Verification Team 
Hello Santosh,

Thank you for the feature request!

Thanks,
Umesh
[12 Sep 2014 2:55] Ben Krug 
Output of SHOW MASTER STATUS and SHOW SLAVE STATUS can get unwieldy over time as the list of executed GTIDs grows and grows.  Using RESET MASTER involves a number of possibly unwanted other effects.  It would be good to have a less intrusive way to trim this list.
[18 Aug 2016 16:37] Chrs Riccomini 
This seems to be a required feature when running multi-source replication in 5.7. Once you start replication for one channel, if you try to load a new DB from a mysqldump file from another master, you can't set the GTID for the new channel because the gtid_executed has already been set by the ongoing replication. This basically makes multi-source replication useless if you ever need to add a new channel after existing channels have been running.

Having the ability to reset gtid_executed would allow us to stop replication, clear the gtid_executed, load the new DB dump, reset the gtid_purged/gtid_executed variables (including the new GTID for the new slave channel), then start replication again.

We don't want to use RESET master because it nukes the slave's binlogs. We have consumers for the slave's binlogs, and deleting them will break the downstream consumers.