MySQL5.7控制复制源服务器的SQL语句

本节讨论用于管理复制源服务器的语句。第 13.4.2 节“用于控制副本服务器的 SQL 语句”讨论用于管理副本服务器的语句。

除了此处描述的语句之外，以下?SHOW语句还用于复制中的源服务器。有关这些语句的信息，请参阅第 13.7.5 节“SHOW 语句”。

PURGE { BINARY | MASTER } LOGS {
    TO 'log_name'
  | BEFORE datetime_expr
}

二进制日志是一组文件，其中包含有关 MySQL 服务器所做的数据修改的信息。日志由一组二进制日志文件和一个索引文件组成（请参见?第 5.4.4 节“二进制日志”）。

该PURGE BINARY LOGS语句删除日志索引文件中列出的指定日志文件名或日期之前的所有二进制日志文件。?BINARY和MASTER是同义词。删除的日志文件也会从索引文件中记录的列表中删除，以便给定的日志文件成为列表中的第一个。

PURGE BINARY LOGS需要?BINLOG_ADMIN特权。--log-bin如果服务器不是使用启用二进制日志记录的选项?启动的，则此语句无效 。

例子：

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';

变BEFORE体的?datetime_expr参数应计算为一个DATETIME值（格式中的值）。?'YYYY-MM-DD hh:mm:ss'

当副本正在复制时，此语句可以安全运行。你不需要阻止他们。如果您有一个活动副本当前正在读取您尝试删除的日志文件之一，则此语句不会删除正在使用的日志文件或晚于该日志文件的任何日志文件，但会删除所有较早的日志文件。在这种情况下会发出警告消息。但是，如果副本未连接，并且您碰巧清除了它尚未读取的日志文件之一，则副本在重新连接后将无法进行复制。

要安全地清除二进制日志文件，请按照以下过程操作：

您还可以将?expire_logs_days系统变量设置为在给定天数后自动使二进制日志文件过期（请参见第 5.1.7 节 “服务器系统变量”）。如果您使用复制，则应将该变量设置为不低于副本可能落后于源的最大天数。

PURGE BINARY LOGS TO当文件中列出的二进制日志文件已通过其他方式（例如在 Linux 上使用?rm?）从系统中删除时，两者都会失败并PURGE BINARY LOGS BEFORE出现错误。（Bug #18199、Bug #18453）要处理此类错误，请手动编辑文件（这是一个简单的文本文件）以确保它仅列出实际存在的二进制日志文件，然后再次运行?失败的语句。?.index.indexPURGE BINARY LOGS

RESET MASTER

RESET MASTER需要?RELOAD特权。

对于启用了二进制日志记录的服务器 (?log_binis?ON)，RESET MASTER删除所有现有的二进制日志文件并重置二进制日志索引文件，将服务器重置为启动二进制日志记录之前的状态。将创建一个新的空二进制日志文件，以便可以重新启动二进制日志记录。

对于正在使用 GTID 的服务器 (?gtid_modeis?ON)，发出命令RESET MASTER?会重置 GTID 执行历史记录。系统变量的值?gtid_purged被设置为空字符串（''），系统变量的全局值（但不是会话值）?gtid_executed被设置为空字符串，并且?mysql.gtid_executed表被清除（参见?mysql.gtid_execulated 表）。如果启用 GTID 的服务器启用了二进制日志记录，?RESET MASTER还会按上述方式重置二进制日志。请注意，这?RESET MASTER是重置 GTID 执行历史记录的方法，即使启用 GTID 的服务器是禁用二进制日志记录的副本；?RESET SLAVE对 GTID 执行历史没有影响。有关重置 GTID 执行历史记录的更多信息，请参阅?重置 GTID 执行历史记录。

RESET MASTER当您首次设置源和副本时，这会很有用，以便您可以按如下方式验证设置：

验证设置、重置源和副本并确保源或副本上没有测试生成的不需要的数据或二进制日志文件后，您可以启动副本并开始复制。

SET sql_log_bin = {OFF|ON}