# 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, the original_commit_timestamp  is always the same on all replicas where the transaction is applied. In source-replica replication, the original_commit_timestamp  of a transaction in the (original) source’s binary log is always the same as its immediate_commit_timestamp . In the replica’s relay log, the original_commit_timestamp  and immediate_commit_timestamp  of the transaction are the same as in the source’s binary log; whereas in its own binary log, the transaction’s immediate_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, the original_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, the original_commit_timestamp  is preserved. The same original_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. From MySQL 8.0.26, each recipient of the transaction also stores the local commit time in its binary log using immediate_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). Before MySQL 8.0.26, these transactions have their original_commit_timestamp set to zero, and they appear this way in viewable output. From MySQL 8.0.26, for improved observability, group members set local timestamp values for transactions associated with view change events. 

## Monitoring Replication Delay 

One of the most common ways to monitor replication delay (lag) in previous MySQL versions was by relying on the Seconds_Behind_Master  field in the output of SHOW REPLICA | SLAVE 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 of immediate_commit_timestamp and original_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. 

• replication_connection_status : current status of the connection to the source, provides information on the last and current transaction the connection thread queued into the relay log. 

• replication_applier_status_by_coordinator : current status of the coordinator thread that only displays information when using a multithreaded replica, provides information on the last transaction buffered by the coordinator thread to a worker’s queue, as well as the transaction it is currently buffering. 

• replication_applier_status_by_worker : current status of the thread(s) applying transactions received from the source, provides information about the transactions applied by the replication SQL thread, or by each worker thread when using a multithreaded replica. 

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: 

•a transaction’s GTID 

•a transaction’s original_commit_timestamp  and immediate_commit_timestamp , retrieved from the replica’s relay log 

