SQL Statements for Controlling Replica Servers For more information, see Section 6.2.17, “Pluggable Authentication” . If an insecure connection is used with any these options, the server issues the warning  Sending passwords in plain text without SSL/TLS is extremely insecure . START REPLICA | SLAVE ... UNTIL  supports two additional options for use with global transaction identifiers (GTIDs) (see Section 17.1.3, “Replication with Global Transaction Identifiers” ). Each of these takes a set of one or more global transaction identifiers  gtid_set  as an argument (see GTID Sets, for more information). When no  thread_type  is specified,  START REPLICA | SLAVE UNTIL SQL_BEFORE_GTIDS  causes the replication SQL thread to process transactions until it has reached the  first  transaction whose GTID is listed in the  gtid_set .  START REPLICA | SLAVE UNTIL SQL_AFTER_GTIDS  causes the replication threads to process all transactions until the  last  transaction in the  gtid_set  has been processed by both threads. In other words,  START REPLICA | SLAVE UNTIL SQL_BEFORE_GTIDS  causes the replication SQL thread to process all transactions occurring before the first GTID in the  gtid_set  is reached, and  START REPLICA | SLAVE UNTIL SQL_AFTER_GTIDS  causes the replication threads to handle all transactions, including those whose GTIDs are found in  gtid_set , until each has encountered a transaction whose GTID is not part of the set.  SQL_BEFORE_GTIDS  and  SQL_AFTER_GTIDS  each support the  SQL_THREAD  and  IO_THREAD  options, although using  IO_THREAD  with them currently has no effect. For example,  START REPLICA | SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56  causes the replication SQL thread to process all transactions originating from the source whose  server_uuid  is  3E11FA47-71CA-11E1-9E33- C80AA9429562  until it encounters the transaction having sequence number 11; it then stops without processing this transaction. In other words, all transactions up to and including the transaction with sequence number 10 are processed. Executing  START REPLICA | SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 , on the other hand, would cause the replication SQL thread to obtain all transactions just mentioned from the source, including all of the transactions having the sequence numbers 11 through 56, and then to stop without processing any additional transactions; that is, the transaction having sequence number 56 would be the last transaction fetched by the replication SQL thread. When using a multithreaded replica with  slave_preserve_commit_order=0  set, there is a chance of gaps in the sequence of transactions that have been executed from the relay log in the following cases: Use the  START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS  statement to cause a multithreaded replica’s worker threads to only run until no more gaps are found in the relay log, and then to stop. This statement can take an  SQL_THREAD  option, but the effects of the statement remain unchanged. It has no effect on the replication I/O thread (and cannot be used with the  IO_THREAD  option). Issuing  START REPLICA | SLAVE  on a multithreaded replica with gaps in the sequence of transactions executed from the relay log generates a warning. In such a situation, the solution is to use  START REPLICA | SLAVE UNTIL SQL_AFTER_MTS_GAPS , then issue  RESET REPLICA | SLAVE  to remove any remaining relay logs. See Section 17.5.1.34, “Replication and Transaction Inconsistencies”  for more information. To change a failed multithreaded replica to single-threaded mode, you can issue the following series of statements, in the order shown: 2777 •killing the coordinator thread •after an error occurs in the applier threads • mysqld  shuts down unexpectedly