Bad Sync Pattern for Chain Replication MTR Tests

Many MTR tests in the replication suite use chain replication, and many of these tests synchronize servers in a way that skips the middle server, assuming that if the last server becomes synchronized, we can assume the middle server is synchronized. E.g.

--source include/have_innodb.inc

--source include/have_binlog_format_row.inc

--let $rpl_topology=1->2, 2->3

--source include/rpl_init.inc

--echo #

--echo # Initialize test data

--connection server_1

insert into t1 values (1);

--source include/save_master_gtid.inc

--connection server_3

--source include/sync_with_master_gtid.inc

It is possible to progress passed this point while the middle server has not actually finished committing the transaction. It is possible for server_2 to have binlogged the transaction, but not yet commit in the storage engines (done in run_commit_ordered()). Then server 2's binlog dump thread can see the new transaction in the binary log, send it to server 3, and server 3 can execute it. Any operations done on server 2 at this point that rely on that transaction to have committed would then fail.

We should fix instances of this pattern in the MTR suite. We likely don't need to manually read through each file to fix such occurrences, but perhaps apply the following patch and run the rpl suite and see what fails:

diff --git a/sql/log.cc b/sql/log.cc

index 8e2e37a83fc..7aa39f9d46a 100644

--- a/sql/log.cc

+++ b/sql/log.cc

@@ -11087,6 +11087,8 @@ void MYSQL_BIN_LOG::trx_group_commit_with_engines(group_commit_entry *leader,

     DBUG_VOID_RETURN;

   }

+  my_sleep(500000); /* 0.5s */

+

   /*

     Wakeup each participant waiting for our group commit, first calling the

     commit_ordered() methods for any transactions doing 2-phase commit.