<\/span><\/h3>\nIn MySQL 8.0 the delayed replication is controlled by two system variables on timestamps –\u00a0orginal_commit_timestamp<\/i>\u00a0<\/em>and immediate_commit_timestamp<\/em>\u00a0,<\/i>\u00a0 They depend on\u00a0GTID of each transaction (instead of each event like in MySQL 5.7) written to the binary log.These two system variables are applicable only when your entire replication infrastructure is on MySQL 8.0.1 or above , If either Master or slave is not using these timestamps, then delayed replication from MySQL 5.7 is used.\u00a0<\/strong><\/p>\n\n- original_commit_timestamp<\/strong><\/span>: The total number of\u00a0microseconds since epoch when the transaction was written (committed) to the binary log of the original master.<\/li>\n
- immediate_commit_timestamp<\/strong><\/span>: The total number of\u00a0microseconds since epoch when the transaction was written (committed) to the binary log of the immediate master \/ slave.<\/li>\n<\/ul>\n
The\u00a0orginal_commit_timestamp\u00a0<\/i>will be always same on all replication when the transaction is applied. In a typical master-slave replication, the\u00a0original_commit_timestamp<\/em> of a transaction in the (original) master\u2019s binary log is always the same as its immediate_commit_timestamp<\/em>. In the slave\u2019s relay log, the original_commit_timestamp <\/em>and immediate_commit_timestamp<\/em> of the transaction are the same as in the master\u2019s binary log; whereas in its own binary log, the transaction\u2019s immediate_commit_timestamp<\/em> corresponds to when the slave committed the transaction.<\/p>\n