maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

Simon, hello.

> Hi Andrei,
>
>> On 25 Sep 2017, at 20:17, andrei.elkin@xxxxxxxxxx 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