MySQL学习——管理复制源服务器的SQL语句

管理复制源服务器的语句，主要是指数据库环境中主从复制（master-slave replication）或主主复制（master-master replication）的设置。这些设置用于在多个数据库服务器之间同步数据，以实现高可用性、备份或负载均衡。主要语句有：

1 PURGE BINARY LOGS语句

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

二进制日志是一组文件，其中包含有关MySQL服务器所做数据修改的信息。日志由一组二进制日志文件和一个索引文件组成。

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

清除二进制日志需要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”格式的值）。

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

当LOCK INSTANCE FOR BACKUP语句对实例有效时，不应发出PURGE BINARY LOGS，因为它从服务器中删除文件违反了备份锁的规则。在MySQL 8.0.28中，这是被不允许的。

为了安全地清除二进制日志文件，请遵循以下步骤：

在每个复制副本上，使用SHOW replica STATUS来检查它正在读取哪个日志文件。
使用SHOW binary LOGS获取源上二进制日志文件的列表。
确定所有副本中最早的日志文件。这是目标文件。如果所有复制副本都是最新的，则这是列表上的最后一个日志文件。
备份您要删除的所有日志文件。（此步骤是可选的，但始终是可取的。）
清除目标文件之前但不包括目标文件的所有日志文件。

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

二进制日志文件会在服务器的二进制日志过期后自动删除。文件的删除可以在启动时和刷新二进制日志时进行。默认的二进制日志过期时间为30天。可以使用binlog_expire_logs_secconds系统变量指定一个替代的到期期限。如果您正在使用复制，则应指定一个不低于复制副本可能滞后于源的最长时间的过期期。

2 RESET MASTER 语句

RESET MASTER [TO binary_log_file_index_number]

请谨慎使用此语句，以确保不会丢失任何所需的二进制日志文件数据和GTID执行历史记录。

RESET MASTER需要RELOAD特权。

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

对于使用GTID的服务器（gtid_mode为ON），发出的RESET MASTER将重置GTID的执行历史。gtid_phulled系统变量的值被设置为空字符串（“”），gtid_executed系统变量的全局值（但不是会话值）被设置为一个空字符串，并且mysql.gtid_executed表被清除。如果启用GTID的服务器启用了二进制日志记录，则RESET MASTER也会如上所述重置二进制日志。请注意，RESET MASTER是重置GTID执行历史的方法，即使启用GTID的服务器是禁用二进制日志记录的副本；RESET REPLICA对GTID执行历史没有影响。

发出不带可选TO子句的RESET MASTER会删除索引文件中列出的所有二进制日志文件，将二进制日志索引文件重置为空，并从1开始创建一个新的二进制日志文件。重置后，使用可选的TO子句从1以外的数字开始二进制日志文件索引。

检查您是否使用了合理的索引号值。如果输入的值不正确，可以通过发出另一个带有或不带有TO子句的RESET MASTER语句来更正此错误。如果不更正超出范围的值，则无法重新启动服务器。

以下示例演示了TO子句的用法：

RESET MASTER TO 1234;SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name          | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 |       154 | No        |
+-------------------+-----------+-----------+

不带TO子句的RESET MASTER与PURGE BINARY LOGS的效果在两个关键方面有所不同：

RESET MASTER删除索引文件中列出的所有二进制日志文件，只留下一个数字后缀为000001的空二进制日志文件。而PURGE binary LOGS不会重置编号。
RESET MASTER不适用于运行任何复制副本的情况。在副本运行时使用RESET MASTER的行为是未定义的（因此不受支持），而在副本运行期间可以安全地使用PURGE BINARY LOGS。

当第一次设置源和复制副本时，不带TO子句的RESET MASTER是有用的，因此可以按如下方式验证设置：