Movatterモバイル変換

START REPLICA andSTOP REPLICA take effect immediately and ignore any delay.RESET REPLICA resets the delay to 0.

• To protect against user mistakes on the source. With a delay you can roll back a delayed replica to the time just before the mistake.

• To test how the system behaves when there is a lag. For example, in an application, a lag might be caused by a heavy load on the replica. However, it can be difficult to generate this load level. Delayed replication can simulate the lag without having to simulate the load. It can also be used to debug conditions related to a lagging replica.

• To inspect what the database looked like in the past, without having to reload a backup. For example, by configuring a replica with a delay of one week, if you then need to see what the database looked like before the last few days' worth of development, the delayed replica can be inspected.

MySQL 8.4 provides a new method for measuring delay (also referred to as replication lag) in replication topologies that depends on the following timestamps associated with the GTID of each transaction (instead of each event) written to the binary log.

The output ofmysqlbinlog displays these timestamps in two formats, microseconds from epoch and alsoTIMESTAMP format, which is based on the user defined time zone for better readability. For example:

#170404 10:48:05 server id 1  end_log_pos 233 CRC32 0x016ce647     GTID    last_committed=0\ sequence_number=1    original_committed_timestamp=1491299285661130    immediate_commit_timestamp=1491299285843771# original_commit_timestamp=1491299285661130 (2017-04-04 10:48:05.661130 WEST)# immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST) /*!80001 SET @@SESSION.original_commit_timestamp=1491299285661130*//*!*/;   SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;# at 233

As a rule, theoriginal_commit_timestamp is always the same on all replicas where the transaction is applied. In source-replica replication, theoriginal_commit_timestamp of a transaction in the (original) source’s binary log is always the same as itsimmediate_commit_timestamp. In the replica’s relay log, theoriginal_commit_timestamp andimmediate_commit_timestamp of the transaction are the same as in the source’s binary log; whereas in its own binary log, the transaction’simmediate_commit_timestamp corresponds to when the replica committed the transaction.

In a Group Replication setup, when the original source is a member of a group, theoriginal_commit_timestamp is generated when the transaction is ready to be committed. In other words, when it finished executing on the original source and its write set is ready to be sent to all members of the group for certification. When the original source is a server outside the group, theoriginal_commit_timestamp is preserved. The sameoriginal_commit_timestamp for a particular transaction is replicated to all servers in the group, and to any replica outside the group that is replicating from a member. Each recipient of the transaction also stores the local commit time in its binary log usingimmediate_commit_timestamp.

View change events, which are exclusive to Group Replication, are a special case. Transactions containing these events are generated by each group member but share the same GTID (so, they are not first executed in a source and then replicated to the group, but all members of the group execute and apply the same transaction). Group members set local timestamp values for transactions associated with view change events.

One of the most common ways to monitor replication delay (lag) in previous MySQL versions was by relying on theSeconds_Behind_Master field in the output ofSHOW REPLICA STATUS. However, this metric is not suitable when using replication topologies more complex than the traditional source-replica setup, such as Group Replication. The addition ofimmediate_commit_timestamp andoriginal_commit_timestamp to MySQL 8 provides a much finer degree of information about replication delay. The recommended method to monitor replication delay in a topology that supports these timestamps is using the following Performance Schema tables.

Using these tables you can monitor information about the last transaction the corresponding thread processed and the transaction that thread is currently processing. This information comprises:

In addition to the Performance Schema tables, the output ofSHOW REPLICA STATUS has three fields that show:

When the replication SQL thread is waiting for the delay to elapse before executing an event,SHOW PROCESSLIST displays itsState value asWaiting until SOURCE_DELAY seconds after master executed event.