15.4.1.2 重置二进制日志和 GTID 语句
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
删除所有现有二进制日志文件,并重置二进制日志索引文件,使服务器回退到二进制日志记录开始前的状态。然后,创建一个新的空二进制日志文件,以便重新启动二进制日志记录。
在使用 GTIDs 的服务器 (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
也将重置二进制日志记录,如上所述。注意,RESET BINARY LOGS AND GTIDS
是重置 GTID 执行历史的方法,即使 GTID 启用的服务器是副本,二进制日志记录禁用;RESET REPLICA
无法影响 GTID 执行历史。有关重置 GTID 执行历史的更多信息,请见重置 GTID 执行历史。
执行 RESET BINARY LOGS AND GTIDS
语句时,如果不使用可选的 TO
take 删除所有二进制日志文件,重置二进制日志索引文件,使其为空,并创建一个新的二进制日志文件,开始从 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 |
+-------------------+-----------+-----------+
RESET BINARY LOGS AND GTIDS
语句的效果在不使用 TO
语句时与PURGE BINARY LOGS
在 2 个关键方面不同:
-
RESET BINARY LOGS AND GTIDS
删除了索引文件中列出的所有二进制日志文件,留下一个空的二进制日志文件,文件名为.000001
,而且编号不被PURGE BINARY LOGS
重置。 -
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
以删除与测试生成的二进制日志文件和关联的交易ID。
验证设置后,重置源和从属服务器,并确保在源或从属服务器上没有任何不想要的数据或二进制日志文件生成的测试数据,然后可以启动从属服务器并开始复制。