content_image/780780.jpg content_image/780790.jpg content_image/780794.jpg
<img src='content_image/780780.jpg'>

## 13.4.2.4 MASTER_POS_WAIT() Statement 

SELECT MASTER_POS_WAIT(’ source_log_file ’, source_log_pos  [, timeout ][, channel ]) 

This is actually a function, not a statement. It is used to ensure that the replica has read and executed events up to a given position in the source’s binary log. See Section 12.24, “Miscellaneous Functions” , for a full description. 

## 13.4.2.5 RESET REPLICA | SLAVE Statement 

RESET {REPLICA | SLAVE} [ALL] [ channel_option ] channel_option : FOR CHANNEL channel 

RESET REPLICA | SLAVE  makes the replica forget its position in the source’s binary log. From MySQL 8.0.22, use RESET REPLICA  in place of RESET SLAVE , which is deprecated from that release. In releases before MySQL 8.0.22, use RESET SLAVE . 

This statement is meant to be used for a clean start; it clears the replication metadata repositories, deletes all the relay log files, and starts a new relay log file. It also resets to 0 the replication delay specified with the SOURCE_DELAY  | MASTER_DELAY  option of the CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or CHANGE MASTER TO  statement (before MySQL 8.0.23). 

<img src='content_image/780790.jpg'>

<img src='content_image/780794.jpg'>

## Note 

All relay log files are deleted, even if they have not been completely executed by the replication SQL thread. (This is a condition likely to exist on a replica if you have issued a STOP REPLICA | SLAVE  statement or if the replica is highly loaded.) 

For a server where GTIDs are in use ( gtid_mode  is ON ), issuing RESET REPLICA | SLAVE  has no effect on the GTID execution history. The statement does not change the values of gtid_executed  or gtid_purged , or the mysql.gtid_executed  table. If you need to reset the GTID execution history, use RESET MASTER , even if the GTID-enabled server is a replica where binary logging is disabled. 

RESET REPLICA | SLAVE  requires the RELOAD  privilege. 

