MySQL 8.4 版本資訊
MySQL 支援延遲複製，以便副本伺服器刻意比來源晚至少指定的延遲時間來執行交易。本節說明如何在副本上設定複製延遲，以及如何監控複製延遲。
在 MySQL 8.4 中，延遲複製的方法取決於兩個時間戳記，immediate_commit_timestamp 和 original_commit_timestamp（請參閱複製延遲時間戳記）；延遲複製是使用這些時間戳記來衡量的。如果立即來源或副本未使用這些時間戳記，則會使用 MySQL 5.7 的延遲複製實作（請參閱延遲複製）。本節說明伺服器之間都使用這些時間戳記的延遲複製。
預設複製延遲為 0 秒。使用 CHANGE REPLICATION SOURCE TO SOURCE_DELAY= 陳述式將延遲設為 NN 秒。從來源接收的交易必須至少比其在立即來源上的提交晚 N 秒才會執行。延遲發生在每個交易上（而不是像先前 MySQL 版本中的事件），並且實際延遲僅對 gtid_log_event 或 anonymous_gtid_log_event 強制執行。交易中的其他事件始終會遵循這些事件，而不會對其強制執行任何等待時間。
注意
START REPLICA 和 STOP REPLICA 會立即生效，並忽略任何延遲。RESET REPLICA 會將延遲重設為 0。
效能綱要（Performance Schema）的 replication_applier_configuration 資料表包含 DESIRED_DELAY 欄位，該欄位會顯示使用 SOURCE_DELAY 選項設定的延遲時間。效能綱要的 replication_applier_status 資料表包含 REMAINING_DELAY 欄位，該欄位會顯示剩餘的延遲秒數。
延遲複寫可用於多種用途
保護來源免於使用者錯誤。透過延遲，您可以將延遲複本回滾到錯誤發生之前的時間點。
測試系統在發生延遲時的行為。例如，在應用程式中，延遲可能是由於複本上的高負載所導致。然而，可能難以產生此負載等級。延遲複寫可以模擬延遲，而無需模擬負載。它也可用於偵錯與延遲複本相關的狀況。
檢視過去資料庫的狀態，而無需重新載入備份。例如，透過將複本設定為延遲一週，如果您需要查看最近幾天開發之前資料庫的狀態，可以檢查延遲的複本。
MySQL 8.4 提供了一種新的延遲測量方法（也稱為複寫延遲），該方法依賴於與寫入二進位日誌的每個交易的 GTID 相關聯的以下時間戳記（而不是每個事件）。
original_commit_timestamp：自 epoch 以來的微秒數，表示交易寫入（提交）到原始來源的二進位日誌的時間。immediate_commit_timestamp：自 epoch 以來的微秒數，表示交易寫入（提交）到直接來源的二進位日誌的時間。
mysqlbinlog 的輸出以兩種格式顯示這些時間戳記，一種是自 epoch 以來的微秒數，另一種是 TIMESTAMP 格式，後者基於使用者定義的時區，以提高可讀性。例如
#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一般而言，original_commit_timestamp 在應用該交易的所有複本上始終相同。在來源-複本複寫中，（原始）來源的二進位日誌中交易的 original_commit_timestamp 始終與其 immediate_commit_timestamp 相同。在複本的中繼日誌中，交易的 original_commit_timestamp 和 immediate_commit_timestamp 與來源的二進位日誌中的相同；而在其自身的二進位日誌中，交易的 immediate_commit_timestamp 對應於複本提交該交易的時間。
在群組複寫設定中，當原始來源是群組的成員時，會在交易準備好提交時產生 original_commit_timestamp。換句話說，當它在原始來源上完成執行，並且其寫入集準備好發送給群組的所有成員進行認證時。當原始來源是群組外部的伺服器時，會保留 original_commit_timestamp。特定交易的相同 original_commit_timestamp 會複寫到群組中的所有伺服器，以及從成員複寫的群組外部的任何複本。交易的每個接收者也會使用 immediate_commit_timestamp 將本機提交時間儲存在其二進位日誌中。
視圖變更事件是群組複寫獨有的特殊情況。包含這些事件的交易由每個群組成員產生，但共用相同的 GTID（因此，它們不是先在來源中執行，然後複寫到群組，而是群組的所有成員執行並套用相同的交易）。群組成員會為與視圖變更事件相關的交易設定本機時間戳記值。
在之前的 MySQL 版本中，監控複寫延遲（lag）的最常見方法之一是依賴 SHOW REPLICA STATUS 輸出的 Seconds_Behind_Master 欄位。然而，當使用比傳統來源-複本設定更複雜的複寫拓撲（例如群組複寫）時，此指標並不適用。在 MySQL 8 中加入 immediate_commit_timestamp 和 original_commit_timestamp 提供了關於複寫延遲更精細的資訊。在支援這些時間戳記的拓撲中，建議使用以下效能綱要資料表來監控複寫延遲。
replication_connection_status：與來源連線的目前狀態，提供關於連線執行緒排入中繼日誌的最後和目前交易的資訊。replication_applier_status_by_coordinator：協調器執行緒的目前狀態，僅在使用多執行緒複本時才會顯示資訊，提供關於協調器執行緒緩衝到工作者佇列的最後一個交易，以及目前正在緩衝的交易的資訊。replication_applier_status_by_worker：套用從來源接收的交易的執行緒的目前狀態，提供關於複寫 SQL 執行緒或使用多執行緒複本時每個工作者執行緒所套用的交易的資訊。
使用這些資料表，您可以監控關於對應執行緒處理的最後一個交易以及該執行緒目前正在處理的交易的資訊。此資訊包含
交易的 GTID
交易的
original_commit_timestamp和immediate_commit_timestamp，從複本的中繼日誌擷取執行緒開始處理交易的時間
對於最後處理的交易，執行緒完成處理的時間
除了效能綱要資料表之外，SHOW REPLICA STATUS 的輸出還有三個欄位顯示
SQL_Delay：一個非負整數，表示使用CHANGE REPLICATION SOURCE TO SOURCE_DELAY=設定的複寫延遲，其中NN以秒為單位。SQL_Remaining_Delay：當Replica_SQL_Running_State為Waiting until SOURCE_DELAY seconds after master executed event時，此欄位包含一個整數，表示剩餘的延遲秒數。在其他時間，此欄位為NULL。Replica_SQL_Running_State：一個字串，表示 SQL 執行緒的狀態（類似於Replica_IO_State）。該值與SHOW PROCESSLIST顯示的 SQL 執行緒的State值相同。
當複寫 SQL 執行緒正在等待延遲經過，然後再執行事件時，SHOW PROCESSLIST 會將其 State 值顯示為 Waiting until SOURCE_DELAY seconds after master executed event。