mysql reset master_MySQL Reset Master AND Reset Slave

RESET MASTER

删除所有 index file 中记录的所有 binlog 文件，将日志索引文件清空，创建一个新的日志文件，这个命令通常仅仅用于第一次用于搭建主从关系的时的主库。

注意，reset master 不同于 purge binary log 的两处地方。

reset master 将删除日志索引文件中记录的所有 binlog 文件，创建一个新的日志文件起始值从 000001 开始，然而 purge binary log 命令并不会修改记录 binlog 的顺序的数值。

reset master 不能用于有任何 slave 正在运行的主从关系的主库，因为在 slave 运行时刻 reset master 命令不被支持，reset master 将 master 的 binlog 从 000001 开始记录，slave 记录的 master log 则是 reset master 时主库的最新的 binlog，从库会报错无法找的指定的 binlog 文件。

In MySQL 5.6.5 and later, RESET MASTER also clears the values of the gtid_purged system variable (known as gtid_lost in MySQL 5.6.8 and earlier) as well as the global value of the gtid_executed (gtid_done, prior to MySQL 5.6.9) system variable (but not its session value); that is, executing this statement sets each of these values to an empty string (”)

RESET SLAVE

RESET SLAVE 将使 slave 忘记主从复制关系的位置信息。该语句将被用于干净的启动，它删除 master.info 文件和 relay-log.info 文件以及所有的 relay log 文件并重新启用一个新的 relay log 文件。

使用 reset slave 之前必须使用 stop slave 命令将复制进程停止。

注：所有的 relay log 将被删除，不管他们是否被 SQL thread 进程完全应用(这种情况发生于备库延迟以及在备库执行了 stop slave 命令)，存储复制链接信息的 master.info 文件将被立即清除，如果 SQL thread 正在复制临时表的过程中，执行了 stop slave ，并且执行了 reset slave，这些被复制的临时表将被删除。

RESET SLAVE ALL

在 MySQL 5.6 版本中 reset slave 并不会清理存储于内存中的复制信息，比如 master host，master port，master user，or master password，也就是说如果没有使用 change master 命令做重新定向，执行 start slave 还是会指向旧的 master 上面。

当从库执行 reset slave 之后，将 mysqld shutdown 复制参数将被重置。

在 MySQL 5.6.3 版本以及以后使用使用 RESET SLAVE ALL 来完全的清理复制连接参数信息。(Bug #11809016)

RESET SLAVE ALL does not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. This issue is fixed in MySQL 5.7. (Bug #18816897)

In MySQL 5.6.7 and later, RESET SLAVE causes an implicit commit of an ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.

如果您觉得本站对你有帮助，那么可以支付宝扫码捐助以帮助本站更好地发展，在此谢过。