Re: [Maria-developers] Comments for parallel replication patch (MDEV-4506)
Michael Widenius <michael.widenius@gmail.com> 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.
participants (1)
-
Kristian Nielsen