MySQL 8.0 FAQ: Replication When the replication SQL thread executes an event read from the source, it modifies its own time to the event timestamp. (This is why  TIMESTAMP  is well replicated.) In the  Time  column in the output of  SHOW PROCESSLIST , the number of seconds displayed for the replication SQL thread is the number of seconds between the timestamp of the last replicated event and the real time of the replica machine. You can use this to determine the date of the last replicated event. Note that if your replica has been disconnected from the source for one hour, and then reconnects, you may immediately see large  Time  values such as 3600 for the replication SQL thread in  SHOW PROCESSLIST . This is because the replica is executing statements that are one hour old. See Section 17.2.3, “Replication Threads” . Use the following procedure: mysql>  FLUSH TABLES WITH READ LOCK; mysql>  SHOW MASTER STATUS; Record the replication coordinates (the current binary log file name and position) from the output of the  SHOW  statement. mysql>  SELECT MASTER_POS_WAIT(’ log_name ’,  log_pos ); The  SELECT  statement blocks until the replica reaches the specified log file and position. At that point, the replica is in synchrony with the source and the statement returns. mysql>  UNLOCK TABLES; MySQL replication currently does not support any locking protocol between source and replica to guarantee the atomicity of a distributed (cross-server) update. In other words, it is possible for client A to make an update to co-source 1, and in the meantime, before it propagates to co-source 2, client B could make an update to co-source 2 that makes the update of client A work differently than it did on co-source 1. Thus, when the update of client A makes it to co-source 2, it produces tables that are different from what you have on co-source 1, even after all the updates from co-source 2 have also propagated. This means that you should not chain two servers together in a two-way replication relationship unless you are sure that your updates can safely happen in any order, or unless you take care of mis-ordered updates somehow in the client code. You should also realize that two-way replication actually does not improve performance very much (if at all) as far as updates are concerned. Each server must do the same number of updates, just as you would have a single server do. The only difference is that there is a little less lock contention because the updates originating on another server are serialized in one replication thread. Even this benefit might be offset by network delays. 5271 A.14.6. How can I use replication to improve performance of my system? A.14.5. What issues should I be aware of when setting up two-way replication? 3. On the source, issue the following statement to enable the source to begin processing updates again: 2. On the replica, issue the following statement, where the arguments to the MASTER_POS_WAIT()  function are the replication coordinate values obtained in the previous step: 1. On the source, execute these statements: A.14.4. How do I force the source to block updates until the replica catches up?