Hello. I've completed with the patch which passes few tests. However I had to make one concession with regard to replication. Actually..
So I see the DELETE DOMAIN (MariaDB) or “remove old UUID” (MySQL) type request to be one that means the master will only pretend that it can serve or knows about the remaining domains or UUIDs and if the slaves are sufficiently up to date they really don’t care as their vision will be similar. Such a command would be replicated, right? It has to be for the slaves to change “their view” at the same moment in replication (not necessarily time) as the master.
Hm, good point about whether it will be replicated.
FLUSH LOGS is replicated by default with an option not to, so a DELETE DOMAIN would be also, I suppose. This makes it seem even more
the "vanilla" FLUSH-LOGS is not binlogged by decision commented in reload_acl_and_cache(): if (options & REFRESH_BINARY_LOG) { /* Writing this command to the binlog may result in infinite loops when doing mysqlbinlog|mysql, and anyway it does not really make sense to log it automatically (would cause more trouble to users than it would help them) */ tmp_write_to_binlog= 0; ... I read them in a way how
dangerous,
Kristian estimates.
frankly. Imagine an active domain being deleted by mistake
So the point is to have a slave that is not affected and can rectify (e.g with fail-over to it as promoted Master)?
, now the mistake immediately propagates to all servers in the replication topology, ouch.
Maybe there should be an option, for example
FLUSH BINARY LOGS DELETE DOMAIN 10 NOCHECK
or
FLUSH BINARY LOGS DELETE DOMAIN 10 ALLOW ACTIVE
Something like this and also the choice between 'NOCHECK' and 'ALLOW ACTIVE' would be mandatory, that is no replication default for 'DELETE DOMAIN'. So the user first weighs how much risky it would be replicate.
I would to step back from this. The new option does not change the nature of FLUSH BINARY LOGS so the threat comments remain. Also considering that all this measure makes sense only to master, its rush accomplishment on a slave until its promotion to master does not seem necessary. So I would take a simpler originally considered no-replication route. In case the replication requirement will receive more support, we might consider to turn the feature's syntax into something different \footnote{% Consider an "exotic" form of it SET @@global.gtid_binlog_state = "-domain_1,domain_2,..." where '-' hints for decrements}. Yet I think we'll stay with FLUSH BINARY LOGS which I despite some trying could not find any better (The SET I liked though :-)). Cheers, Andrei