官网地址：MySQL :: MySQL 5.7 Reference Manual :: 13.4.1 SQL Statements for Controlling Replication Source Servers
欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.
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'
当副本正在复制时，此语句可以安全运行。你不需要阻止他们。如果您有一个活动副本当前正在读取您尝试删除的日志文件之一，则此语句不会删除正在使用的日志文件或晚于该日志文件的任何日志文件，但会删除所有较早的日志文件。在这种情况下会发出警告消息。但是，如果副本未连接，并且您碰巧清除了它尚未读取的日志文件之一，则副本在重新连接后将无法进行复制。
要安全地清除二进制日志文件，请按照以下过程操作：
-
在每个副本上，用于SHOW SLAVE STATUS检查它正在读取哪个日志文件。
-
使用 获取复制源服务器上的二进制日志文件的列表SHOW BINARY LOGS。
-
确定所有副本中最早的日志文件。这是目标文件。如果所有副本都是最新的，则这是列表中的最后一个日志文件。
-
备份您要删除的所有日志文件。（此步骤是可选的，但始终建议。）
-
清除直到但不包括目标文件的所有日志文件。
您还可以将 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请谨慎使用此语句，以确保您不会丢失任何所需的二进制日志文件数据和 GTID 执行历史记录。
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 不同之处：PURGE BINARY LOGS
-
RESET MASTER删除 索引文件中列出的所有
.000001二进制日志文件，只留下一个带有数字后缀的空二进制日志文件，而编号不会由 重置 PURGE BINARY LOGS。 -
RESET MASTER不 打算在任何副本运行时使用。RESET MASTER副本运行时使用的行为 未定义（因此不受支持），而PURGE BINARY LOGS副本运行时可以安全使用。
另请参见第 13.4.1.1 节“PURGE BINARY LOGS 语句”。
RESET MASTER当您首次设置源和副本时，这会很有用，以便您可以按如下方式验证设置：
-
启动源和副本，然后开始复制（请参见 第 16.1.2 节 “设置基于二进制日志文件位置的复制”）。
-
对源执行一些测试查询。
-
检查查询是否已复制到副本。
-
当复制正确运行时，在副本上发出问题 STOP SLAVE， RESET SLAVE然后验证副本上不再存在任何不需要的数据。
-
在源上发出问题RESET MASTER以清理测试查询。
验证设置、重置源和副本并确保源或副本上没有测试生成的不需要的数据或二进制日志文件后，您可以启动副本并开始复制。
SET sql_log_bin = {OFF|ON}该sql_log_bin变量控制是否为当前会话启用记录到二进制日志（假设二进制日志本身已启用）。默认值为ON。要禁用或启用当前会话的二进制日志记录，请将会话sql_log_bin变量设置为 OFF或ON。
将此变量设置为OFF会话，以在对不希望复制到副本的源进行更改时临时禁用二进制日志记录。
设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参见 第 5.1.8.1 节“系统变量权限”。
无法 sql_log_bin在事务或子查询中设置会话值。
设置此变量可防止OFF 将 GTID 分配给二进制日志中的事务。如果您使用 GTID 进行复制，这意味着即使稍后再次启用二进制日志记录，从此时写入日志的 GTID 也不会考虑同时发生的任何事务，因此实际上这些事务都会丢失。
全局sql_log_bin变量是只读的，不能修改。全局范围已被弃用；预计它会在未来的 MySQL 版本中被删除。
