Bug #113489 gtid_executed table lost the last binlog gtids
Submitted: 22 Dec 2023 7:43 Modified: 4 Jan 2024 3:36
Reporter: xuty Lucky Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.7.26 5.7.36 5.7.44 OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any

[22 Dec 2023 7:43] xuty Lucky
Description:
Slave has more GTIDs than the master has, using the master's SERVER_UUID.

master lost the last binlog gtids.

when mysql recover starting be killed,mysql maybe create a new binlog,but have not write old binlog gtids into mysql.gtid_executed.

How to repeat:
mysql5.7.26

1、reset master

2、write one transaction,it will create a GTID in mysql-bin.000001 like 3916952c-2ab8-11ee-bf30-56ad0febcbe3:1

3、kill -9 mysqld

4、start mysqld with gdb with a break on Gtid_state::save(mysqld.cc:4870)

5、kill -9 mysqld again

6、service mysqld start(normal start)

7、write again, you will found the current gtid is not 3916952c-2ab8-11ee-bf30-56ad0febcbe3:2,but still 3916952c-2ab8-11ee-bf30-56ad0febcbe3:1, mysql already lost the gtids in mysql-bin.000001

|main
 |mysqld_main
  |open_binlog        #mysqld.cc:4282 
                                         <-kill -9 mysqld
  |Gtid_state::save   #mysqld.cc:4870
[25 Dec 2023 15:05] MySQL Verification Team
Hi,

While this is rather impossible scenario (you need to kill/crash in a very specific way twice) even then I cannot reproduce this with 5.7.44. Your test case is on 5.7.26 that is rather old.
[4 Jan 2024 3:36] xuty Lucky
I already reproduce this with 5.7.44:

1、use kill -9 mysqlpid, as emulate mysql crash;

2、start mysql with gdb with a break on Gtid_state::save ,when mysql start break on Gtid_state::save function, use kill -9 mysqlpid, as emulate mysql crash again when it in savegtid process but not completed;

3、normal start mysql

4、mysql.gtid_executed table will lost last binlog gtids,it will cause mysql use repeat gtid in binlog and slave replication maybe sync error;