Documentation Home

13.4.2.4 RESET SLAVE 语句

RESET SLAVE [ALL] [channel_option]

channel_option:
    FOR CHANNEL channel

RESET SLAVE使副本忘记它在源的二进制日志中的复制位置。此语句用于干净启动:它清除复制元数据存储库,删除所有中继日志文件,并启动一个新的中继日志文件。MASTER_DELAY它还将使用选项指定的复制延迟重置为 0 CHANGE MASTER TO

笔记

所有中继日志文件都被删除,即使它们还没有被复制 SQL 线程完全执行。(如果您已发出 STOP SLAVE声明或副本负载很高,则副本可能存在这种情况。)

对于正在使用 GTID 的服务器 ( gtid_modeis ON),发布RESET SLAVE对 GTID 执行历史没有影响。该语句不会更改 gtid_executedor gtid_purgedmysql.gtid_executed表的值。如果您需要重置 GTID 执行历史记录,请使用RESET MASTER,即使启用 GTID 的服务器是禁用二进制日志记录的副本。

RESET SLAVE需要 RELOAD特权。

To use RESET SLAVE, the replication threads must be stopped, so on a running replica use STOP SLAVE before issuing RESET SLAVE. To use RESET SLAVE on a Group Replication group member, the member status must be OFFLINE, meaning that the plugin is loaded but the member does not currently belong to any group. A group member can be taken offline by using a STOP GROUP REPLICATION statement.

The optional FOR CHANNEL channel clause enables you to name which replication channel the statement applies to. Providing a FOR CHANNEL channel clause applies the RESET SLAVE statement to a specific replication channel. Combining a FOR CHANNEL channel clause with the ALL option deletes the specified channel. If no channel is named and no extra channels exist, the statement applies to the default channel. Issuing a RESET SLAVE ALL statement without a FOR CHANNEL channel clause when multiple replication channels exist deletes all replication channels and recreates only the default channel. See Section 16.2.2, “Replication Channels” for more information.

RESET SLAVE不会更改任何复制连接参数,例如源的主机名和端口,或者复制用户帐户名及其密码。

  • 从 MySQL 5.7.24 开始,当 master_info_repository=TABLE 在服务器上设置时,复制连接参数作为操作的一部分 保存在崩溃安全InnoDB表 中。它们也保留在内存中。如果服务器在发出后但发出前意外退出或故意重启 ,将从表中检索复制连接参数并重新用于新连接。 mysql.slave_master_infoRESET SLAVERESET SLAVESTART SLAVE

  • When master_info_repository=FILE is set on the server (which is the default in MySQL 5.7), replication connection parameters are only retained in memory. If the replica mysqld is restarted immediately after issuing RESET SLAVE due to an unexpected server exit or deliberate restart, the connection parameters are lost. In that case, you must issue a CHANGE MASTER TO statement after the server start to respecify the connection parameters before issuing START SLAVE.

If you want to reset the connection parameters intentionally, you need to use RESET SLAVE ALL, which clears the connection parameters. In that case, you must issue a CHANGE MASTER TO statement after the server start to specify the new connection parameters.

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

If the replication SQL thread was in the middle of replicating temporary tables when it was stopped, and RESET SLAVE is issued, these replicated temporary tables are deleted on the replica.

Prior to MySQL 5.7.5, RESET SLAVE also had the effect of resetting both the heartbeat period (Slave_heartbeat_period) and SSL_VERIFY_SERVER_CERT. This issue is fixed in MySQL 5.7.5 and later. (Bug #18777899, Bug #18778485)

Prior to MySQL 5.7.5, RESET SLAVE ALL did not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. In MySQL 5.7.5 and later, the statement clears the list. (Bug #18816897)

Note

When used on an NDB Cluster replica SQL node, RESET SLAVE clears the mysql.ndb_apply_status table. You should keep in mind when using this statement that ndb_apply_status uses the NDB storage engine and so is shared by all SQL nodes attached to the replica cluster.

You can override this behavior by issuing SET GLOBAL @@ndb_clear_apply_status=OFF prior to executing RESET SLAVE, which keeps the replica from purging the ndb_apply_status table in such cases.