Bug #106182 when excute reset master ,the gtid may wrong

• Submitted: 17 Jan 2022 2:56
• Modified: 17 Jan 2022 13:54
• Reporter: yunlei xu
• Status: Unsupported
• Category: MySQL Server
• Severity: S3 (Non-critical)
• Version: 5.7.23
• OS: Any
• CPU Architecture: Any

[17 Jan 2022 2:56] yunlei xu

Description:
when i excute reset master command ,the gtid may have a wrong value
like this 
+----------------------------------+----------+--------------+------------------+------------------------------------------+
| File                             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+----------------------------------+----------+--------------+------------------+------------------------------------------+
| yunleixudeMacBook-Pro-bin.000001 |     2751 |              |                  | 702a3b9e-737f-11ec-97ed-44f0e6b0bda2:8 |
+----------------------------------+----------+--------------+------------------+
------------------------------------------+

an then the next gtid will start from 1,like
702a3b9e-737f-11ec-97ed-44f0e6b0bda2:1-2:8

How to repeat:
sql1:
while true:
    insert into table ();

sql2:
reset master;

also can set breakpoints at binlog.cc
commit_stage:
  if (opt_binlog_order_commits &&
      (sync_error == 0 || binlog_error_action != ABORT_SERVER))

sql1:
insert into table ();
then trigger the breakpoint

sql2:
reset master;

continue the program

Suggested fix:
when i debug the program,i found the problem may be here

first：
global_sid_lock->rdlock();  //when excute thie ,reset master finished，now the gtid queue was null，but sql1‘s gtid not yet be persisted，and the session hold
the gno=8

then：
update_gtids_impl_own_gtid(thd,is_commit);   // sql1's gtid persisted，gno=8
}

rpl_gtid_state.cc
voidGtid_state::update_commit_group(THD*first_thd)
{
DBUG_ENTER("Gtid_state::update_commit_group");

/*
Wearegoingtoloopinallsessionsofthegroupcommitinordertoavoid
beingtakingandreleasingtheglobal_sid_lockandsidno_lockforeach
session.
*/
DEBUG_SYNC(first_thd,"update_gtid_state_before_global_sid_lock");
global_sid_lock->rdlock();  //when excute thie ,reset master finished，but gtid not yet be persisted
DEBUG_SYNC(first_thd,"update_gtid_state_after_global_sid_lock");

update_gtids_impl_lock_sidnos(first_thd);

for(THD*thd=first_thd;thd!=NULL;thd=thd->next_to_commit)
{
boolis_commit=(thd->commit_error!=THD::CE_COMMIT_ERROR);

if(update_gtids_impl_do_nothing(thd)||
(!is_commit&&update_gtids_impl_check_skip_gtid_rollback(thd)))
continue;

boolmore_trx_with_same_gtid_next=update_gtids_impl_begin(thd);

if(thd->owned_gtid.sidno==THD::OWNED_SIDNO_GTID_2022/1/13SET)
{
update_gtids_impl_own_gtid_set(thd,is_commit);
}
elseif(thd->owned_gtid.sidno>0)
{
update_gtids_impl_own_gtid(thd,is_commit);   // gtid 持久化，gno=8
}
elseif(thd->owned_gtid.sidno==THD::OWNED_SIDNO_ANONYMOUS)
{
update_gtids_impl_own_anonymous(thd,&more_trx_with_same_gtid_next);
}
else
{
update_gtids_impl_own_nothing(thd);
}

update_gtids_impl_end(thd,more_trx_with_same_gtid_next);
}

update_gtids_impl_broadcast_and_unlock_sidnos();

global_sid_lock->unlock();

DBUG_VOID_RETURN;
}

[17 Jan 2022 13:54] MySQL Verification Team

Hi Mr. xu,

Thank you for your bug report.

However, we must note that you are using an ancient 5.7 release, which is not supported any more.

Hence, try using 5.7.36. We have also tried to reproduce your test case, but it works just fine on 5.7.36 and macOS Monterey.

Unsupported.