maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

Hello.

I've completed with the patch which passes few tests.

However I had to make one concession with regard to replication.
Actually..

>>> So I see the DELETE DOMAIN (MariaDB) or “remove old UUID” (MySQL)
>>> type request
>>> to be one that means the master will only pretend that it can serve
>>> or knows about
>>> the remaining domains or UUIDs and if the slaves are sufficiently
>>> up to date they
>>> really don’t care as their vision will be similar.  Such a command
>>> would be replicated,
>>> right? It has to be for the slaves to change “their view” at the
>>> same moment
>>> in replication (not necessarily time) as the master.
>>
>> Hm, good point about whether it will be replicated.
>>
>> FLUSH LOGS is replicated by default with an option not to, so a
>> DELETE
>> DOMAIN would be also, I suppose. This makes it seem even more

the "vanilla" FLUSH-LOGS is not binlogged by decision commented in
reload_acl_and_cache():

  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

>> dangerous,

Kristian estimates.


>> frankly. Imagine an active domain being deleted by mistake
>
> So the point is to have a slave that is not affected and can rectify
> (e.g with fail-over to it as promoted Master)?
>
>>, now the mistake
>> immediately propagates to all servers in the replication topology, ouch.
>>
>> Maybe there should be an option, for example
>>
>>   FLUSH BINARY LOGS DELETE DOMAIN 10 NOCHECK
>>
>> or
>>
>>   FLUSH BINARY LOGS DELETE DOMAIN 10 ALLOW ACTIVE
>
> Something like this and also the choice between 'NOCHECK' and 'ALLOW
> ACTIVE' would be mandatory, that is no replication default for 'DELETE
> DOMAIN'.
> So the user first weighs how much risky it would be replicate.

I would to step back from this. The new option does not change
the nature of
   FLUSH BINARY LOGS
so the threat comments remain.
Also considering that all this measure makes sense only to master, its
rush accomplishment on a slave until its promotion to master does not
seem necessary.

So I would take a simpler originally considered no-replication route.

In case the replication requirement will receive more support, we might
consider to turn the feature's syntax into something different \footnote{%
Consider an "exotic" form of it

  SET @@global.gtid_binlog_state = "-domain_1,domain_2,..."

where '-' hints for decrements}.

Yet I think we'll stay with FLUSH BINARY LOGS which I despite some
trying could not find any better (The SET I liked though :-)).


Cheers,

Andrei