maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Michael Widenius <michael.widenius@xxxxxxxxx> writes:

>> What about Rotate_log_event::do_update_pos() and
>> Stop_log_event::do_update_pos()?
>>
>> They currently access the flag in rli. I am not sure that is right, as
> this
>> could be far ahead of the event they are actually executing?
>
> Aren't the above events handled by the sql driver thread?

No, by the worker threads. I do not understand how it could be done in the
driver thread? do_update_pos updates the current position of the last event
executed, it cannot happen until after events have been executed? And this
happens in the worker threads.

> My thought was that the driver thread was in charge of all reading of the
> relay log and would thus hide any stop or rotate events from the sql
> execution threads.

The Rotate event is what updates the group_master_log_name to the name of the
next binlog file on the master. This must not happen until previous events
have been executed (otherwise they will be wrongly skipped if we stop and
restart the slave).

Or did I misunderstand?

My best suggestion at the moment is to copy the required information from
m_flags (and a couple of other fields from rli) into rgi, so that the right
value gets associated with the right event in each worker thread. But let's
discuss when you are back from travelling if you have a better idea.

> The purgeing of log should be changed to check the position of the st
> committed event. It's safe to delay any older logs.

> The other I am not sure about as I can't look at the code just know.
> However we need a solution that works also for masters that don't support
> GTID.

Yes, the non-GTID case is the main problem. (Using GTID, everything is updated
automatically in parallel in the mysql.gtid_slave_pos and there is a sub_id
field that ensures we can figure out which GTIDs are the most recent ones).

 - Kristian.