maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

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@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