MySQL 8.4 发行说明
注意
此语句取代了旧的 RESET MASTER 语句，该语句不再受支持。
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 执行历史记录。
执行不带可选 TO 子句的 RESET BINARY LOGS AND GTIDS 将删除索引文件中列出的所有二进制日志文件，将二进制日志索引文件重置为空，并创建一个从 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以清除与其关联的任何二进制日志条目和标识符。
在验证设置、重置主服务器和副本并确保主服务器或副本上不存在由测试生成的不需要的数据或二进制日志文件后，您可以启动副本并开始复制。