MySQL 8.3 Release Notes
RESET MASTER [TO binary_log_file_index_number]该语句已弃用，并将在未来版本的 MySQL 中删除。在 MySQL 8.2.0 及更高版本中，请使用 RESET BINARY LOGS AND GTIDS 语句代替。
Warning
请小心使用该语句，以免丢失任何想要的二进制日志文件数据和 GTID 执行历史记录。
RESET MASTER 需要 RELOAD 权限。
对于启用了二进制日志记录的服务器 (log_bin 为 ON），RESET MASTER 删除所有现有的二进制日志文件，并重置二进制日志索引文件，将服务器恢复到启用二进制日志记录之前的状态。创建一个新的空白二进制日志文件，以便重新启动二进制日志记录。
对于启用了 GTID 的服务器 (gtid_mode 为 ON），执行 RESET MASTER 将重置 GTID 执行历史记录。gtid_purged 系统变量的值将被设置为空字符串 (''），gtid_executed 系统变量的全局值（但不是会话值）将被设置为空字符串，mysql.gtid_executed 表将被清空（见 mysql.gtid_executed 表）。如果 GTID 启用的服务器启用了二进制日志记录，RESET MASTER 也将重置二进制日志，如上所述。注意，RESET MASTER 是重置 GTID 执行历史记录的方法，即使 GTID 启用的服务器是副本，而二进制日志记录被禁用；RESET REPLICA 不会影响 GTID 执行历史记录。有关重置 GTID 执行历史记录的更多信息，请参阅 重置 GTID 执行历史记录。
执行 RESET MASTER 语句而不带有可选的 TO 子句，将删除所有二进制日志文件，重置二进制日志索引文件，并创建一个新的二进制日志文件，从 1 开始。使用可选的 TO 子句可以从其他数字开始二进制日志文件索引。
请确保使用合理的索引号值。如果输入了错误的值，可以通过再次执行 RESET MASTER 语句（带或不带 TO 子句）来纠正。如果您不纠正超出范围的值，服务器将无法重新启动。
以下示例演示了 TO 子句的使用：
RESET MASTER TO 1234;
SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 | 154 | No |
+-------------------+-----------+-----------+
Important
与 PURGE BINARY LOGS 语句相比，RESET MASTER 语句的效果有两个关键区别：
-
RESET MASTER删除所有二进制日志文件，仅留下一个空白的二进制日志文件，编号为.000001，而PURGE BINARY LOGS不会重置编号。 -
RESET MASTER不应在副本运行时使用。使用RESET MASTER语句时副本正在运行的行为是未定义的（因此不受支持），而PURGE BINARY LOGS可以在副本运行时安全使用。
RESET MASTER 语句（不带 TO 子句）可以在首次设置源和副本时证明有用，以便验证设置，如下所示：
-
启动源和副本，并启动复制（见 第 19.1.2 节，“基于二进制日志文件位置的复制设置”）。
-
在源上执行几个测试查询。
-
确保查询已经复制到副本。
-
当复制运行正确时，在副本上发出
STOP REPLICA，然后是RESET REPLICA，然后验证副本上不存在测试查询的不想要的数据。 -
从源中删除不想要的数据，然后发出
RESET MASTER以清除与其关联的二进制日志条目和标识符。
在验证设置、重置源和副本、确保源或副本上不存在测试生成的不想要的数据或二进制日志文件后，可以启动副本并开始复制。