RESET SLAVE [ALL] [channel_option]
channel_option:
FOR CHANNEL channel
RESET SLAVE
使副本忘记它在源的二进制日志中的复制位置。此语句用于干净启动:它清除复制元数据存储库,删除所有中继日志文件,并启动一个新的中继日志文件。MASTER_DELAY
它还将使用选项指定的复制延迟重置为 0
CHANGE MASTER
TO
。
所有中继日志文件都被删除,即使它们还没有被复制 SQL 线程完全执行。(如果您已发出
STOP SLAVE
声明或副本负载很高,则副本可能存在这种情况。)
对于正在使用 GTID 的服务器 ( gtid_mode
is
ON
),发布RESET
SLAVE
对 GTID 执行历史没有影响。该语句不会更改
gtid_executed
or
gtid_purged
或
mysql.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
clause enables you
to name which replication channel the statement applies to.
Providing a channel
FOR CHANNEL
clause applies the
channel
RESET SLAVE
statement to a specific
replication channel. Combining a FOR CHANNEL
clause with the
channel
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
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.
channel
RESET SLAVE
不会更改任何复制连接参数,例如源的主机名和端口,或者复制用户帐户名及其密码。
从 MySQL 5.7.24 开始,当
master_info_repository=TABLE
在服务器上设置时,复制连接参数作为操作的一部分 保存在崩溃安全InnoDB
表 中。它们也保留在内存中。如果服务器在发出后但发出前意外退出或故意重启 ,将从表中检索复制连接参数并重新用于新连接。mysql.slave_master_info
RESET SLAVE
RESET SLAVE
START 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 issuingRESET SLAVE
due to an unexpected server exit or deliberate restart, the connection parameters are lost. In that case, you must issue aCHANGE MASTER TO
statement after the server start to respecify the connection parameters before issuingSTART 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)
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.