sql文件中的源服务器,MySQL的SQL语句复制语句（2）用于控制源服务器的 SQL语句RESET MASTER 语句...

RESET MASTER 语句

1. RESET MASTER [TO binary_log_file_index_number]

警告

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

执行 RESET MASTER 需要 RELOAD 权限。

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

对于使用 GTID 的服务器(gtid_mode 为 ON)，发出 RESET MASTER 命令将重置 GTID 的执行历史记录。gtid_purged 系统变量的值设置为空字符串('')，gtid_executed 系统变量的全局值(而不是会话值)设置为空字符串，并且 mysql.gtid_executed 表被清空。如果启用了 GTID 的服务器启用了二进制日志记录，那么 RESET MASTER 还会按照上述方法重置二进制日志。请注意，RESET MASTER 是重置 GTID 执行历史记录的方法，即使启用 GTID 的服务器是禁用二进制日志记录的副本；RESET REPLICA | SLAVE 对 GTID 执行历史没有影响。

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

使用带 TO 子句的 RESET MASTER 指定二进制日志文件中开始的索引号，通过提供一个替代 FLUSH BINARY LOGS 和 PURGE BINARY LOGS TO 语句的单个语句，简化故障转移。检查索引号是否使用了合理的值。如果输入了不正确的值，则可以通过执行另一个 RESET MASTER 语句来更正此错误，该语句包含或不包含 TO 子句。如果不更正超出范围的值，则无法重新启动服务器。

下面的示例演示 TO 子句的用法：

1. RESET MASTER TO 1234;

2.

3. 1. SHOW BINARY LOGS;

4. +-------------------+-----------+-----------+

5. | Log_name | File_size | Encrypted |

6. +-------------------+-----------+-----------+

7. | source-bin.001234 | 154 | No |

8. +-------------------+-----------+-----------+

重要

不带 TO 子句的 RESET MASTER 与 PURGE BINARY LOGS 的效果有两个主要区别：

RESET MASTER 删除索引文件中列出的所有二进制日志文件，只留下一个数字后缀为 .000001 的空二进制日志文件，而 PURGE BINARY LOGS 不会重置编号。

在任何复制副本正在运行时，不要使用 RESET MASTER。在副本运行时使用 RESET MASTER 的行为是未定义的(因此不受支持)，而在副本运行时可以安全地使用 PURGE BINARY LOGS。

在首次设置源和副本时，不带 TO 子句的 RESET MASTER 非常有用，可以按如下方式验证设置：

启动源和副本，然后启动复制。

在源上执行一些测试查询。

检查查询是否已复制到副本。

当复制正确运行时，在副本上执行 STOP REPLICA | SLAVE，然后在副本上执行 RESET REPLICA | SLAVE，然后验证副本上不存在来自测试查询的不需要的数据。

在源上发出 RESET MASTER 以清除测试查询。

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