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