延迟复制

MySQL支持延迟复制，以便从属服务器故意比主服务器晚至少指定的时间量执行事务。本节介绍如何在从属服务器上配置复制延迟以及如何监视复制延迟。

在MySQL 8.0中，延迟复制的方法取决于两个时间戳，immediate_commit_timestamp并且original_commit_timestamp（请参见复制延迟时间戳）。如果复制拓扑中的所有服务器都运行MySQL 8.0.1或更高版本，则使用这些时间戳来衡量延迟复制。如果直接主服务器或从属服务器未使用这些时间戳，则使用从MySQL 5.7开始的延迟复制的实现（请参见延迟复制）。本节描述了都使用这些时间戳的服务器之间的延迟复制。

默认复制延迟为0秒。使用该CHANGE MASTER TO MASTER_DELAY=N语句将延迟设置为N秒。从主服务器接收到的事务要至少N在其提交到直接主服务器之后至少几秒钟才执行。延迟发生在每个事务中（不是以前的MySQL版本中的事件），实际延迟仅施加于gtid_log_event或anonymous_gtid_log_event。事务中的其他事件始终跟随这些事件，而不会对其施加任何等待时间。

注意
START SLAVE并STOP SLAVE立即生效，而忽略任何延迟。RESET SLAVE将延迟重置为0。

在replication_applier_configuration性能模式表包含DESIRED_DELAY表示采用配置的延迟列MASTER_DELAY选项。“replication_applier_status性能模式”表中的REMAINING_DELAY列显示了剩余的延迟秒数。

延迟复制可用于多种目的：

防止主机上的用户错误。通过延迟，您可以将延迟的从站回滚到错误之前的时间。
测试出现延迟时系统的行为。例如，在一个应用程序中，延迟可能是由于从站上的负载过重引起的。但是，可能很难生成此负载水平。延迟复制可以模拟延迟，而不必模拟负载。它还可以用于调试与滞后从站有关的条件。
检查数据库过去的状态，而不必重新加载备份。例如，通过将延迟时间配置为一个星期的从属服务器，如果您随后需要在开发最后几天之前参见数据库的外观，则可以检查延迟的从属服务器。

复制延迟时间戳

MySQL 8.0提供了一种用于测量复制拓扑中的延迟（也称为复制滞后）的新方法，该方法取决于与写入二进制日志的每个事务（而不是每个事件）的GTID相关的以下时间戳。

original_commit_timestamp：自将交易写入（提交）到原始主服务器的二进制日志中的纪元以来的微秒数。
immediate_commit_timestamp：从纪元以来的毫秒数，当事务被写入（提交）到直接主数据库的二进制日志中时。

mysqlbinlog的输出以两种格式显示这些时间戳，两种格式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的消息复制到所有应用事务的服务器（无论是组成员还是从成员复制的从属服务器），并且每个服务器都使用将本地提交时间存储在其二进制日志中immediate_commit_timestamp。

视图更改事件是组复制所独有的，是特例。包含这些事件的事务由每个服务器生成，但是共享相同的GTID（因此，它们不是首先在主服务器中执行，然后再复制到组中，而是组中的所有成员都执行并应用相同的事务）。由于没有原始主数据，因此这些交易将其original_commit_timestamp设置为零。

监视复制延迟

监视以前的MySQL版本中最常见的复制延迟（延迟）的方法之一是依靠Seconds_Behind_Master的输出字段SHOW SLAVE STATUS。但是，当使用比传统的主从设置更复杂的复制拓扑（例如组复制）时，此指标不适用。在MySQL 8中添加immediate_commit_timestamp和original_commit_timestamp可以提供有关复制延迟的更好的信息。在支持这些时间戳的拓扑中监视复制延迟的推荐方法是使用以下性能架构表。

replication_connection_status：到主服务器的连接的当前状态，提供有关连接线程排队到中继日志中的最后和当前事务的信息。
replication_applier_status_by_coordinator：协调程序线程的当前状态，仅在使用多线程从属服务器时显示信息，将有关协调程序线程缓冲的最后事务的信息提供给工作人员队列，以及当前正在缓冲的事务。
replication_applier_status_by_worker：应用从主服务器接收到的事务的线程的当前状态，提供有关应用程序线程或使用多线程从属服务器时每个工作程序应用的事务的信息。

使用这些表，您可以监视有关最后一个事务，相应的已处理线程以及该线程当前正在处理的事务的信息。该信息包括：

交易的GTID
事务的original_commit_timestamp and immediate_commit_timestamp，从从属的中继日志中检索
线程开始处理事务的时间
对于最后处理的事务，线程完成处理的时间

除了“性能模式”表外，的输出SHOW SLAVE STATUS还包含三个字段，这些字段显示：

SQL_Delay：一个非负整数，指示使用配置的复制延迟CHANGE MASTER TO MASTER_DELAY=N，以秒为单位。
SQL_Remaining_Delay：当Slave_SQL_Running_State为时Waiting until MASTER_DELAY seconds after master executed event，此字段包含一个整数，指示延迟剩余的秒数。在其他时间，此字段为NULL。
Slave_SQL_Running_State：一个字符串，指示SQL线程的状态（类似于Slave_IO_State）。该值与State所显示的SQL线程的值相同SHOW PROCESSLIST。

当从SQL线程在执行事件之前等待延迟过去时，将SHOW PROCESSLIST其State值显示为Waiting until MASTER_DELAY seconds after master executed event。