Kristian, Simon, hello. Replication side of FLUSH BINARY LOGS DELETE_DOMAIN_ID is actually bound to another requirement specified in early mails. The command is successful only *after* the user has run PURGE BINARY LOGS to 'the-first-log-free-of-old-domains' which is not replicated. Therefore in order to propagate the delete domain instruction we would have to involve into the feature a search for a first satisfactory log and purge. Earlier I fancied it would be syntactically PURGE [NO_WRITE_TO_BINLOG|LOCAL] BINARY LOGS DELETE_DOMAIN_ID=(list-of-domain-ids) with the FLUSH-like final piece of logics. Unlike the plain PURGE this one can be replicated. If we go this way, I also feel replicating behaviour would not be made by default. Apparently an opposite to NO_WRITE_TO_BINLOG|LOCAL would need introduction into parser; say DO_WRITE_TO_BINLOG|REPLICATE ? Now I am wondering what colleguas could say.. Cheers, Andrei
Hi Andrei,
On 25 Sep 2017, at 20:17, andrei.elkin@pp.inet.fi wrote:
...
the "vanilla" FLUSH-LOGS is not binlogged by decision commented in reload_acl_and_cache():
In the normal case I think it makes sense to not trigger another flush and to not binlog the command.
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 ??
Well, I should've spent one 1 (really) to understand them properly. Apparently mysqlbinlog --read-from-remote-server is meant and it's clear how the pipe is nirvana-like endless, indeed :-).
However for the FLUSH LOGS DELETE DOMAIN …. I’m not so sure.
You are directing to the point. Unlike the plain FLUSH BINARY LOGS the DELETE-DOMAIN one does not have to rotate the logs in case the domains have been already deleted or missed altogether. Therefore the above pipe is not dangerous.
If you “forget" the domain on the upstream server what happens if there are downstream slaves? I think you’ll break replication if they disconnect from this box and try to reconnect. Their GTID information will no longer match. IMO and if I’ve understood correctly this is broken.
Proper usage of FLUSH-DELETE-DOMAIN was thought to require slaves replication position be past the deleted domain. This implies a sort of client> SELECT MASTER_GTID_WAIT() on each slave before FLUSH-DELETE-DOMAIN can be run on the master.
Please do not expect the DBA to fix this manually. I have lots of places of multi-tier hierarchies and I do not want to touch anything downstream of a master I push changes into.
“It should just work”.
This is understood. Now that the new FLUSH-DELETE-DOMAIN is loop-free I don't have any doubt on its replication anymore.
If FLUSH LOGS should not be binlogged for the reasons stated do not overload this command with something which behaves differently. Use a different command, which you can BINLOG and which won’t trigger confusion.
Well, even a new command would rotate binlog so being loop-prone. (But we don't have to make any 2nd FLUSH-DELETE-DOMAIN to rotate, as said above).
The signal in the binlogs of the fact you’re removing “old domains” is _needed_ by downstream slaves to ensure that they “lose” these domains at the same point in time binlog-wise and thus keep in sync. That’s important.
Simon
Thanks for your response. I am going to exempt FLUSH-BINARY-LOGS from replication ban when it's run with the new DELETE_DOMAIN_ID=(list-of-domain-ids) option^\footnote{akin to {DO,IGNORE}_DOMAIN_IDS of CHANGE-MASTER}. Ineffective DELETE_DOMAIN_ID (e.g for a domain that is not in the gtid binlog state) won't cause rotation (the plain FLUSH-BINARY-LOGS part is not run).
Existing NO_WRITE_TO_BINLOG|LOCAL options will *actually* control FLUSH-DELETE-DOMAIN replication.
I hope this is satisfactory to everybody now.
Cheers,
Andrei