Bug #113489 gtid_executed table lost the last binlog gtids

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

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.

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；