maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Andrei Elkin <andrei.elkin@xxxxxxxxxxx> writes:

> Kristian, salve!

Hi Andrei, thanks for interesting comments and discussion!

>> 3. To solve (2), we recover the old master with
>> --tc-heuristic-recover=rollback. This makes it rollback (=discard) any
>> transaction that was not fully committed to disk (does it also roll back the
>> binary log for such transactions? I don't recall this detail).
>>
>> 4. Because of (3), there might be a transaction that originated on the old
>> master (has it's server_id), but which is now missing from that server (now
>> a slave) as it was deliberately discarded.
>>
>> 5. To solve (4), we will use circular replication
>
> Well, the circularity is not necessary for (4). The ex-master just needs
> to be configured as slave.

Right, I see now.

> Also let me call in the following this stage of receiving/accepting own
> events as 'slave recovery'.

But thinking more, there's another point that I don't understand, around the
use of --tc-heuristic-recover=rollback. From memory, and also from reading
docs on https://mariadb.com/kb/en/heuristic-recovery-with-the-transaction-coordinator-log/,
this will forcibly roll back any prepared-but-not-committed InnoDB
transaction, but _not_ roll back any corresponding binlog entry.

Doesn't this leave the binlog inconsistent with the storage engine? Of the
last few transactions in the binlog, some may be in InnoDB, some may not.

And if so, doesn't this make the binlog useless for deciding which of our
own transactions to ignore? When the old-master-now-slave gets one of its
own events that's also in the binlog, we don't know if it is in the engine.
If we apply it, we may end up with it double. If we do not apply it, we may
be missing it.

Is there some mechanims used in this feature/MDEV that handles this
correctly that I'm missing?

>> So isn't there a better way to achieve the underlying use case? For example,
>> why not just use the new MASTER_DEMOTE_TO_SLAVE option to set the correct
>> slave position from which to replicate from in the old master (now
>> slave)?
>
> That's how it should normally do, yet it's an optimization (to save on
> traffic) part of the solution.

Interesting. Can you elaborate on this optimization - how does it save on
traffic?

> In the worst case `gtid_slave_pos` can be even empty for the
> ex-master's domain, so the ex-master slave might keep receiving a bulk
> of own events, only to ignore the most of them.
> And that's the patch's base code logics as well.

I guess there's something here that I'm not understanding. If
MASTER_DEMOTE_TO_SLAVE is used to copy the gtid_binlog_pos into the
gtid_slave_pos, how can the gtid_slave_pos be empty for the ex-master's
domain?

> ... , `gtid_ignore_duplicate = OFF` would have to go in my perception.
> And if it goes, we'd remain with the only "choice" of
> `gtid_ignore_duplicate = ON` :-) so the option would be gone.

Hm. So are you suggesting that the current behaviour when
--gtid-ignore-duplicates=ON becomes the default behaviour - in fact the only
behaviour?

As I remember it, the --gtid-ignore-duplicates=ON option is a very dangerous
option unless the servers are managed very strictly and correctly. In fact I
was expecting to find a dire warning written by myself about this, but
didn't find anything in a quick web search ;-)

I think the main problem is if an incorrect transaction done on a slave
somewhere introduces an out-of-order GTID sequence, Then the replication
will silently ignore potentially a large number of transactions that have
their sequence number smaller than the incorrect out-of-order transaction.

Out-of-order will normally be an error. But mistakes happen, and it is bad
if this causes replication to become silently corrupt, as opposed to
flagging the error (assuming --gtid-strict-mode=ON).

What do you think?

Again, it's cool that things are being worked on in MariaDB GTID, and I hope
my comments don't come out as purely negative. While MariaDB/MySQL
replication is in some ways overly complex, this is also what gives it the
enormous flexibility for advanced users to do crazy^H^H^H^H^Hfantastic
stuff! So there's some leeway for allowing complexity. But there are also
some very delicate pitfalls that the original design tried hard to avoid,
with decisions that may not always be obvious. So anything I can do there to
help with history and design principles, I'm happy to assist with...

 - Kristian.