Simon, hello.
> 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
> ??
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
_______________________________________________
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
