RESET {REPLICA | SLAVE} [ALL] [channel_option
]channel_option
: FOR CHANNELchannel
RESET REPLICA | SLAVE
makes the replica forget its position in the source's binary log. RESET REPLICA | SLAVE
使副本忘记其在源二进制日志中的位置。From MySQL 8.0.22, use 在MySQL 8.0.22中,使用RESET REPLICA
in place of RESET SLAVE
, which is deprecated from that release. RESET REPLICA
代替RESET SLAVE
,该版本不推荐使用RESET SLAVE
。In releases before MySQL 8.0.22, use 在MySQL 8.0.22之前的版本中,使用RESET SLAVE
.RESET SLAVE
。
This statement is meant to be used for a clean start; it clears the replication metadata repositories, deletes all the relay log files, and starts a new relay log file. 本声明旨在用于一个干净的开始;它清除复制元数据存储库,删除所有中继日志文件,并启动新的中继日志文件。It also resets to 0 the replication delay specified with the 它还将使用SOURCE_DELAY
| MASTER_DELAY
option of the CHANGE REPLICATION SOURCE TO
statement (from MySQL 8.0.23) or CHANGE MASTER TO
statement (before MySQL 8.0.23).CHANGE REPLICATION SOURCE TO
语句(从MySQL 8.0.23开始)或CHANGE MASTER TO
语句(在MySQL 8.0.23之前)的SOURCE_DELAY
| MASTER_DELAY
选项指定的复制延迟重置为0。
All relay log files are deleted, even if they have not been completely executed by the replication SQL thread. 所有中继日志文件都将被删除,即使它们尚未完全由复制SQL线程执行。(This is a condition likely to exist on a replica if you have issued a (如果您已发出STOP REPLICA | SLAVE
statement or if the replica is highly loaded.)STOP REPLICA | SLAVE
属语句或复制副本高负载,则复制副本上可能存在这种情况。)
For a server where GTIDs are in use (对于使用GTID的服务器(gtid_mode
is ON
), issuing RESET REPLICA | SLAVE
has no effect on the GTID execution history. gtid_mode
为ON
),发出RESET REPLICA | SLAVE
对GTID执行历史记录没有影响。The statement does not change the values of 该语句不会更改gtid_executed
or gtid_purged
, or the mysql.gtid_executed
table. gtid_executed
或gtid_purged
的值,也不会更改mysql.gtid_executed
表的值。If you need to reset the GTID execution history, use 如果需要重置GTID执行历史记录,请使用RESET MASTER
, even if the GTID-enabled server is a replica where binary logging is disabled.RESET MASTER
,即使启用GTID的服务器是禁用二进制日志记录的副本。
RESET REPLICA | SLAVE
requires the RELOAD
privilege.RESET REPLICA | SLAVE
需要RELOAD
权限。
To use 要使用RESET REPLICA | SLAVE
, the replication SQL thread and replication I/O thread must be stopped, so on a running replica use STOP REPLICA | SLAVE
before issuing RESET REPLICA | SLAVE
. RESET REPLICA | SLAVE
,必须停止复制SQL线程和复制I/O线程,因此在运行的副本上,在发出RESET REPLICA | SLAVE
之前使用STOP REPLICA | SLAVE
。To use 要在组复制组成员上使用RESET REPLICA | 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. RESET REPLICA | SLAVE
,成员状态必须为OFFLINE
(脱机),这意味着插件已加载,但该成员当前不属于任何组。A group member can be taken offline by using a 可以使用STOP GROUP REPLICATION
statement.STOP GROUP REPLICATION
语句使组成员脱机。
The optional 可选的FOR CHANNEL
clause enables you to name which replication channel the statement applies to. channel
FOR CHANNEL
子句允许您命名语句应用于哪个复制通道。channel
Providing a 提供FOR CHANNEL
clause applies the channel
RESET REPLICA | SLAVE
statement to a specific replication channel. FOR CHANNEL channel
子句将RESET REPLICA | SLAVE
语句应用于特定的复制通道。Combining a 将FOR CHANNEL
clause with the channel
ALL
option deletes the specified channel. FOR CHANNEL channel
子句与ALL
选项组合将删除指定的通道。If no channel is named and no extra channels exist, the statement applies to the default channel. 如果未命名通道且不存在额外通道,则该语句将应用于默认通道。Issuing a 当存在多个复制通道时,在没有RESET REPLICA | SLAVE ALL
statement without a FOR CHANNEL
clause when multiple replication channels exist deletes all replication channels and recreates only the default channel. channel
FOR CHANNEL channel
子句的情况下发出RESET REPLICA | SLAVE ALL
语句将删除所有复制通道,并仅重新创建默认通道。See Section 17.2.2, “Replication Channels” for more information.有关更多信息,请参阅第17.2.2节,“复制通道”。
RESET REPLICA | SLAVE
does not change any replication connection parameters, which include the source's host name and port, the replication user account and its password, the PRIVILEGE_CHECKS_USER
account, the REQUIRE_ROW_FORMAT
option, the REQUIRE_TABLE_PRIMARY_KEY_CHECK
option, and the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
option. RESET REPLICA | SLAVE
不会更改任何复制连接参数,包括源的主机名和端口、复制用户帐户及其密码、PRIVILEGE_CHECKS_USER
帐户、REQUIRE_ROW_FORMAT
选项、REQUIRE_TABLE_PRIMARY_KEY_CHECK
选项和ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
选项。If you want to change any of the replication connection parameters, you can do this using a 如果要更改任何复制连接参数,可以在服务器启动后使用CHANGE REPLICATION SOURCE TO
statement (from MySQL 8.0.23) or CHANGE MASTER TO
statement (before MySQL 8.0.23) after the server start. CHANGE REPLICATION SOURCE TO
语句(从MySQL 8.0.23开始)或CHANGE MASTER TO
语句(在MySQL 8.0.23之前)。If you want to remove all of the replication connection parameters, use 如果要删除所有复制连接参数,请使用RESET REPLICA | SLAVE ALL
. RESET REPLICA | SLAVE ALL
。RESET REPLICA | SLAVE ALL
also clears the IGNORE_SERVER_IDS
list set by CHANGE REPLICATION SOURCE TO
| CHANGE MASTER TO
. RESET REPLICA | SLAVE ALL
还会通过CHANGE REPLICATION SOURCE TO
|CHANGE MASTER TO
来清除IGNORE_SERVER_IDS
列表集。When you have used 当你使用了RESET REPLICA | SLAVE ALL
, if you want to use the instance as a replica again, you need to issue a CHANGE REPLICATION SOURCE TO
| CHANGE MASTER TO
statement after the server start to specify new connection parameters.RESET REPLICA | SLAVE ALL
之后,如果你想要再次使用实例作为复本,你需要在服务器开始指定新连接参数后,发出CHANGE REPLICATION SOURCE TO
|CHANGE MASTER TO
。
In the event of an unexpected server exit or deliberate restart after issuing 如果在发出RESET REPLICA | SLAVE
but before issuing START REPLICA | SLAVE
, retention of the replication connection parameters depends on the repository used for the replication metadata:RESET REPLICA | SLAVE
之后但在发出START REPLICA | SLAVE
之前发生意外的服务器退出或故意重新启动,复制连接参数的保留取决于用于复制元数据的存储库:
When 在服务器上设置master_info_repository=TABLE
and relay_log_info_repository=TABLE
are set on the server (which are the default settings from MySQL 8.0), replication connection parameters are preserved in the crash-safe InnoDB
tables mysql.slave_master_info
and mysql.slave_relay_log_info
as part of the RESET REPLICA | SLAVE
operation. master_info_repository=TABLE
和relay_log_info_repository=TABLE
(这是MySQL 8.0中的默认设置)时,复制连接参数将保留在崩溃安全的InnoDB
表mysql.slave_master_info
和mysql.slave_relay_log_info
中,作为RESET REPLICA | SLAVE
操作的一部分。They are also retained in memory. 它们也被保存在内存中。In the event of an unexpected server exit or deliberate restart after issuing 如果在发出RESET REPLICA | SLAVE
but before issuing START REPLICA | SLAVE
, the replication connection parameters are retrieved from the tables and reapplied to the channel. RESET REPLICA | SLAVE
之后但在发出START REPLICA | SLAVE
之前出现意外的服务器退出或故意重新启动,则会从表中检索复制连接参数,并重新应用于通道。This situation applies from MySQL 8.0.13 for the connection metadata repository, and from MySQL 8.0.19 for the applier metadata repository.这种情况在MySQL 8.0.13中适用于连接元数据存储库,在MySQL 8.0.19中适用于applier元数据存储库。
If 如果在服务器上设置了master_info_repository=FILE
and relay_log_info_repository=FILE
are set on the server, which is deprecated from MySQL 8.0, or the MySQL Server release is earlier than those specified above, replication connection parameters are only retained in memory. master_info_repository=FILE
和relay_log_info_repository=FILE
(MySQL 8.0不推荐使用),或者MySQL服务器版本早于上述指定版本,则复制连接参数仅保留在内存中。If the replica mysqld is restarted immediately after issuing 如果由于意外的服务器退出或故意重新启动,在发出RESET REPLICA | SLAVE
due to an unexpected server exit or deliberate restart, the connection parameters are lost. RESET REPLICA | SLAVE
后立即重新启动副本mysqld
,则连接参数将丢失。In that case, you must issue a 在这种情况下,您必须在服务器启动后发出CHANGE REPLICATION SOURCE TO
statement (from MySQL 8.0.23) or CHANGE MASTER TO
statement (before MySQL 8.0.23) after the server start to respecify the connection parameters before issuing START REPLICA | SLAVE
.CHANGE REPLICATION SOURCE TO
语句(从MySQL 8.0.23开始)或CHANGE MASTER TO
语句(在MySQL 8.0.23之前),以在发出START REPLICA | SLAVE
之前重新指定连接参数。
RESET REPLICA | SLAVE
does not change any replication filter settings (such as --replicate-ignore-table
) for channels affected by the statement. RESET REPLICA | SLAVE
不会更改受语句影响的通道的任何复制筛选器设置(例如--replicate-ignore-table
)。However, 但是,RESET REPLICA | SLAVE ALL
removes the replication filters that were set on the channels deleted by the statement. RESET REPLICA | SLAVE ALL
将删除在该语句删除的通道上设置的复制筛选器。When the deleted channel or channels are recreated, any global replication filters specified for the replica are copied to them, and no channel specific replication filters are applied. 当重新创建已删除的一个或多个通道时,为复制副本指定的任何全局复制筛选器都将复制到它们,并且不会应用任何特定于通道的复制筛选器。For more information see Section 17.2.5.4, “Replication Channel Based Filters”.有关更多信息,请参阅第17.2.5.4节,“基于复制通道的筛选器”。
RESET REPLICA | SLAVE
causes an implicit commit of an ongoing transaction. RESET REPLICA | SLAVE
导致正在进行的事务的隐式提交。See Section 13.3.3, “Statements That Cause an Implicit Commit”.请参阅第13.3.3节,“导致隐式提交的语句”。
If the replication SQL thread was in the middle of replicating temporary tables when it was stopped, and 如果复制SQL线程处于停止时复制临时表的中间,并发出了RESET REPLICA | SLAVE
is issued, these replicated temporary tables are deleted on the replica.RESET REPLICA | SLAV
,则复制的临时表将被删除。
RESET REPLICA | SLAVE
does not reset the heartbeat period or SSL_VERIFY_SERVER_CERT
.RESET REPLICA | SLAVE
不重置心跳周期或SSL_VERIFY_SERVER_CERT
。
When used on an NDB Cluster replica SQL node, 在NDB群集副本SQL节点上使用时,RESET REPLICA | SLAVE
clears the mysql.ndb_apply_status
table. RESET REPLICA | SLAVE
会清除mysql.ndb_apply_status
表。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 cluster.ndb_apply_status
使用NDB
存储引擎,因此由连接到集群的所有SQL节点共享。
You can override this behavior by issuing 在执行SET
GLOBAL @@
ndb_clear_apply_status=OFF
prior to executing RESET REPLICA | SLAVE
, which keeps the replica from purging the ndb_apply_status
table in such cases.RESET REPLICA | SLAVE
之前,您可以通过发出SET GLOBAL@@ndb_clear_apply_status=OFF
来重写此行为,在这种情况下,此命令可防止副本清除ndb_apply_status
表。