MySQL 9.0 版本注意事項
MySQL 支援延遲複製，使得副本伺服器刻意比來源至少延遲指定的時長執行交易。本節說明如何在副本上設定複製延遲，以及如何監控複製延遲。
在 MySQL 9.0 中，延遲複製的方法取決於兩個時間戳記：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。
replication_applier_configuration Performance Schema 表格包含 DESIRED_DELAY 欄位，其中顯示使用 SOURCE_DELAY 選項設定的延遲。replication_applier_status Performance Schema 表格包含 REMAINING_DELAY 欄位，其中顯示剩餘的延遲秒數。
延遲複製可用於數個目的
保護來源免受使用者錯誤影響。透過延遲，您可以將延遲副本回溯到錯誤發生前的時間。
測試系統在發生延遲時的行為。例如，在應用程式中，延遲可能是因為副本上的負載過重所導致。不過，可能很難產生此負載層級。延遲複製可以模擬延遲，而無需模擬負載。它也可以用來偵錯與延遲副本相關的條件。
檢查資料庫過去的樣子，而無需重新載入備份。例如，透過設定一個延遲一週的副本，如果您需要查看資料庫在過去幾天開發之前的樣子，則可以檢查延遲的副本。
MySQL 9.0 提供一種新的方法來測量複製拓撲中的延遲（也稱為複製滯後），該方法依賴於與寫入二進制日誌的每個交易的 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 版本中，監控複製延遲（滯後）最常見的方法之一是依賴 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。