reset master、reset slave与reset slave all 今天测一测这几个参数,首先说下测试环境:
主节点:192.168.197.128
从节点:192.168.197.137
01
reset slave命令和reset slave all测试
今天在做GTID功能测试的时候,使用了reset slave命令,关于这个命令,这里简单讲一讲:
reset slave命令进行两个动作:
1.清除 master.info,relay-log.info文件(记录),
2.删除所有的relay log,包括还没有应用完的日志,创建一个新的relay log文件.
我们来看第一个动作,也就是清楚master.info文件和relay-log.info文件,需要注意的是,新版本的mysql中,这两个文件已经不存在了,而是存储在mysql数据库的slave_master_info表和slave_relay_log_info表中,我们在从节点停止复制前后来查看这两个表里面的内容,如下:
mysql> select * from mysql.slave_master_info where host='192.168.197.128'G
*************************** 1. row ***************************
Number_of_lines:
Master_log_name: mysql-bin.000009
Master_log_pos:
Host: 192.168.197.128
User_name: repluser
User_password:
Port:
Connect_retry:
Enabled_ssl:
mysql> select * from mysql.slave_relay_log_info where master_log_name ='mysql-bin.000009'G
*************************** 1. row ***************************
Number_of_lines:
Relay_log_name: ./mysql-relay-bin.000001
Relay_log_pos:
Master_log_name: mysql-bin.000009
Master_log_pos:
Sql_delay:
Number_of_workers:
Id:
Channel_name:
row in set (0.00 sec)
mysql> stop slave;
Query OK, rows affected (0.01 sec)
mysql> reset slave;
Query OK, rows affected (0.01 sec)
mysql> select * from mysql.slave_master_info where host='192.168.197.128'G
Empty set (0.00 sec)
mysql> select * from mysql.slave_relay_log_info where master_log_name ='mysql-bin.000009'G
Empty set (0.00 sec)
上面的例子说明,停止复制前后,这两个表中对应记录被删除了,也就是说名reset slave操作确实会删除相关的记录。
我们再来证明第二个动作,来看例子,首先来看清理之前,data文件夹目录下面的内容,注意红色部分:
[root@work_NAT_4 data]# ll total -rw-r-----. mysql mysql Sep auto.cnf drwxr-x---. mysql mysql Jul customer drwxr-x---. mysql mysql Sep DBAs -rw-r-----. mysql mysql Mar : ib_buffer_pool -rw-r-----. mysql mysql May : ibdata1 -rw-r-----. mysql mysql May : ib_logfile0 -rw-r-----. mysql mysql Jul ib_logfile1 -rw-r-----. mysql mysql May : ibtmp1 drwxr-x---. mysql mysql Aug inc_db -rw-r-----. mysql mysql Feb : localhost.localdomaion.pid -rw-r-----. mysql mysql Sep localhost-relay-bin.000001 -rw-r-----. mysql mysql Sep localhost-relay-bin.index drwxr-x---. mysql mysql Jul mysql -rw-r-----. mysql mysql May : mysql-bin.000005 -rw-r-----. mysql mysql May : mysql-bin.index -rw-r-----. mysql mysql May : mysql-relay-bin.000009 -rw-r-----. mysql mysql May : mysql-relay-bin.000010 -rw-r-----. mysql mysql May : mysql-relay-bin.index drwxr-x---. mysql mysql Jul performance_schema drwxr-x---. mysql mysql Jul sys drwxr-x---. mysql mysql May : test drwxr-x---. mysql mysql Jul testdb -rw-r--r--. root root Jul test.txt -rw-r-----. mysql mysql May : work_NAT_4.pid drwxr-x---. mysql mysql Mar : yeyz
此时我们客户端中使用reset slave命令,可以看到如下结果:
mysql> reset slave; ERROR (HY000): This operation cannot be performed with running replication threads; run STOP SLAVE FOR CHANNEL '' first mysql> stop slave; Query OK, rows affected (0.00 sec) mysql> reset slave; Query OK, rows affected (0.04 sec)
可以看到,reset slave 必须在stop slave命令后面使用,否则无法直接对slave进行重置,当我们使用了reset slave命令之后,我们可以看到data文件夹下面的内容变为了:
[root@work_NAT_4 data]# ll total -rw-r-----. mysql mysql Sep auto.cnf drwxr-x---. mysql mysql Jul customer drwxr-x---. mysql mysql Sep DBAs -rw-r-----. mysql mysql Mar : ib_buffer_pool -rw-r-----. mysql mysql May : ibdata1 -rw-r-----. mysql mysql May : ib_logfile0 -rw-r-----. mysql mysql Jul ib_logfile1 -rw-r-----. mysql mysql May : ibtmp1 drwxr-x---. mysql mysql Aug inc_db -rw-r-----. mysql mysql Feb : localhost.localdomaion.pid -rw-r-----. mysql mysql Sep localhost-relay-bin.000001 -rw-r-----. mysql mysql Sep localhost-relay-bin.index drwxr-x---. mysql mysql Jul mysql -rw-r-----. mysql mysql May : mysql-bin.000005 -rw-r-----. mysql mysql May : mysql-bin.index -rw-r-----. mysql mysql May : mysql-relay-bin.000001 -rw-r-----. mysql mysql May : mysql-relay-bin.index drwxr-x---. mysql mysql Jul performance_schema drwxr-x---. mysql mysql Jul sys drwxr-x---. mysql mysql May : test drwxr-x---. mysql mysql Jul testdb -rw-r--r--. root root Jul test.txt -rw-r-----. mysql mysql May : work_NAT_4.pid drwxr-x---. mysql mysql Mar : yeyz
我们可以发现,它修改了mysql-relay-bin.000001的序号。此时我们使用show slave status来查看复制情况:
mysql> reset slave;
Query OK, rows affected (0.01 sec)
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.197.128
Master_User: repluser
Master_Port:
Connect_Retry:
Master_Log_File:
Read_Master_Log_Pos:
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos:
Relay_Master_Log_File:
Slave_IO_Running: No
Slave_SQL_Running: No
可以发现,这个复制的情况还是能看到的。
如果此时我们进行start slave的命令,在Second Behind Master等于0的情况下,依旧可以搭建主从复制,如下:
mysql> start slave;
Query OK, rows affected (0.02 sec)
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.197.128
Master_User: repluser
Master_Port:
Connect_Retry:
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos:
Relay_Log_File: mysql-relay-bin.000004
Relay_Log_Pos:
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
如果我们使用了reset slave all,结果会变成:
mysql> stop slave ; Query OK, rows affected (0.01 sec) mysql> reset slave all; Query OK, rows affected (0.01 sec) mysql> show slave statusG Empty set (0.00 sec)
结论:
第一、reset slave命令和reset slave all命令会删除所有的relay log(包括还没有应用完的日志),创建一个新的relay log文件;
第二、使用reset slave命令,那么所有的连接信息仍然保留在内存中,包括主库地址、端口、用户、密码等。这样可以直接运行start slave命令而不必重新输入change master to命令,而运行show slave status也仍和没有运行reset slave一样,有正常的输出。但如果使用reset slave all命令,那么这些内存中的数据也会被清除掉,运行show slave status就输出为空了。
第三、reset slave和reset slave all命令会将系统mysql数据库的slave_master_info表和slave_relay_log_info表中对应的复制记录清除。
02
reset master命令
还是一样,我们先来说说这个命令的结果:
1、清理所有的binlog文件,创建一个新的文件,起始值从1开始。
2、GTID环境中,reset master会清理掉gtid_executed的值
实验如下:
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000008 | |
| mysql-bin.000009 | |
+------------------+-----------+
rows in set (0.00 sec)
mysql> show master statusG
*************************** 1. row ***************************
File: mysql-bin.000009
Position:
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: db33b36-0e51-409f-a61d-c99756e90155:1-14,
bd0d-8691-11e8-afd6-4c3e51db5828:1-9
row in set (0.00 sec)
mysql> reset master;
Query OK, rows affected (0.12 sec)
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | |
+------------------+-----------+
row in set (0.00 sec)
mysql> show master statusG
*************************** 1. row ***************************
File: mysql-bin.000001
Position:
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
row in set (0.00 sec)
我们在主节点上进行了reset master操作,此时我们是哟红master_auto_position参数来搭建主从复制,看看结果:
mysql> change master to master_host='192.168.197.128',
-> master_user='repluser',
-> master_password='123456',
-> master_port=,
-> master_auto_position=;
Query OK, rows affected, warnings (0.01 sec)
mysql> start slave;
Query OK, rows affected (0.01 sec)
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.197.128
Master_User: repluser
Master_Port:
Connect_Retry:
Master_Log_File:
Read_Master_Log_Pos:
Relay_Log_File: mysql-relay-bin.000001
Relay_Log_Pos:
Relay_Master_Log_File:
Slave_IO_Running: No
Slave_SQL_Running: Yes
Last_IO_Errno:
Last_IO_Error: Got fatal error from master when reading
data from binary log: 'Slave has more GTIDs than the master has, using the
master's SERVER_UUID. This may indicate that the end of the binary log was
truncated or that the last binary log file was lost, e.g., after a power or disk
failure when sync_binlog != 1. The master may or may not have rolled back
transactions that were already replica'
Executed_Gtid_Set: 3db33b36-0e51-409f-a61d-c99756e90155:1-14,
9451bd0d-8691-11e8-afd6-4c3e51db5828:1-9,
bb874065-c485-11e8-8b52-000c2934472e:1
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
我们可以发现,复制的结果出错了,找找原因,“Slave has more GTIDs than the master has,using the master's SERVER_UUID. “提示我们slave包含太多UUID了,需要指定master的UUID,这个时候我们应该怎么办呢?
既然已经说了slave的GTID太多了,我们直接使用reset master命令给它清理掉就行了。说干就干,查看下当前slave的GTID,然后进行处理:
mysql> show master statusG
*************************** 1. row ***************************
File: mysql-bin.000005
Position:
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: db33b36-0e51-409f-a61d-c99756e90155:1-14,
bd0d-8691-11e8-afd6-4c3e51db5828:1-9,
bb874065-c485-11e8-8b52-000c2934472e:
row in set (0.00 sec)
mysql> stop slave;
Query OK, rows affected (0.00 sec)
mysql> reset slave all;
Query OK, rows affected (0.01 sec)
mysql> change master to master_host='192.168.197.128',
-> master_user='repluser',
-> master_password='123456',
-> master_port=,
-> master_auto_position=;
Query OK, rows affected, warnings (0.03 sec)
搭建完毕之后,我们看看结果:
mysql> start slave;
Query OK, rows affected (0.01 sec)
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.197.128
Master_User: repluser
Master_Port:
Connect_Retry:
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos:
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos:
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
可以看到,reset master操作会将GTID都清空。
总结一下:
1、reset master操作有两个功能,一个是把binary log进行清空,并生成新的编号为000001的binary log
2、reset master会清空主库的GTID编号,在搭建主从的时候可以使用,但是要慎用(如果你的二进制日志还有需要的话)。
继续阅读与本文标签相同的文章
MySQL线上日志库迁移优化案例
Innodb存储引擎之插入缓冲
-
MySQL中的sql_mode参数
2026-05-26栏目: 教程
-
mysqlbinlog浅析
2026-05-26栏目: 教程
-
使用pt-query-digest分析mysql慢日志
2026-05-26栏目: 教程
-
MySQL之GTID
2026-05-26栏目: 教程
-
innodb_flush_log_at_trx_commit参数
2026-05-26栏目: 教程
