MySQL 9.0 发行说明
RESET BINARY LOGS AND GTIDS [TO binary_log_file_index_number]警告
谨慎使用此语句，以确保您不会丢失任何所需的二进制日志文件数据和 GTID 执行历史记录。
RESET BINARY LOGS AND GTIDS 需要 RELOAD 权限。
对于启用二进制日志记录的服务器（log_bin 为 ON），RESET BINARY LOGS AND GTIDS 会删除所有现有的二进制日志文件并重置二进制日志索引文件，将服务器重置为二进制日志记录开始之前的状态。将创建一个新的空二进制日志文件，以便可以重新启动二进制日志记录。
对于使用 GTID 的服务器（gtid_mode 为 ON），执行 RESET BINARY LOGS AND GTIDS 将重置 GTID 执行历史记录。 gtid_purged 系统变量的值将被设置为一个空字符串 ('')，gtid_executed 系统变量的全局值（但不是会话值）将被设置为一个空字符串，并且 mysql.gtid_executed 表将被清空（参见 mysql.gtid_executed 表）。如果启用了 GTID 的服务器启用了二进制日志记录，RESET BINARY LOGS AND GTIDS 还会如上所述重置二进制日志。请注意，即使启用了 GTID 的服务器是二进制日志记录被禁用的副本，RESET BINARY LOGS AND GTIDS 也是重置 GTID 执行历史记录的方法；RESET REPLICA 对 GTID 执行历史记录没有影响。有关重置 GTID 执行历史记录的更多信息，请参见 重置 GTID 执行历史记录。
执行 RESET BINARY LOGS AND GTIDS 而不使用可选的 TO 子句将删除索引文件中列出的所有二进制日志文件，将二进制日志索引文件重置为空，并创建一个新的二进制日志文件，从 1 开始。使用可选的 TO 子句，可以在重置后从除 1 之外的数字开始二进制日志文件索引。
请检查您使用的索引号是否合理。如果您输入了错误的值，可以通过使用或不使用 TO 子句执行另一个 RESET BINARY LOGS AND GTIDS 语句来更正。如果您没有更正超出范围的值，服务器将无法重启。
以下示例演示了 TO 子句的用法
RESET BINARY LOGS AND GTIDS TO 1234;
SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 | 154 | No |
+-------------------+-----------+-----------+重要
不使用 TO 子句的 RESET BINARY LOGS AND GTIDS 的效果与 PURGE BINARY LOGS 在两个关键方面不同
RESET BINARY LOGS AND GTIDS将删除索引文件中列出的 所有 二进制日志文件，只留下一个空的二进制日志文件，其数字后缀为.000001，而PURGE BINARY LOGS不会重置编号。RESET BINARY LOGS AND GTIDS不 应该在任何副本运行时使用。当在副本运行时使用RESET BINARY LOGS AND GTIDS时，其行为是未定义的（因此不受支持），而PURGE BINARY LOGS可以在副本运行时安全使用。
当您首次设置源和副本时，不使用 TO 子句的 RESET BINARY LOGS AND GTIDS 可以被证明很有用，这样您就可以按如下方式验证设置
启动源和副本，并启动复制（参见 第 19.1.2 节，“设置基于二进制日志文件位置的复制”）。
在源上执行几个测试查询。
检查查询是否已复制到副本。
当复制正常运行时，执行
STOP REPLICA，然后执行RESET REPLICA（都在副本上），然后验证副本上不存在来自测试查询的任何不需要的数据。之后，执行RESET BINARY LOGS AND GTIDS（也在副本上）以删除二进制日志和关联的交易 ID。从源中删除不需要的数据，然后执行
RESET BINARY LOGS AND GTIDS以清除与其相关的任何二进制日志条目和标识符。
验证设置后，重置源和副本，并确保源或副本上没有保留由测试生成的任何不需要的数据或二进制日志文件，然后您可以启动副本并开始复制。