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 ??
However for the FLUSH LOGS DELETE DOMAIN …. I’m not so sure. 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. 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”. 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. 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