#### 17.5.1.28 复制和源或副本关闭

[](<>)[](<>)[](<>)[](<>)

关闭复制源服务器并稍后重新启动它是安全的。当副本失去与源的连接时，副本会立即尝试重新连接，如果失败则定期重试。默认设置是每 60 秒重试一次。这可能会随着[`将复制源更改为`](change-replication-source-to.html)语句（来自 MySQL 8.0.23）或[`将主更改为`](change-master-to.html)语句（在 MySQL 8.0.23 之前）。副本还能够处理网络连接中断。但是，副本只有在没有从源接收到数据后才注意到网络中断[`副本网络超时`](replication-options-replica.html#sysvar_replica_net_timeout)要么[`slave_net_timeout`](replication-options-replica.html#sysvar_slave_net_timeout)秒。如果您的中断时间很短，您可能希望减少[`副本网络超时`](replication-options-replica.html#sysvar_replica_net_timeout)要么[`slave_net_timeout`](replication-options-replica.html#sysvar_slave_net_timeout).看[第 17.4.2 节，“处理副本的意外停止”](replication-solutions-unexpected-replica-halt.html).

由于源端的二进制日志文件未刷新，源端的不正常关闭（例如崩溃）可能导致源端的二进制日志的最终位置小于副本读取的最近位置。这可能会导致副本在源恢复时无法复制。环境[`sync_binlog=1`](replication-options-binary-log.html#sysvar_sync_binlog)在源服务器的`我的.cnf`file 有助于最小化这个问题，因为它会导致源更频繁地刷新其二进制日志。为了在复制设置中获得最大可能的持久性和一致性，使用`InnoDB`对于交易，您还应该设置[`innodb_flush_log_at_trx_commit=1`](innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit).使用此设置，`InnoDB`每次事务提交时，重做日志缓冲区都会写入日志文件，并且日志文件会刷新到磁盘。请注意，此设置仍不能保证事务的持久性，因为操作系统或磁盘硬件可能会告诉[**mysqld**](mysqld.html)表明刷新到磁盘的操作已经发生，即使它还没有发生。

干净地关闭副本是安全的，因为它会跟踪它停止的位置。但是，请注意副本没有打开临时表；看[第 17.5.1.31 节，“复制和临时表”](replication-features-temptables.html).不干净的关闭可能会产生问题，尤其是在问题发生之前磁盘缓存未刷新到磁盘时：

-   对于事务，副本提交然后更新`中继日志信息`.如果在这两个操作之间发生意外退出，中继日志处理会比信息文件指示的更进一步，并且副本在重新启动后重新执行中继日志中最后一个事务的事件。

-   如果副本更新，可能会出现类似的问题`中继日志信息`但是服务器主机在写入刷新到磁盘之前崩溃了。为了尽量减少这种情况发生的机会，设置[`sync_relay_log_info=1`](replication-options-replica.html#sysvar_sync_relay_log_info)在复制品中`我的.cnf`文件。环境[`sync_relay_log_info`](replication-options-replica.html#sysvar_sync_relay_log_info)为 0 导致不强制写入磁盘，并且服务器依赖操作系统不时刷新文件。

    如果你有一个好的不间断电源，你的系统对这些类型的问题的容错能力就会大大提高。
