Understanding MySQL 8.0 immediate_commit_timestamp and original_commit_timestamp in Binlog Replication

MySQL 8.0 adds two new timestamp fields to the binary log: immediate_commit_timestamp and original_commit_timestamp . The former records the commit time on the server where the transaction is applied, while the latter records the original commit time on the primary server; on the primary they are identical.

Both timestamps are generated during the flush phase when the binlog cache is written to the binlog file, i.e., when the GTID event is created. In Group Replication the primary’s timestamps may be slightly advanced by group_replication_trans_before_commit , which is not the true commit time.

The value of thd->variables.original_commit_timestamp is usually UNDEFINED_COMMIT_TIMESTAMP on the primary; when a replica applies a GTID event it replaces this with the primary’s original timestamp. When replicating from 5.7 to 8.0 the value may be 0, as shown:

# original_commit_timestamp=0 (1970-01-01 08:00:00.000000 CST)
# immediate_commit_timestamp=1703237689977004 (2023-12-22 17:34:49.977004 CST)

The timestamps are set in MYSQL_BIN_LOG::write_transaction roughly as:

immediate_commit_timestamp = current time
original_commit_timestamp = thd->variables.original_commit_timestamp
if original_commit_timestamp == UNDEFINED_COMMIT_TIMESTAMP {
    original_commit_timestamp = immediate_commit_timestamp;
}

If a replica’s original_commit_timestamp is later than its immediate_commit_timestamp , MySQL logs a warning such as:

if (original_commit_timestamp > immediate_commit_timestamp &&
    !thd->rli_slave->get_c_rli()->gtid_timestamps_warning_logged) {
    LogErr(WARNING_LEVEL, ER_INVALID_REPLICATION_TIMESTAMPS);
}

In delayed replication, the immediate_commit_timestamp from the relay log is used to compute the delay, because it reflects the commit time on the upstream server (B in an A→B→C chain). The calculation is:

sql_delay_end = ceil((static_cast<Gtid_log_event *>(ev)->immediate_commit_timestamp) / 1000000.00) + sql_delay;

If the replica does not support this field, the delay is based on the binlog header timestamp , which represents the statement start time rather than the commit time, leading to less accurate delay measurement.

For precise delay analysis, MySQL provides performance‑schema views such as ps.replication_applier_status_by_worker , ps.replication_connection_status , and ps.replication_applier_status_by_coordinator . These expose various buffer and apply timestamps (e.g., LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP , LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP ) that can be correlated with the primary’s original_commit_timestamp to compute exact replication lag.

Monitoring code points like Relay_log_info::finished_processing and Relay_log_info::started_processing reveals that each worker and coordinator thread stores a Gtid_monitoring_info structure containing the timestamps needed for these calculations.