maria-developers team mailing list archive
Mailing list archive
Re: A problem of DDL apply in parallel replication
"nanyi607rao" <nanyi607rao@xxxxxxxxx> writes:
> Maybe you have encountered this problem and fixed it, that is a DDL
> statement Query event has a Gtid event ahead, but has no end_event (like
> xid_event, commit or rollback) behind. so in the latest codes of parallel
> replication, count_queued_event_groups will increase but
> count_committing_event_groups will not for DDL. it would lead next
> event_group wait forever I guess.
Hm, the way it is supposed to work is this:
A DDL like CREATE TABLE is logged as two events:
1. A GTID_EVENT with the FL_STANDALONE flag set
2. A QUERY_EVENT with the CREATE TABLE statement
(no end event, as you wrote. The FL_STANDALONE flag in the GTID_EVENT is used
to handle the case where there is a GTID event but no end event).
In handle_rpl_parallel_thread(), group_standalone will be true because the
FL_STANDALONE flag is set. Then end_of_group will also be true, because of
(group_standalone && !Log_event::is_part_of_group(event_type))
(is_part_of_group() is false for a QUERY_EVENT).
Then the code will call into finish_event_group() which calls
rgi->mark_start_commit_no_lock(), which does
So as far as I can see, things should work correctly also for DDL. Does this
make things clearer for you? Or is there some problem with the code that I
missed in the above explanation?