Hi Andrei,
> On 25 Sep 2017, at 20:17, andrei.el...@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
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
