"nanyi607rao" <nanyi607rao@gmail.com> 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 this condition: (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 ++e->count_committing_event_groups. 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? Thanks, - Kristian.