MySQL8 中文参考（六十二）

于 2024-06-26 11:14:32 发布
阅读量705 收藏 28
点赞数 18
CC 4.0 BY-SA版权
分类专栏： mysql 文章标签： mysql
License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译
本文链接：https://blog.csdn.net/wizardforcel/article/details/139984255

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

15.3.7 SET TRANSACTION 语句

原文：dev.mysql.com/doc/refman/8.0/en/set-transaction.html

SET [GLOBAL | SESSION] TRANSACTION
    *transaction_characteristic* [, *transaction_characteristic*] ...

*transaction_characteristic*: {
    ISOLATION LEVEL *level*
  | *access_mode*
}

*level*: {
     REPEATABLE READ
   | READ COMMITTED
   | READ UNCOMMITTED
   | SERIALIZABLE
}

*access_mode*: {
     READ WRITE
   | READ ONLY
}

此语句指定了事务 特性。它接受一个由逗号分隔的一个或多个特性值的列表。每个特性值设置事务的隔离级别 或访问模式。隔离级别用于对InnoDB 表进行操作。访问模式指定事务是以读/写模式还是只读模式运行。

此外，SET TRANSACTION 可以包括一个可选的GLOBAL或SESSION关键字，以指示语句的范围。

  • 事务隔离级别

  • 事务访问模式

  • 事务特性范围

事务隔离级别

要设置事务隔离级别，请使用ISOLATION LEVEL *level*子句。不允许在同一SET TRANSACTION 语句中指定多个ISOLATION LEVEL子句。

默认隔离级别是REPEATABLE READ。其他允许的值是READ COMMITTED、READ UNCOMMITTED 和SERIALIZABLE。有关这些隔离级别的信息，请参见第 17.7.2.1 节，“事务隔离级别”。

事务访问模式

要设置事务访问模式，请使用READ WRITE或READ ONLY子句。不允许在同一SET TRANSACTION 语句中指定多个访问模式子句。

默认情况下，事务以读/写模式进行，允许对事务中使用的表进行读取和写入。可以使用具有READ WRITE访问模式的SET TRANSACTION 明确指定此模式。

如果事务访问模式设置为READ ONLY，则禁止对表进行更改。这可能使存储引擎能够进行性能改进，这些改进在不允许写入时可能是可能的。

在只读模式下，仍然可以使用 DML 语句更改使用 TEMPORARY 关键字创建的表。使用 DDL 语句进行的更改是不允许的，就像永久表一样。

也可以使用 START TRANSACTION 语句为单个事务指定 READ WRITE 和 READ ONLY 访问模式。

事务特性范围

您可以全局设置事务特性，为当前会话或仅限于下一个事务：

  • 使用 GLOBAL 关键字：

    • 该语句全局适用于所有后续会话。

    • 现有会话不受影响。

  • 使用 SESSION 关键字：

    • 该语句适用于当前会话中执行的所有后续事务。

    • 该语句允许在事务内部执行，但不影响当前正在进行的事务。

    • 如果在事务之间执行，则该语句将覆盖设置下一个事务值的任何先前语句。

  • 没有任何 SESSION 或 GLOBAL 关键字：

    • 该语句仅适用于会话中执行的下一个单个事务。

    • 后续事务将恢复使用命名特性的会话值。

    • 该语句不允许在事务内部执行：

      mysql> START TRANSACTION;
Query OK, 0 rows affected (0.02 sec)

mysql> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
ERROR 1568 (25001): Transaction characteristics can't be changed
while a transaction is in progress

更改全局事务特性需要 CONNECTION_ADMIN 权限（或已弃用的 SUPER 权限）。任何会话都可以自由更改其会话特性（即使在事务中间），或者更改其下一个事务的特性（在该事务开始之前）。

要在服务器启动时设置全局隔离级别，请在命令行或选项文件中使用 --transaction-isolation=*level* 选项。此选项的 level 值使用破折号而不是空格，因此可接受的值为 READ-UNCOMMITTED、READ-COMMITTED、REPEATABLE-READ 或 SERIALIZABLE。

同样，要在服务器启动时设置全局事务访问模式，请使用 --transaction-read-only 选项。默认值为 OFF（读/写模式），但该值可以设置为 ON 以进行只读模式。

例如，要将隔离级别设置为 REPEATABLE READ 并将访问模式设置为 READ WRITE，请在选项文件的 [mysqld] 部分中使用以下行：

[mysqld]
transaction-isolation = REPEATABLE-READ
transaction-read-only = OFF

在运行时，可以间接地使用SET TRANSACTION语句设置全局、会话和下一个事务范围级别的特征，如前所述。也可以直接使用SET语句为transaction_isolation和transaction_read_only系统变量赋值来直接设置它们：

  • SET TRANSACTION允许在不同范围级别设置事务特征时使用可选的GLOBAL和SESSION关键字。

  • 用于为transaction_isolation和transaction_read_only系统变量赋值的SET语句具有在不同范围级别设置这些变量的语法。

以下表格显示了每个SET TRANSACTION和变量赋值语法设置的特征范围级别。

表 15.9 事务特征的 SET TRANSACTION 语法

语法受影响的特征范围
SET GLOBAL TRANSACTION *transaction_characteristic*全局
SET SESSION TRANSACTION *transaction_characteristic*会话
SET TRANSACTION *transaction_characteristic*仅适用于下一个事务

表 15.10 事务特征的 SET 语法

语法受影响的特征范围
SET GLOBAL *var_name* = *value*全局
SET @@GLOBAL.*var_name* = *value*全局
SET PERSIST *var_name* = *value*全局
SET @@PERSIST.*var_name* = *value*全局
SET PERSIST_ONLY *var_name* = *value*无运行时效果
SET @@PERSIST_ONLY.*var_name* = *value*无运行时效果
SET SESSION *var_name* = *value*会话
SET @@SESSION.*var_name* = *value*会话
SET *var_name* = *value*会话
SET @@*var_name* = *value*仅适用于下一个事务
语法受影响的特征范围

可以在运行时检查事务特征的全局和会话值：

SELECT @@GLOBAL.transaction_isolation, @@GLOBAL.transaction_read_only;
SELECT @@SESSION.transaction_isolation, @@SESSION.transaction_read_only;

15.3.8 XA 事务

原文：dev.mysql.com/doc/refman/8.0/en/xa.html

15.3.8.1 XA 事务 SQL 语句

15.3.8.2 XA 事务状态

15.3.8.3 XA 事务的限制

InnoDB存储引擎支持 XA 事务。MySQL 的 XA 实现基于 X/Open CAE 文档Distributed Transaction Processing: The XA Specification。该文档由 The Open Group 发布，可在www.opengroup.org/public/pubs/catalog/c193.htm获取。当前 XA 实现的限制在第 15.3.8.3 节“XA 事务的限制”中描述。

在客户端方面，没有特殊要求。MySQL 服务器的 XA 接口由以XA关键字开头的 SQL 语句组成。MySQL 客户端程序必须能够发送 SQL 语句并理解 XA 语句接口的语义。它们不需要链接到最新的客户端库。旧的客户端库也可以工作。

在 MySQL Connectors 中，MySQL Connector/J 5.0.0 及更高版本直接支持 XA，通过一个处理 XA SQL 语句接口的类接口。

XA 支持分布式事务，即允许多个独立的事务资源参与全局事务。事务资源通常是关系型数据库，但也可能是其他类型的资源。

一个全局事务涉及几个本身是事务性的操作，但所有这些操作必须作为一个组要么全部成功完成，要么全部回滚。实质上，这将 ACID 属性“提升”到一个更高的级别，以便多个 ACID 事务可以作为全局操作的组成部分一起执行，并且也具有 ACID 属性。（与非分布式事务一样，如果您的应用程序对读现象敏感，可能更喜欢SERIALIZABLE。REPEATABLE READ可能对分布式事务不够。）

一些分布式事务的例子：

  • 一个应用程序可以充当一个集成工具，将消息服务与关系型数据库结合在一起。该应用程序确保处理涉及消息发送、检索和处理的事务，同时涉及事务性数据库，都发生在一个全局事务中。你可以将其视为“事务性电子邮件”。

  • 一个应用程序执行涉及不同数据库服务器的操作，例如 MySQL 服务器和 Oracle 服务器（或多个 MySQL 服务器），其中涉及多个服务器的操作必须作为全局事务的一部分进行，而不是作为每个服务器本地的单独事务。

  • 一家银行在关系数据库管理系统（RDBMS）中保留账户信息，并通过自动取款机（ATM）分发和接收资金。必须确保 ATM 操作在账户中正确反映，但这不能仅通过 RDBMS 完成。全局事务管理器整合 ATM 和数据库资源，以确保金融交易的整体一致性。

使用全局事务的应用程序涉及一个或多个资源管理器和一个事务管理器：

  • 资源管理器（RM）提供对事务资源的访问。数据库服务器是资源管理器的一种。必须能够提交或回滚由 RM 管理的事务。

  • 事务管理器（TM）协调作为全局事务一部分的事务。它与处理每个事务的 RM 进行通信。全局事务及其分支由稍后描述的命名方案标识。

MySQL 对 XA 的实现使 MySQL 服务器能够充当处理全局事务中的 XA 事务的资源管理器。连接到 MySQL 服务器的客户端程序充当事务管理器。

要执行全局事务，必须知道涉及哪些组件，并使每个组件达到可以提交或回滚的状态。根据每个组件报告的关于其成功能力的情况，它们必须作为一个原子组提交或回滚。也就是说，要么所有组件都必须提交，要么所有组件都必须回滚。要管理全局事务，必须考虑到任何组件或连接网络可能会失败。

执行全局事务的过程使用两阶段提交（2PC）。这发生在执行全局事务的分支执行的操作之后。

  1. 在第一阶段，所有分支都被准备好了。也就是说，它们被 TM 告知准备好提交。通常，这意味着每个管理分支的 RM 在稳定存储中记录了分支的操作。这些分支指示它们是否能够这样做，这些结果将用于第二阶段。

  2. 在第二阶段，TM 告诉 RM 是否提交或回滚。如果所有分支在准备时指示它们能够提交，那么所有分支都被告知提交。如果任何分支在准备时指示它不能提交，那么所有分支都被告知回滚。

在某些情况下，全局事务可能会使用一阶段提交（1PC）。例如，当事务管理器发现全局事务仅包含一个事务资源（即单个分支）时，可以要求该资源同时准备和提交。

原文：dev.mysql.com/doc/refman/8.0/en/xa-statements.html

15.3.8.1 XA 事务 SQL 语句

要在 MySQL 中执行 XA 事务，请使用以下语句：

XA {START|BEGIN} *xid* [JOIN|RESUME]

XA END *xid* [SUSPEND [FOR MIGRATE]]

XA PREPARE *xid*

XA COMMIT *xid* [ONE PHASE]

XA ROLLBACK *xid*

XA RECOVER [CONVERT XID]

对于 XA START，JOIN 和 RESUME 子句被识别但没有效果。

对于 XA END，SUSPEND [FOR MIGRATE] 子句被识别但没有效果。

每个 XA 语句都以 XA 关键字开头，大多数需要一个 xid 值。xid 是一个 XA 事务标识符。它指示语句适用于哪个事务。xid 值由客户端提供，或由 MySQL 服务器生成。xid 值有一到三部分：

*xid*: *gtrid* [, *bqual* [, *formatID* ]]

gtrid 是全局事务标识符，bqual 是分支限定符，formatID 是标识 gtrid 和 bqual 值使用的格式的数字。如语法所示，bqual 和 formatID 是可选的。如果未给出，默认 bqual 值为 ''。如果未给出，默认 formatID 值为 1。

gtrid 和 bqual 必须是字符串字面量，每个最多 64 字节（而非字符）长。gtrid 和 bqual 可以以几种方式指定。您可以使用带引号的字符串（'ab'）、十六进制字符串（X'6162'、0x6162）或位值（b'*nnnn*'）。

formatID 是一个无符号整数。

gtrid 和 bqual 值由 MySQL 服务器底层的 XA 支持程序解释为字节。然而，在解析包含 XA 语句的 SQL 语句时，服务器使用特定的字符集。为了安全起见，将 gtrid 和 bqual 写成十六进制字符串。

xid 值通常由事务管理器生成。一个事务管理器生成的值必须与其他事务管理器生成的值不同。给定的事务管理器必须能够在 XA RECOVER 语句返回的值列表中识别出自己的 xid 值。

XA START *xid* 使用给定的 xid 值启动一个 XA 事务。每个 XA 事务必须具有唯一的 xid 值，因此该值不能当前被另一个 XA 事务使用。使用 gtrid 和 bqual 值来评估唯一性。随后的所有 XA 语句必须使用与 XA START 语句中给定的 xid 值相同的 xid 值指定。如果您使用这些语句之一，但指定的 xid 值与某个现有 XA 事务不对应，则会发生错误。

从 MySQL 8.0.31 开始，当服务器运行时带有 --replicate-do-db 或 --replicate-ignore-db 时，XA START、XA BEGIN、XA END、XA COMMIT 和 XA ROLLBACK 语句不会被默认数据库过滤。

一个或多个 XA 事务可以是同一个全局事务的一部分。给定全局事务中的所有 XA 事务必须在 xid 值中使用相同的 gtrid 值。因此，gtrid 值必须是全局唯一的，以确保对于给定 XA 事务是哪个全局事务的一部分没有歧义。 xid 值的 bqual 部分必须对于全局事务中的每个 XA 事务都不同。 （bqual 值必须不同的要求是当前 MySQL XA 实现的限制。它不是 XA 规范的一部分。）

XA RECOVER 语句返回 MySQL 服务器上处于PREPARED状态的 XA 事务的信息。（参见 Section 15.3.8.2, “XA 事务状态”.）输出包括服务器上每个这样的 XA 事务的行，无论是哪个客户端启动的。

XA RECOVER 需要 XA_RECOVER_ADMIN 权限。这个权限要求阻止用户发现除了自己之外的未完成准备好的 XA 事务的 XID 值。它不影响 XA 事务的正常提交或回滚，因为启动它的用户知道它的 XID。

XA RECOVER 输出行如下（对于由部分 'abc'、'def' 和 7 组成的 xid 值的示例）：

mysql> XA RECOVER;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        7 |            3 |            3 | abcdef |
+----------+--------------+--------------+--------+

输出列的含义如下：

  • formatID 是事务 xid 的 formatID 部分

  • gtrid_length 是 xid 的 gtrid 部分的字节长度

  • bqual_length 是 xid 的 bqual 部分的字节长度

  • data 是 xid 的 gtrid 和 bqual 部分的串联

XID 值可能包含不可打印字符。XA RECOVER 允许一个可选的 CONVERT XID 子句，以便客户端可以请求十六进制的 XID 值。

原文：dev.mysql.com/doc/refman/8.0/en/xa-states.html

15.3.8.2 XA 事务状态

一个 XA 事务会经历以下状态：

  1. 使用 XA START 来启动一个 XA 事务并将其置于 ACTIVE 状态。

  2. 对于一个 ACTIVE 的 XA 事务，发出构成事务的 SQL 语句，然后发出 XA END 语句。XA END 将事务置于 IDLE 状态。

  3. 对于一个 IDLE 的 XA 事务，可以发出 XA PREPARE 语句或 XA COMMIT ... ONE PHASE 语句：

    • XA PREPARE 将事务置于 PREPARED 状态。此时，XA RECOVER 语句会在输出中包含事务的 xid 值，因为 XA RECOVER 列出所有处于 PREPARED 状态的 XA 事务。

    • XA COMMIT ... ONE PHASE 准备并提交事务。xid 值不会被 XA RECOVER 列出，因为事务已经终止。

  4. 对于一个 PREPARED 的 XA 事务，可以发出 XA COMMIT 语句来提交并终止事务，或者发出 XA ROLLBACK 来回滚并终止事务。

下面是一个简单的 XA 事务，作为全局事务的一部分向表中插入一行：

mysql> XA START 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO mytable (i) VALUES(10);
Query OK, 1 row affected (0.04 sec)

mysql> XA END 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec)

在 MySQL 8.0.28 及更早版本中，在给定客户端连接的上下文中，XA 事务和本地（非 XA）事务是互斥的。例如，如果已经发出 XA START 来开始一个 XA 事务，那么在 XA 事务提交或回滚之前不能启动本地事务。反之，如果已经使用 START TRANSACTION 开始了本地事务，那么在事务提交或回滚之前不能使用 XA 语句。

MySQL 8.0.29 及更高版本支持分离的 XA 事务，通过xa_detach_on_prepare系统变量启用（默认为ON）。分离的事务在执行XA PREPARE后与当前会话断开连接（可以由另一个连接提交或回滚）。这意味着当前会话可以自由开始新的本地事务或 XA 事务，而无需等待准备的 XA 事务被提交或回滚。

当 XA 事务被分离时，一个连接对其准备的任何 XA 事务没有特殊知识。如果当前会话尝试提交或回滚给定的 XA 事务（即使是它准备的），在另一个连接已经这样做之后，请求将被拒绝，并显示无效的 XID 错误（ER_XAER_NOTA），因为请求的*xid*不再存在。

注意

分离的 XA 事务不能使用临时表。

当禁用分离的 XA 事务（xa_detach_on_prepare设置为OFF）时，一个 XA 事务会保持连接，直到由发起连接提交或回滚，就像之前描述的 MySQL 8.0.28 及更早版本一样。不建议为用于组复制的 MySQL 服务器实例禁用分离的 XA 事务；有关更多信息，请参阅服务器实例配置。

如果一个 XA 事务处于ACTIVE状态，你不能发出任何导致隐式提交的语句。这将违反 XA 协议，因为你无法回滚 XA 事务。尝试执行这样的语句会引发以下错误：

ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed
when global transaction is in the ACTIVE state

适用于前述备注的语句列在第 15.3.3 节，“导致隐式提交的语句”中。

原文：dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html

15.3.8.3 XA 事务的限制

XA 事务支持仅限于InnoDB存储引擎。

对于“外部 XA”，一个 MySQL 服务器充当资源管理器，客户端程序充当事务管理器。对于“内部 XA”，MySQL 服务器内的存储引擎充当 RMs，服务器本身充当 TM。内部 XA 支持受到各个存储引擎能力的限制。处理涉及多个存储引擎的 XA 事务需要内部 XA。实现内部 XA 要求存储引擎在表处理程序级别支持两阶段提交，目前只有InnoDB符合这一要求。

对于XA START，识别JOIN和RESUME子句但不起作用。

对于XA END，识别SUSPEND [FOR MIGRATE]子句但不起作用。

要求xid值的bqual部分在全局事务中的每个 XA 事务中不同是当前 MySQL XA 实现的限制。这不是 XA 规范的一部分。

XA 事务分两部分写入二进制日志。当发出XA PREPARE时，事务的第一部分直到XA PREPARE使用初始 GTID 写入。XA_prepare_log_event用于在二进制日志中标识这类事务。当发出XA COMMIT或XA ROLLBACK时，包含仅XA COMMIT或XA ROLLBACK语句的事务的第二部分使用第二个 GTID 写入。请注意，由XA_prepare_log_event标识的事务的初始部分不一定会跟随其XA COMMIT或XA ROLLBACK，这可能导致任意两个 XA 事务的二进制日志交错记录。XA 事务的两部分甚至可以出现在不同的二进制日志文件中。这意味着处于PREPARED状态的 XA 事务现在持久存在，直到发出显式的XA COMMIT或XA ROLLBACK语句，确保 XA 事务与复制兼容。

在副本上，在 XA 事务准备完成后，它会从复制应用程序线程中分离，并可以由副本上的任何线程提交或回滚。这意味着相同的 XA 事务可以在不同线程上以不同状态出现在events_transactions_current表中。events_transactions_current表显示线程上最近监视的事务事件的当前状态，并在线程空闲时不更新此状态。因此，即使在被另一个线程处理后，XA 事务仍可能以PREPARED状态显示在原始应用程序线程中。要明确识别仍处于PREPARED状态且需要恢复的 XA 事务，请使用XA RECOVER语句，而不是性能模式事务表。

使用 XA 事务存在以下限制：

  • 在 MySQL 8.0.30 之前，XA 事务在意外停机时对于二进制日志不是完全具有弹性。如果在服务器正在执行XA PREPARE、XA COMMIT、XA ROLLBACK或XA COMMIT ... ONE PHASE语句时发生意外停机，服务器可能无法恢复到正确状态，导致服务器和二进制日志处于不一致状态。在这种情况下，二进制日志可能包含未应用的额外 XA 事务，或者缺少已应用的 XA 事务。此外，如果启用了 GTIDs，在恢复后，@@GLOBAL.GTID_EXECUTED可能无法正确描述已应用的事务。请注意，如果在XA PREPARE之前、在XA PREPARE和XA COMMIT（或XA ROLLBACK）之间，或在XA COMMIT（或XA ROLLBACK）之后发生意外停机，则服务器和二进制日志将正确恢复并处于一致状态。

    从 MySQL 8.0.30 开始，这不再是一个问题；服务器将XA PREPARE实现为一个两阶段操作，它在存储引擎和服务器之间维护准备操作的状态，并在存储引擎和二进制日志之间强制执行执行顺序，以便在服务器节点上的状态在一致和持久之前不进行广播。

    请注意，当使用相同的事务 XID 依次执行 XA 事务并且在处理 XA COMMIT ... ONE PHASE 过程中发生中断时，可能无法再同步二进制日志和存储引擎之间的状态。如果在此事务在存储引擎中准备后发生了刚描述的一系列事件，而 XA COMMIT 语句仍在执行，则可能会发生这种情况。这是一个已知问题。

  • 不支持在 XA 事务中使用复制过滤器或二进制日志过滤器。对表的过滤可能导致副本上的 XA 事务为空，并且不支持空的 XA 事务。此外，副本的连接元数据存储库和应用程序元数据存储库存储在 InnoDB 表中，这在 MySQL 8.0 中成为默认设置，过滤的 XA 事务会改变数据引擎事务的内部状态，并可能与复制事务上下文状态不一致。

    当 XA 事务受到复制过滤器的影响时，无论事务是否为空，都会记录错误 ER_XA_REPLICATION_FILTERS。如果事务不为空，则副本可以继续运行，但您应该采取措施停止使用 XA 事务的复制过滤器以避免潜在问题。如果事务为空，则副本将停止。在这种情况下，副本可能处于一个不确定的状态，其中复制过程的一致性可能会受到损害。特别是，副本的 gtid_executed 集合可能与源端不一致。要解决这种情况，请隔离源端并停止所有复制，然后检查复制拓扑结构中的 GTID 一致性。撤消生成错误消息的 XA 事务，然后重新启动复制。

  • XA 事务被认为对于基于语句的复制是不安全的。如果在源端并行提交了两个 XA 事务，并且在副本上以相反的顺序准备这些事务，可能会发生无法安全解决的锁定依赖关系，并且复制可能会因副本上的死锁而失败。这种情况可能发生在单线程或多线程副本上。当设置 binlog_format=STATEMENT 时，对于 XA 事务中的 DML 语句会发出警告。当设置 binlog_format=MIXED 或 binlog_format=ROW 时，XA 事务中的 DML 语句将使用基于行的复制进行记录，潜在问题将不再存在。

15.4 复制语句

原文：dev.mysql.com/doc/refman/8.0/en/sql-replication-statements.html

15.4.1 控制源服务器的 SQL 语句

15.4.2 控制副本服务器的 SQL 语句

15.4.3 控制组复制的 SQL 语句

通过本节描述的语句，可以通过 SQL 接口控制复制。语句分为控制源服务器的组，控制副本服务器的组，以及可应用于任何复制服务器的组。

15.4.1 用于控制源服务器的 SQL 语句

原文：dev.mysql.com/doc/refman/8.0/en/replication-statements-master.html

15.4.1.1 清除二进制日志语句

15.4.1.2 重置主服务器语句

15.4.1.3 设置 sql_log_bin 语句

本节讨论了用于管理复制源服务器的语句。第 15.4.2 节，“用于控制副本服务器的 SQL 语句”，讨论了用于管理副本服务器的语句。

除了这里描述的语句外，以下SHOW语句用于在复制中与源服务器一起使用。有关这些语句的信息，请参阅第 15.7.7 节，“显示语句”。

  • SHOW BINARY LOGS

  • SHOW BINLOG EVENTS

  • SHOW MASTER STATUS

  • SHOW REPLICAS（或在 MySQL 8.0.22 之前，SHOW SLAVE HOSTS）

原文：dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html

15.4.1.1 PURGE BINARY LOGS Statement
PURGE { BINARY | MASTER } LOGS {
    TO '*log_name*'
  | BEFORE *datetime_expr*
}

二进制日志是一组文件，其中包含 MySQL 服务器进行的数据修改的信息。该日志由一组二进制日志文件和一个索引文件组成（参见 第 7.4.4 节，“二进制日志”）。

PURGE BINARY LOGS 语句删除日志索引文件中指定日志文件名或日期之前列出的所有二进制日志文件。BINARY 和 MASTER 是同义词。删除的日志文件也会从索引文件中记录的列表中移除，因此给定的日志文件将成为列表中的第一个。

运行 PURGE BINARY LOGS 需要 BINLOG_ADMIN 权限。如果服务器没有使用 --log-bin 选项启动以启用二进制日志记录，则此语句无效。

示例：

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';

BEFORE 变体的 datetime_expr 参数应该评估为一个 DATETIME 值（一个以 '*YYYY-MM-DD hh:mm:ss*' 格式表示的值）。

当副本正在复制时，可以安全地运行 PURGE BINARY LOGS。你不需要停止它们。如果你有一个活动的副本，当前正在读取你尝试删除的日志文件之一，这个语句不会删除正在使用的日志文件或比它更晚的任何日志文件，但会删除任何更早的日志文件。在这种情况下会发出警告消息。然而，如果一个副本没有连接，并且你碰巧清除了它尚未读取的日志文件之一，那么在重新连接后，该副本无法复制。

在实例生效 LOCK INSTANCE FOR BACKUP 语句时，不应该执行 PURGE BINARY LOGS，因为这违反了备份锁的规则，会从服务器中删除文件。从 MySQL 8.0.28 开始，这是不允许的。

要安全地清除二进制日志文件，请按照以下步骤进行：

  1. 在每个副本上，使用 SHOW REPLICA STATUS 来检查它正在读取哪个日志文件。

  2. 使用 SHOW BINARY LOGS 在源上获取二进制日志文件的列表。

  3. 确定所有副本中最早的日志文件。这是目标文件。如果所有副本都是最新的，那么这是列表中的最后一个日志文件。

  4. 备份即将删除的所有日志文件。（此步骤是可选的，但始终建议执行。）

  5. 清除所有日志文件，但不包括目标文件。

PURGE BINARY LOGS TO 和 PURGE BINARY LOGS BEFORE 在二进制日志文件列表中的文件已经通过其他方式（比如在 Linux 上使用rm）被移除系统时会出现错误（Bug #18199, Bug #18453）。为了处理这种错误，需要手动编辑.index文件（这是一个简单的文本文件），确保它只列出实际存在的二进制日志文件，然后重新运行失败的PURGE BINARY LOGS语句。

服务器的二进制日志到期后会自动删除二进制日志文件。文件的删除可以在启动时和二进制日志刷新时进行。默认的二进制日志到期时间为 30 天。您可以使用binlog_expire_logs_seconds系统变量指定替代的到期时间。如果您正在使用复制，应该指定一个到期时间，不低于从源头落后的最长时间。

原文：dev.mysql.com/doc/refman/8.0/en/reset-master.html

15.4.1.2 RESET MASTER Statement
RESET MASTER [TO *binary_log_file_index_number*]

警告

谨慎使用此语句，以确保不会丢失任何需要的二进制日志文件数据和 GTID 执行历史记录。

RESET MASTER需要RELOAD权限。

对于启用了二进制日志记录的服务器（log_bin为ON），RESET MASTER会删除所有现有的二进制日志文件并重置二进制日志索引文件，将服务器重置为启动二进制日志记录之前的状态。会创建一个新的空二进制日志文件，以便重新启动二进制日志记录。

对于使用 GTIDs 的服务器（gtid_mode为ON），发出RESET MASTER会重置 GTID 执行历史记录。gtid_purged系统变量的值设置为空字符串（''），gtid_executed系统变量的全局值（但不是会话值）设置为空字符串，并清除mysql.gtid_executed表（参见 mysql.gtid_executed Table）。如果启用了 GTID 的服务器启用了二进制日志记录，RESET MASTER也会像上面描述的那样重置二进制日志。请注意，即使启用了 GTID 的服务器是一个禁用了二进制日志记录的副本，RESET MASTER也是重置 GTID 执行历史记录的方法；RESET REPLICA对 GTID 执行历史记录没有影响。有关重置 GTID 执行历史记录的更多信息，请参阅重置 GTID 执行历史记录。

发出不带可选TO子句的RESET MASTER会删除索引文件中列出的所有二进制日志文件，将二进制日志索引文件重置为空，并创建一个从1开始的新二进制日志文件。在重置后，可以使用可选的TO子句从不是1的数字开始二进制日志文件索引。

确保您使用了合理的索引号值。如果输入了不正确的值，您可以通过发出带有或不带有TO子句的另一个RESET MASTER语句来更正。如果不更正超出范围的值，服务器将无法重新启动。

以下示例演示了TO子句的用法：

RESET MASTER TO 1234;

SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name          | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 |       154 | No        |
+-------------------+-----------+-----------+

重要提示

不带TO子句的RESET MASTER的效果与PURGE BINARY LOGS的效果有 2 个关键区别：

  1. RESET MASTER会删除索引文件中列出的所有二进制日志文件，只留下一个带有数字后缀.000001的空二进制日志文件，而编号不会被PURGE BINARY LOGS重置。

  2. 当任何副本正在运行时，不应使用RESET MASTER。在副本正在运行时使用RESET MASTER的行为是未定义的（因此不受支持），而可以在副本正在运行时安全地使用PURGE BINARY LOGS。

另请参阅 Section 15.4.1.1, “PURGE BINARY LOGS Statement”。

在首次设置源和副本时，执行不带TO子句的RESET MASTER可能会很有用，以便您可以验证设置如下：

  1. 启动源和副本，并开始复制（参见 Section 19.1.2, “Setting Up Binary Log File Position Based Replication”）。

  2. 在源上执行几个测试查询。

  3. 检查查询是否已被复制到副本。

  4. 当复制正常运行时，在副本上依次执行STOP REPLICA，然后执行RESET REPLICA，然后验证副本上不存在来自测试查询的不需要的数据。

  5. 从源中删除不需要的数据，然后执行RESET MASTER以清除与其关联的任何二进制日志条目和标识符。

在验证设置、重置源和副本并确保源或副本上没有任何不需要的数据或测试生成的二进制日志文件后，您可以启动副本并开始复制。

原文：dev.mysql.com/doc/refman/8.0/en/set-sql-log-bin.html

15.4.1.3 SET sql_log_bin 语句
SET sql_log_bin = {OFF|ON}

sql_log_bin变量控制当前会话是否启用二进制日志记录（假设二进制日志本身已启用）。默认值为ON。要为当前会话禁用或启用二进制日志记录，请将会话sql_log_bin变量设置为OFF或ON。

将此变量设置为OFF，以便在对源进行更改时暂时禁用二进制日志记录，而这些更改不希望被复制到副本中。

设置此系统变量的会话值是受限制的操作。会话用户必须具有足够的特权来设置受限制的会话变量。请参阅第 7.1.9.1 节，“系统变量特权”。

不可能在事务或子查询中设置sql_log_bin的会话值。

将此变量设置为OFF会阻止新的 GTID 分配给二进制日志中的事务。如果您正在使用 GTID 进行复制，这意味着即使稍后重新启用二进制日志记录，从此时点开始写入日志的 GTID 也不会考虑期间发生的任何事务，因此实际上这些事务将丢失。

mysqldump向使用 GTID 的服务器的转储文件中添加SET @@SESSION.sql_log_bin=0语句，这会在重新加载转储文件时禁用二进制日志记录。该语句阻止生成新的 GTID 并将其分配给执行时的转储文件中的事务，以便使用事务的原始 GTID。

15.4.2 用于控制 REPLICA 服务器的 SQL 语句

原文：dev.mysql.com/doc/refman/8.0/en/replication-statements-replica.html

15.4.2.1 更改主服务器 TO 语句

15.4.2.2 更改复制过滤器语句

15.4.2.3 更改复制源 TO 语句

15.4.2.4 重置 REPLICA 语句

15.4.2.5 重置 SLAVE 语句

15.4.2.6 启动 REPLICA 语句

15.4.2.7 启动 SLAVE 语句

15.4.2.8 停止 REPLICA 语句

15.4.2.9 停止 SLAVE 语句

本节讨论了用于管理 REPLICA 服务器的语句。第 15.4.1 节，“用于控制源服务器的 SQL 语句”，讨论了用于管理源服务器的语句。

除了这里描述的语句外，SHOW REPLICA STATUS 和 SHOW RELAYLOG EVENTS 也与 REPLICA 一起使用。有关这些语句的信息，请参阅 第 15.7.7.35 节，“显示 REPLICA 状态语句” 和 第 15.7.7.32 节，“显示 RELAYLOG 事件语句”。

原文：dev.mysql.com/doc/refman/8.0/en/change-master-to.html

15.4.2.1 更改主服务器语句
CHANGE MASTER TO *option* [, *option*] ... [ *channel_option* ]

*option*: {
    MASTER_BIND = '*interface_name*'
  | MASTER_HOST = '*host_name*'
  | MASTER_USER = '*user_name*'
  | MASTER_PASSWORD = '*password*'
  | MASTER_PORT = *port_num*
  | PRIVILEGE_CHECKS_USER = {'*account*' | NULL}
  | REQUIRE_ROW_FORMAT = {0|1}
  | REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF}
  | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | *uuid*}
  | MASTER_LOG_FILE = '*source_log_name*'
  | MASTER_LOG_POS = *source_log_pos*
  | MASTER_AUTO_POSITION = {0|1}
  | RELAY_LOG_FILE = '*relay_log_name*'
  | RELAY_LOG_POS = *relay_log_pos*
  | MASTER_HEARTBEAT_PERIOD = *interval*
  | MASTER_CONNECT_RETRY = *interval*
  | MASTER_RETRY_COUNT = *count*
  | SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}
  | MASTER_DELAY = *interval*
  | MASTER_COMPRESSION_ALGORITHMS = '*algorithm*[,*algorithm*][,*algorithm*]'
  | MASTER_ZSTD_COMPRESSION_LEVEL = *level*
  | MASTER_SSL = {0|1}
  | MASTER_SSL_CA = '*ca_file_name*'
  | MASTER_SSL_CAPATH = '*ca_directory_name*'
  | MASTER_SSL_CERT = '*cert_file_name*'
  | MASTER_SSL_CRL = '*crl_file_name*'
  | MASTER_SSL_CRLPATH = '*crl_directory_name*'
  | MASTER_SSL_KEY = '*key_file_name*'
  | MASTER_SSL_CIPHER = '*cipher_list*'
  | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}
  | MASTER_TLS_VERSION = '*protocol_list*'
  | MASTER_TLS_CIPHERSUITES = '*ciphersuite_list*'
  | MASTER_PUBLIC_KEY_PATH = '*key_file_name*'
  | GET_MASTER_PUBLIC_KEY = {0|1}
  | NETWORK_NAMESPACE = '*namespace*'
  | IGNORE_SERVER_IDS = (*server_id_list*),
  | GTID_ONLY = {0|1}
}

*channel_option*:
    FOR CHANNEL *channel*

*server_id_list*:
    [*server_id* [, *server_id*] ... ]

更改主服务器为更改了副本服务器用于连接到源和从源读取数据的参数。它还更新了复制元数据存储库的内容（参见第 19.2.4 节，“中继日志和复制元数据存储库”）。从 MySQL 8.0.23 开始，请使用更改复制源为代替更改主服务器为，该语句从该版本开始已弃用。在 MySQL 8.0.23 之前的版本中，请使用更改主服务器为。

更改主服务器为需要REPLICATION_SLAVE_ADMIN权限（或已弃用的SUPER权限）。

在更改主服务器为语句中未指定的选项保留其值，除非在以下讨论中另有说明。因此，在大多数情况下，没有必要指定不更改的选项。

用于SOURCE_HOST和其他更改复制源为选项的值将检查换行符（\n或0x0A）字符。这些值中存在这些字符会导致语句失败并显示错误。

可选的FOR CHANNEL *channel*子句使您能够命名语句适用于哪个复制通道。提供FOR CHANNEL *channel*子句将CHANGE MASTER TO语句应用于特定的复制通道，并用于添加新通道或修改现有通道。例如，要添加名为channel2的新通道：

CHANGE MASTER TO MASTER_HOST=host1, MASTER_PORT=3002 FOR CHANNEL 'channel2'

如果未命名任何子句且不存在额外通道，则更改主服务器为语句适用于默认通道，其名称为空字符串(“”)。当设置了多个复制通道时，每个更改主服务器为语句必须使用FOR CHANNEL *channel*子句命名通道。有关更多信息，请参见第 19.2.2 节，“复制通道”。

对于CHANGE MASTER TO语句的某些选项，您必须在发出CHANGE MASTER TO语句之前（以及之后发出START SLAVE语句）发出STOP SLAVE语句。有时，您只需要停止复制 SQL（应用程序）线程或复制 I/O（接收器）线程，而不是两者同时停止：

  • 当应用程序线程停止时，即使复制接收器线程正在运行，您也可以使用RELAY_LOG_FILE、RELAY_LOG_POS和MASTER_DELAY选项的任何允许组合执行CHANGE MASTER TO。当接收器线程正在运行时，不得使用此语句的其他选项。

  • 当接收器线程停止时，即使应用程序线程正在运行，您也可以使用此语句的任何选项（以任何允许的组合）执行CHANGE MASTER TO，除了 RELAY_LOG_FILE、RELAY_LOG_POS、MASTER_DELAY或MASTER_AUTO_POSITION = 1。

  • 在发出使用MASTER_AUTO_POSITION = 1、GTID_ONLY = 1或ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS的CHANGE MASTER TO语句之前，必须停止接收线程和应用线程。

您可以使用SHOW SLAVE STATUS检查复制应用程序线程和复制接收器线程的当前状态。请注意，Group Replication 应用程序通道（group_replication_applier）没有接收器线程，只有一个应用程序线程。

CHANGE MASTER TO语句具有许多副作用和交互作用，您应该事先了解：

  • CHANGE MASTER TO导致正在进行的事务的隐式提交。请参阅第 15.3.3 节，“导致隐式提交的语句”。

  • CHANGE MASTER TO会将先前的MASTER_HOST、MASTER_PORT、MASTER_LOG_FILE和MASTER_LOG_POS值写入错误日志，以及在执行之前有关副本状态的其他信息。

  • 如果您正在使用基于语句的复制和临时表，可能会出现在STOP SLAVE语句后跟随CHANGE MASTER TO语句时在副本上留下临时表的情况。每当发生这种情况时，都会发出警告（ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO）。在这种情况下，您可以通过确保在执行此类CHANGE MASTER TO语句之前，Replica_open_temp_tables或Slave_open_temp_tables系统状态变量的值等于 0 来避免这种情况。

  • 当使用多线程副本（replica_parallel_workers > 0 或 slave_parallel_workers > 0）时，停止副本可能会导致已从中继日志执行的事务序列中存在间隙，无论副本是有意还是无意地停止。当存在这样的间隙时，发出CHANGE MASTER TO将失败。在这种情况下的解决方案是发出START SLAVE UNTIL SQL_AFTER_MTS_GAPS，以确保关闭这些间隙。从 MySQL 8.0.26 开始，在使用基于 GTID 的复制和 GTID 自动定位时，完全跳过检查事务序列中的间隙的过程，因为可以使用 GTID 自动定位解决事务间隙。在这种情况下，仍然可以使用CHANGE MASTER TO。

CHANGE MASTER TO语句提供以下选项：

ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | *uuid*}

使复制通道为没有 GTID 的复制事务分配一个 GTID，从而实现从不使用基于 GTID 的复制的源到使用的副本的复制。对于多源副本，您可以同时使用使用ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS和不使用的通道。默认值为OFF，表示未使用该功能。

LOCAL分配一个包括副本自己的 UUID（server_uuid设置）的 GTID。*uuid*分配一个包括指定 UUID 的 GTID，例如用于复制源服务器的server_uuid设置。使用非本地 UUID 可以让您区分在副本上发起的事务和在源上发起的事务，以及对于多源副本，区分在不同源上发起的事务。您选择的 UUID 仅对副本自身的使用具有意义。如果源发送的任何事务已经具有 GTID，则保留该 GTID。

专用于组复制的通道不能使用ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS，但是服务器实例上另一个源的异步复制通道可以这样做。在这种情况下，不要将组复制组名称指定为用于创建 GTIDs 的 UUID。

要将ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS设置为LOCAL或*uuid*，副本必须设置gtid_mode=ON，且此后不能更改。此选项用于与基于二进制日志文件位置的复制的源一起使用，因此不能为通道设置MASTER_AUTO_POSITION=1。在设置此选项之前，必须停止复制 SQL 线程和复制 I/O（接收器）线程。

重要提示

在任何通道上设置了ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS的副本都不能晋升为替换复制源服务器的副本，如果需要故障转移，则无法使用从副本获取的备份来恢复复制源服务器。相同的限制也适用于替换或恢复其他使用任何通道上的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS的副本。

有关更多限制和信息，请参见第 19.1.3.6 节，“从没有 GTIDs 的源复制到具有 GTIDs 的副本”。

GET_MASTER_PUBLIC_KEY = {0|1}

通过从源请求公钥启用基于 RSA 密钥对的密码交换。此选项默认禁用。

此选项适用于使用caching_sha2_password认证插件进行身份验证的副本。对于使用此插件进行身份验证的帐户的连接，源不会发送公钥，除非请求，因此必须请求或在客户端中指定。如果给出MASTER_PUBLIC_KEY_PATH并指定有效的公钥文件，则它优先于GET_MASTER_PUBLIC_KEY。如果您使用使用caching_sha2_password插件进行身份验证的复制用户帐户（从 MySQL 8.0 开始为默认设置），并且不使用安全连接，则必须指定此选项或MASTER_PUBLIC_KEY_PATH选项之一以向副本提供 RSA 公钥。

GTID_ONLY = {0|1}

停止复制通道在复制元数据存储库中持久化文件名和文件位置。GTID_ONLY从 MySQL 8.0.27 版本开始提供。对于异步复制通道，默认情况下禁用GTID_ONLY选项，但对于 Group Replication 通道，默认情况下启用，并且无法禁用。

对于具有此设置的复制通道，仍然会跟踪内存中的文件位置，并且可以通过错误消息和诸如SHOW REPLICA STATUS语句等接口观察文件位置以进行调试（如果过时，则显示为无效）。但是，在 GTID 基础复制实际上不需要它们的情况下，包括事务排队和应用过程中，避免了持久化和检查文件位置所需的写入和读取。

仅当复制 SQL（applier）线程和复制 I/O（receiver）线程都停止时才能使用此选项。要为复制通道设置GTID_ONLY = 1，服务器必须使用 GTID（gtid_mode = ON），并且源必须使用基于行的二进制日志记录（不支持基于语句的复制）。必须为复制通道设置选项REQUIRE_ROW_FORMAT = 1和SOURCE_AUTO_POSITION = 1。

当设置GTID_ONLY = 1时，如果服务器的replica_parallel_workers=1系统变量设置为零，则副本使用单线程 applier，因此在技术上始终是多线程 applier。这是因为多线程 applier 使用保存的位置而不是复制元数据存储库来定位需要重新应用的事务的起始位置。

如果在设置后禁用GTID_ONLY，则会删除现有的中继日志，并持久化现有的已知二进制日志文件位置，即使它们已过时。复制元数据存储库中的二进制日志和中继日志的文件位置可能无效，如果是这种情况，则会返回警告。只要SOURCE_AUTO_POSITION仍然启用，就会使用 GTID 自动定位来提供正确的定位。

如果还禁用SOURCE_AUTO_POSITION，则在复制元数据存储库中，如果二进制日志和中继日志的文件位置有效，则用于定位。如果它们标记为无效，则必须提供有效的二进制日志文件名和位置（SOURCE_LOG_FILE和SOURCE_LOG_POS）。如果还提供中继日志文件名和位置（RELAY_LOG_FILE和RELAY_LOG_POS），则中继日志将被保留，并且应用程序位置将设置为指定位置。GTID 自动跳过确保任何已应用的事务即使最终的应用程序位置不正确也会被跳过。

IGNORE_SERVER_IDS = (*server_id_list*)

使复制品忽略来自指定服务器的事件。该选项接受一个逗号分隔的 0 或多个服务器 ID 的列表。来自服务器的日志轮换和删除事件不会被忽略，并记录在中继日志中。

在循环复制中，原始服务器通常充当其自己事件的终结者，以便它们不会被应用多次。因此，在循环复制中，当圈中的一个服务器被移除时，此选项很有用。假设您有一个带有服务器 ID 1、2、3 和 4 的 4 个服务器的循环复制设置，并且服务器 3 失效。在从服务器 2 开始到服务器 4 的复制中填补间隙时，您可以在服务器 4 上发出的CHANGE MASTER TO语句中包含IGNORE_SERVER_IDS = (3)，告诉它使用服务器 2 而不是服务器 3 作为其源。这样做会导致它忽略并不传播任何源自不再使用的服务器的语句。

如果IGNORE_SERVER_IDS包含服务器自己的 ID，并且服务器启动时启用了--replicate-same-server-id选项，则会导致错误。

注意

当全局事务标识符（GTID）用于复制时，已经应用的事务会自动被忽略，因此不需要使用IGNORE_SERVER_IDS功能，该功能已被弃用。如果为服务器设置了gtid_mode=ON，则在CHANGE MASTER TO语句中包含IGNORE_SERVER_IDS选项时会发出弃用警告。

源元数据存储库和SHOW REPLICA STATUS的输出提供了当前被忽略的服务器列表。有关更多信息，请参阅 Section 19.2.4.2, “Replication Metadata Repositories”和 Section 15.7.7.35, “SHOW REPLICA STATUS Statement”。

如果发出不带任何IGNORE_SERVER_IDS选项的CHANGE MASTER TO语句，则会保留任何现有的忽略服务器列表。要清除忽略服务器列表，必须使用带有空列表的选项：

CHANGE MASTER TO IGNORE_SERVER_IDS = ();

RESET REPLICA ALL会清除IGNORE_SERVER_IDS。

注意

如果在任何通道已设置带有IGNORE_SERVER_IDS的现有服务器 ID 时发出SET GTID_MODE=ON，则会发出弃用警告。在启动基于 GTID 的复制之前，请检查并清除涉及的服务器上的所有忽略服务器 ID 列表。SHOW REPLICA STATUS语句显示忽略 ID 列表（如果有）。如果收到弃用警告，您仍然可以通过发出包含带有空列表的IGNORE_SERVER_IDS选项的CHANGE MASTER TO语句来清除列表。

MASTER_AUTO_POSITION = {0|1}

使复制品尝试使用基于 GTID 的自动定位功能连接到源，而不是基于二进制日志文件的位置。此选项用于启动使用基于 GTID 的复制的复制品。默认值为 0，表示不使用 GTID 自动定位和基于 GTID 的复制。只有在停止复制 SQL（应用程序）线程和复制 I/O（接收器）线程时，才能将此选项与CHANGE MASTER TO一起使用。

复制品和源都必须启用 GTIDs（GTID_MODE=ON，ON_PERMISSIVE或OFF_PERMISSIVE在复制品上，以及源上的GTID_MODE=ON）。MASTER_LOG_FILE、MASTER_LOG_POS、RELAY_LOG_FILE和RELAY_LOG_POS不能与MASTER_AUTO_POSITION = 1一起指定。如果在复制品上启用了多源复制，您需要为每个适用的复制通道设置MASTER_AUTO_POSITION = 1选项。

设置MASTER_AUTO_POSITION = 1后，在初始连接握手中，复制品发送包含其已接收、已提交或两者都有的事务的 GTID 集。源会响应通过发送其二进制日志中的所有事务，其 GTID 未包含在复制品发送的 GTID 集中。此交换确保源仅发送复制品尚未记录或提交的具有 GTID 的事务。如果复制品从多个源接收事务，如钻石拓扑结构的情况下，自动跳过功能确保不会应用事务两次。有关复制品发送的 GTID 集如何计算的详细信息，请参见 Section 19.1.3.3, “GTID Auto-Positioning”。

如果应该由源发送的任何事务已从源的二进制日志中清除，或者通过其他方法添加到gtid_purged系统变量的 GTID 集合中，源将向副本发送错误ER_MASTER_HAS_PURGED_REQUIRED_GTIDS，并且复制不会启动。缺失的已清除事务的 GTID 将在源的错误日志中被识别并列在警告消息ER_FOUND_MISSING_GTIDS中。此外，如果在交换事务期间发现副本已记录或提交具有 GTID 中源 UUID 的事务，但源本身尚未提交它们，则源将向副本发送错误ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER，并且复制不会启动。有关如何处理这些情况的信息，请参见第 19.1.3.3 节，“GTID 自动定位”。

您可以通过检查 Performance Schema replication_connection_status表或SHOW REPLICA STATUS的输出来查看是否启用了 GTID 自动定位的复制正在运行。再次禁用MASTER_AUTO_POSITION选项会使副本恢复到基于文件的复制。

MASTER_BIND = '*interface_name*'

确定副本的哪个网络接口被选择用于连接到源，用于具有多个网络接口的副本。指定网络接口的 IP 地址。字符串值的最大长度为 255 个字符。

配置此选项的 IP 地址（如果有）可以在SHOW REPLICA STATUS输出的Master_Bind列中看到。在源元数据存储库表mysql.slave_master_info中，该值可以在Master_bind列中看到。将副本绑定到特定网络接口的能力也受到 NDB 集群的支持。

MASTER_COMPRESSION_ALGORITHMS = '*algorithm*[,*algorithm*][,*algorithm*]'

指定连接到复制源服务器的允许压缩算法中的一个、两个或三个，用逗号分隔。字符串值的最大长度为 99 个字符。默认值为uncompressed。

可用的算法是zlib、zstd和uncompressed，与protocol_compression_algorithms系统变量相同。算法可以以任何顺序指定，但这不是优先顺序 - 算法协商过程尝试使用zlib，然后zstd，然后uncompressed，如果它们被指定。MASTER_COMPRESSION_ALGORITHMS自 MySQL 8.0.18 起可用。

MASTER_COMPRESSION_ALGORITHMS的值仅在replica_compressed_protocol或slave_compressed_protocol系统变量被禁用时适用。如果replica_compressed_protocol或slave_compressed_protocol被启用，则优先于MASTER_COMPRESSION_ALGORITHMS，并且如果源和副本都支持该算法，则连接到源使用zlib压缩。有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。

二进制日志事务压缩（自 MySQL 8.0.20 起可用），由binlog_transaction_compression系统变量激活，也可用于节省带宽。如果与连接压缩结合使用，则连接压缩的机会减少作用于数据，但仍可以压缩标头以及未压缩的事件和事务有效载荷。有关二进制日志事务压缩的更多信息，请参见第 7.4.4.5 节，“二进制日志事务压缩”。

MASTER_CONNECT_RETRY = *interval*

指定副本在连接到源超时后进行重新连接尝试之间的秒数间隔。默认间隔为 60 秒。

尝试次数受MASTER_RETRY_COUNT选项限制。如果使用默认设置，副本在重新连接尝试之间等待 60 秒（MASTER_CONNECT_RETRY=60），并以这个速率继续尝试重新连接 60 天（MASTER_RETRY_COUNT=86400）。这些值记录在源元数据存储库中，并显示在replication_connection_configuration性能模式表中。

MASTER_DELAY = *interval*

指定副本必须滞后源多少秒。从源接收的事件要在至少*interval秒后才会在副本上执行。interval*必须是一个非负整数，范围从 0 到 2³¹−1。默认值为 0。更多信息，请参阅 Section 19.4.11, “Delayed Replication”。

当复制 SQL 线程停止时，可以在运行中的副本上执行使用MASTER_DELAY选项的CHANGE MASTER TO语句。

MASTER_HEARTBEAT_PERIOD = *interval*

控制心跳间隔，防止在连接仍然良好的情况下发生连接超时。在经过那么多秒后，会向副本发送一个心跳信号，并且每当源的二进制日志更新为一个事件时，等待时间就会被重置。因此，只有在二进制日志文件中有一段时间没有发送的事件时，源才会发送心跳。

心跳间隔*interval是一个十进制值，范围为 0 到 4294967 秒，分辨率为毫秒；最小的非零值为 0.001。将interval*设置为 0 会完全禁用心跳。心跳间隔默认为replica_net_timeout或slave_net_timeout系统变量值的一半。它记录在源元数据存储库中，并显示在replication_connection_configuration性能模式表中。

系统变量replica_net_timeout（从 MySQL 8.0.26 开始）或slave_net_timeout（在 MySQL 8.0.26 之前）指定了复制等待源端发送更多数据或心跳信号的秒数，超过这个时间，复制将认为连接已断开，中止读取，并尝试重新连接。默认值为 60 秒（一分钟）。请注意，对replica_net_timeout或slave_net_timeout的值或默认设置的更改不会自动更改心跳间隔，无论是显式设置还是使用先前计算的默认值。如果将全局值replica_net_timeout或slave_net_timeout设置为小于当前心跳间隔的值，将发出警告。如果更改了replica_net_timeout或slave_net_timeout，还必须发出CHANGE MASTER TO以将心跳间隔调整为适当的值，以便在连接超时之前发生心跳信号。如果不这样做，心跳信号将不起作用，如果没有从源端接收到数据，复制可能会进行重复的重新连接尝试，创建僵尸转储线程。

MASTER_HOST = '*host_name*'

复制源服务器的主机名或 IP 地址。复制使用此信息连接到源端。字符串值的最大长度为 255 个字符。在 MySQL 8.0.17 之前为 60 个字符。

如果指定了MASTER_HOST或MASTER_PORT，则复制将假定源服务器与以前不同（即使选项值与当前值相同）。在这种情况下，源端二进制日志文件名和位置的旧值被认为不再适用，因此如果在语句中不指定MASTER_LOG_FILE和MASTER_LOG_POS，则会自动附加MASTER_LOG_FILE=''和MASTER_LOG_POS=4。

将MASTER_HOST=''设置为（即将其值显式设置为空字符串）不等同于根本不设置MASTER_HOST。尝试将MASTER_HOST设置为空字符串将导致错误。

MASTER_LOG_FILE = '*source_log_name*'，MASTER_LOG_POS = *source_log_pos*

二进制日志文件名以及复制 I/O（接收器）线程从源端二进制日志中读取的位置，下次线程启动时开始读取。如果使用基于二进制日志文件位置的复制，请指定这些选项。

MASTER_LOG_FILE必须包括源服务器上可用的特定二进制日志文件的数字后缀，例如，MASTER_LOG_FILE='binlog.000145'。字符串值的最大长度为 511 个字符。

MASTER_LOG_POS是副本在该文件中开始读取的数字位置。MASTER_LOG_POS=4表示二进制日志文件中事件的开始。

如果指定了MASTER_LOG_FILE或MASTER_LOG_POS中的任一项，则不能指定MASTER_AUTO_POSITION = 1，该选项用于基于 GTID 的复制。

如果未指定MASTER_LOG_FILE或MASTER_LOG_POS中的任一项，则副本使用复制 SQL（应用程序）线程在发出CHANGE MASTER TO之前的最后坐标。这确保即使复制 SQL（应用程序）线程相对于复制 I/O（接收器）线程较晚，也不会在复制中出现不连续。

MASTER_PASSWORD = '*password*'

用于连接到复制源服务器的复制用户帐户的密码。字符串值的最大长度为 32 个字符。如果指定了MASTER_PASSWORD，则还需要MASTER_USER。

在CHANGE MASTER TO语句中用于复制用户帐户的密码长度限制为 32 个字符。尝试使用超过 32 个字符的密码会导致CHANGE MASTER TO失败。

密码在 MySQL 服务器的日志、性能模式表和SHOW PROCESSLIST语句中被掩码。

MASTER_PORT = *port_num*

副本用于连接到复制源服务器的 TCP/IP 端口号。

注意

复制不能使用 Unix 套接字文件。您必须能够使用 TCP/IP 连接到复制源服务器。

如果指定了MASTER_HOST或MASTER_PORT，则副本会假定源服务器与之前不同（即使选项值与当前值相同）。在这种情况下，源二进制日志文件名和位置的旧值被视为不再适用，因此如果在语句中未指定MASTER_LOG_FILE和MASTER_LOG_POS，则会自动附加MASTER_LOG_FILE=''和MASTER_LOG_POS=4。

MASTER_PUBLIC_KEY_PATH = '*key_file_name*'

通过提供包含源端所需的公钥副本的文件的路径名，启用基于 RSA 密钥对的密码交换。该文件必须采用 PEM 格式。字符串值的最大长度为 511 个字符。

此选项适用于使用sha256_password或caching_sha2_password认证插件进行身份验证的复制品。（对于sha256_password，只有在使用 OpenSSL 构建 MySQL 时才能使用MASTER_PUBLIC_KEY_PATH。）如果您使用的是使用caching_sha2_password插件进行身份验证的复制用户帐户（这是 MySQL 8.0 的默认设置），并且您没有使用安全连接，则必须指定此选项或GET_MASTER_PUBLIC_KEY=1选项以向复制品提供 RSA 公钥。

MASTER_RETRY_COUNT = *count*

设置复制品在连接到源之后超时的最大重连尝试次数，由replica_net_timeout或slave_net_timeout系统变量确定。如果复制品确实需要重新连接，则第一次重试会在超时后立即发生。默认值为 86400 次尝试。

尝试之间的间隔由MASTER_CONNECT_RETRY选项指定。如果使用默认设置，复制品在重新连接尝试之间等待 60 秒（MASTER_CONNECT_RETRY=60），并以此速率继续尝试重新连接 60 天（MASTER_RETRY_COUNT=86400）。将MASTER_RETRY_COUNT设置为 0 意味着没有限制重新连接尝试次数，因此复制品将无限尝试重新连接。

MASTER_CONNECT_RETRY和MASTER_RETRY_COUNT的值记录在源元数据存储库中，并显示在replication_connection_configuration性能模式表中。MASTER_RETRY_COUNT取代了--master-retry-count服务器启动选项。

MASTER_SSL = {0|1}

指定复制品是否加密复制连接。默认值为 0，表示复制品不加密复制连接。如果设置MASTER_SSL=1，则可以使用MASTER_SSL_*xxx*和MASTER_TLS_*xxx*选项配置加密。

为复制连接设置MASTER_SSL=1，然后不设置更多的MASTER_SSL_*xxx*选项相当于为客户端设置--ssl-mode=REQUIRED，如加密连接的命令选项中所述。使用MASTER_SSL=1，连接尝试仅在可以建立加密连接时成功。复制连接不会退回到未加密连接，因此没有与复制相对应的--ssl-mode=PREFERRED设置。如果设置了MASTER_SSL=0，则相当于--ssl-mode=DISABLED。

重要

为了帮助防止复杂的中间人攻击，重要的是副本要验证服务器的身份。您可以指定额外的MASTER_SSL_*xxx*选项，对应设置--ssl-mode=VERIFY_CA和--ssl-mode=VERIFY_IDENTITY，这比默认设置更好，有助于防止这种类型的攻击。使用这些设置，副本会检查服务器的证书是否有效，并检查副本正在使用的主机名是否与服务器证书中的身份匹配。要实施这些验证级别之一，必须首先确保服务器的 CA 证书可靠地可用于副本，否则会导致可用性问题。因此，它们不是默认设置。

MASTER_SSL_*xxx*，MASTER_TLS_*xxx*

指定副本如何使用加密和密码来保护复制连接。即使在没有 SSL 支持的副本上也可以更改这些选项。它们保存在源元数据存储库中，但如果副本没有启用 SSL 支持，则会被忽略。字符串值的MASTER_SSL_*xxx*和MASTER_TLS_*xxx*选项的值的最大长度为 511 个字符，MASTER_TLS_CIPHERSUITES除外，其长度为 4000 个字符。

MASTER_SSL_*xxx*和MASTER_TLS_*xxx*选项执行与加密连接的命令选项中描述的--ssl-*xxx*和--tls-*xxx*客户端选项相同的功能。两组选项之间的对应关系，以及使用MASTER_SSL_*xxx*和MASTER_TLS_*xxx*选项建立安全连接的方法，在第 19.3.1 节，“设置复制使用加密连接”中有解释。

MASTER_USER = '*user_name*'

用于连接到复制源服务器的复制用户帐户的用户名。字符串值的最大长度为 96 个字符。

对于组复制，此帐户必须存在于复制组的每个成员中。如果 XCom 通信堆栈用于组，则用于分布式恢复，如果 MySQL 通信堆栈用于组，则用于组通信连接。对于 MySQL 通信堆栈，帐户必须具有GROUP_REPLICATION_STREAM权限。

可以通过指定MASTER_USER=''来设置空用户名称，但不能使用空用户名称启动复制通道。在 MySQL 8.0.21 之前的版本中，只有在出于安全目的需要清除先前使用的凭据时才设置空的MASTER_USER用户名称。不要在之后使用通道，因为在这些版本中存在一个错误，如果从存储库中读取到空用户名称（例如，在自动重新启动组复制通道期间），则可能会替换默认用户名称。从 MySQL 8.0.21 开始，可以设置空的MASTER_USER用户名称，并在之后使用通道，只要始终使用START REPLICA语句或START GROUP_REPLICATION语句提供用户凭据启动复制通道。这种方法意味着复制通道始终需要操作员干预才能重新启动，但用户凭据不会记录在复制元数据存储库中。

重要

要使用使用caching_sha2_password插件进行身份验证的复制用户帐户连接到源，必须设置安全连接，如 Section 19.3.1, “Setting Up Replication to Use Encrypted Connections”中所述，或启用不加密的连接以支持使用 RSA 密钥对进行密码交换。caching_sha2_password身份验证插件是从 MySQL 8.0 开始新用户的默认插件（有关详细信息，请参见 Section 8.4.1.2, “Caching SHA-2 Pluggable Authentication”）。如果您创建或使用用于复制的用户帐户使用此身份验证插件，并且未使用安全连接，则必须启用基于 RSA 密钥对的密码交换才能成功连接。您可以使用此语句的MASTER_PUBLIC_KEY_PATH选项或GET_MASTER_PUBLIC_KEY=1选项来执行此操作。

MASTER_ZSTD_COMPRESSION_LEVEL = *level*

用于使用zstd压缩算法的与复制源服务器连接的压缩级别。允许的级别为 1 到 22，较大的值表示较高级别的压缩。默认级别为 3。MASTER_ZSTD_COMPRESSION_LEVEL自 MySQL 8.0.18 起可用。

压缩级别设置对不使用zstd压缩的连接没有影响。有关更多信息，请参见 Section 6.2.8, “Connection Compression Control”。

NETWORK_NAMESPACE = '*namespace*'

用于 TCP/IP 连接到复制源服务器或者如果使用 MySQL 通信堆栈，则用于 Group Replication 的组通信连接的网络命名空间。字符串值的最大长度为 64 个字符。如果省略此选项，则副本的连接将使用默认（全局）命名空间。在不实现网络命名空间支持的平台上，当副本尝试连接到源时会发生故障。有关网络命名空间的信息，请参见 第 7.1.14 节，“网络命名空间支持”。NETWORK_NAMESPACE 自 MySQL 8.0.22 版本起可用。

PRIVILEGE_CHECKS_USER = {NULL | '*account*'}

为指定通道提供安全上下文的用户帐户名称。NULL 是默认值，表示不使用安全上下文。PRIVILEGE_CHECKS_USER 自 MySQL 8.0.18 版本起可用。

用户帐户的用户名和主机名必须遵循 第 8.2.4 节，“指定帐户名称” 中描述的语法，并且用户不能是匿名用户（具有空白用户名）或 CURRENT_USER。该帐户必须具有 REPLICATION_APPLIER 权限，以及执行在通道上复制的事务所需的权限。有关帐户所需权限的详细信息，请参见 第 19.3.3 节，“复制权限检查”。重新启动复制通道时，权限检查将从那一点开始应用。如果您不指定通道且没有其他通道存在，则该语句将应用于默认通道。

当设置了 PRIVILEGE_CHECKS_USER 时，强烈建议使用基于行的二进制日志记录，并且您可以设置 REQUIRE_ROW_FORMAT 来强制执行此操作。例如，要在运行中的副本上启动通道 channel_1 上的权限检查，请执行以下语句：

mysql> STOP REPLICA FOR CHANNEL 'channel_1';
mysql> CHANGE MASTER TO
         PRIVILEGE_CHECKS_USER = '*priv_repl*'@'*%.example.com*',
         REQUIRE_ROW_FORMAT = 1,
         FOR CHANNEL 'channel_1';
mysql> START REPLICA FOR CHANNEL 'channel_1';

对于 MySQL 8.0.22 版本及更高版本，请使用 START REPLICA 和 STOP REPLICA，对于 MySQL 8.0.22 版本之前的版本，请使用 START SLAVE 和 STOP SLAVE。这些语句的工作方式相同，只是术语发生了变化。

RELAY_LOG_FILE = '*relay_log_file*'，RELAY_LOG_POS = '*relay_log_pos*'

中继日志文件名以及在该文件中的位置，复制 SQL 线程在下次启动时从副本的中继日志中开始读取的位置。RELAY_LOG_FILE 可以使用绝对路径或相对路径，并且使用与 MASTER_LOG_FILE 相同的基本名称。字符串值的最大长度为 511 个字符。

在运行副本时，可以在停止复制 SQL 线程时执行使用RELAY_LOG_FILE、RELAY_LOG_POS或两个选项的CHANGE MASTER TO语句。如果至少有一个复制 SQL（应用程序）线程和复制 I/O（接收器）线程正在运行，则保留中继日志。如果两个线程都停止，则除非至少指定RELAY_LOG_FILE或RELAY_LOG_POS中的一个，否则所有中继日志文件都将被删除。对于仅具有应用程序线程而没有接收器线程的 Group Replication 应用程序通道（group_replication_applier），如果应用程序线程停止，那么这种情况就是，但是对于该通道，您不能使用RELAY_LOG_FILE和RELAY_LOG_POS选项。

REQUIRE_ROW_FORMAT = {0|1}

仅允许通过复制通道处理基于行的复制事件。此选项防止复制应用程序执行诸如创建临时表和执行LOAD DATA INFILE请求等操作，从而增加通道的安全性。默认情况下，异步复制通道禁用REQUIRE_ROW_FORMAT选项，但默认情况下启用 Group Replication 通道，并且不能禁用它们。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。REQUIRE_ROW_FORMAT自 MySQL 8.0.19 起可用。

REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF}

启用副本选择自己的主键检查策略。默认值为STREAM。REQUIRE_TABLE_PRIMARY_KEY_CHECK自 MySQL 8.0.20 起可用。

当为复制通道设置选项为ON时，副本始终在复制操作中使用sql_require_primary_key系统变量的值为ON，需要主键。当选项设置为OFF时，副本始终在复制操作中使用sql_require_primary_key系统变量的值为OFF，因此即使源需要主键，也不需要主键。当REQUIRE_TABLE_PRIMARY_KEY_CHECK选项设置为STREAM时，这是默认值，副本使用从源复制的每个事务的任何值。

对于多源复制，将REQUIRE_TABLE_PRIMARY_KEY_CHECK设置为ON或OFF使副本能够规范不同源的复制通道的行为，并保持sql_require_primary_key系统变量的一致设置。使用ON可以防止在多个源更新相同的表集时意外丢失主键。使用OFF允许可以操作主键的源与不能操作主键的源一起工作。

当设置PRIVILEGE_CHECKS_USER时，将REQUIRE_TABLE_PRIMARY_KEY_CHECK设置为ON或OFF意味着用户帐户无需会话管理级别权限即可设置受限制的会话变量，这些变量是必需的，以便更改sql_require_primary_key的值以匹配每个事务的源设置。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。

SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}

如果有一个或多个备用复制源服务器可用（即有多个共享复制数据的 MySQL 服务器或服务器组），则为复制通道激活异步连接故障转移机制。SOURCE_CONNECTION_AUTO_FAILOVER从 MySQL 8.0.22 版本开始可用。默认值为 0，表示未激活该机制。有关完整信息和设置此功能的说明，请参见第 19.4.9.2 节，“副本的异步连接故障转移”。

异步连接故障转移机制在由MASTER_CONNECT_RETRY和MASTER_RETRY_COUNT控制的重连尝试耗尽后接管。它会将副本重新连接到一个从指定源列表中选择的备用源，您可以使用asynchronous_connection_failover_add_source和asynchronous_connection_failover_delete_source函数来管理这些源。要添加和删除受管理的服务器组，请改用asynchronous_connection_failover_add_managed和asynchronous_connection_failover_delete_managed函数。有关更多信息，请参见第 19.4.9 节，“使用异步连接故障转移切换源和副本”。

重要提示

  1. 只有在使用 GTID 自动定位（MASTER_AUTO_POSITION = 1）时才能设置SOURCE_CONNECTION_AUTO_FAILOVER = 1。

  2. 当你设置SOURCE_CONNECTION_AUTO_FAILOVER = 1时，将MASTER_RETRY_COUNT和MASTER_CONNECT_RETRY设置为最小值，只允许在短时间内对同一源进行几次重试尝试，以防连接故障是由瞬时网络中断引起的。否则，异步连接故障转移机制无法及时激活。适当的值为MASTER_RETRY_COUNT=3和MASTER_CONNECT_RETRY=10，这使得副本在每次连接尝试之间间隔 10 秒的情况下重试连接 3 次。

  3. 当你设置SOURCE_CONNECTION_AUTO_FAILOVER = 1时，复制元数据存储库必须包含用于连接到复制通道源列表上的所有服务器的复制用户帐户的凭据。可以使用带有MASTER_USER和MASTER_PASSWORD选项的CHANGE REPLICATION SOURCE TO语句来设置这些凭据。更多信息，请参见第 19.4.9 节，“使用异步连接故障转移切换源和副本”。

  4. 从 MySQL 8.0.27 开始，当你设置SOURCE_CONNECTION_AUTO_FAILOVER = 1时，如果此复制通道位于单主模式中的组复制主服务器上，则自动激活副本的异步连接故障转移。启用此功能后，如果正在复制的主服务器下线或进入错误状态，新的主服务器在选举时会在同一通道上开始复制。如果要使用此功能，此复制通道还必须在复制组中的所有辅助服务器上设置，并在任何新加入的成员上设置。（如果使用 MySQL 的克隆功能进行服务器配置，则所有这些都会自动完成。）如果不想使用此功能，请使用group_replication_disable_member_action函数来禁用默认启用的 Group Replication 成员操作mysql_start_failover_channels_if_primary。更多信息，请参见第 19.4.9.2 节，“副本的异步连接故障转移”。

示例

当您拥有源的快照并记录了与快照时间对应的源二进制日志坐标时，CHANGE MASTER TO对于设置副本非常有用。在将快照加载到副本以与源同步之后，您可以在副本上运行CHANGE MASTER TO MASTER_LOG_FILE='*log_name*', MASTER_LOG_POS=*log_pos*来指定副本应开始读取源二进制日志的坐标。以下示例更改了副本使用的源服务器，并建立了副本开始读取源二进制日志的源二进制日志坐标：

CHANGE MASTER TO
  MASTER_HOST='source2.example.com',
  MASTER_USER='replication',
  MASTER_PASSWORD='*password*',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='source2-bin.001',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10;

要在故障切换期间将现有副本切换到新源的过程，请参见第 19.4.8 节，“故障切换期间切换源”。

当源和副本上使用 GTID 时，请指定 GTID 自动定位，而不是给出二进制日志文件位置，如下例所示。有关在新服务器、已停止服务器、在线服务器或其他副本上配置和启动基于 GTID 的复制的完整说明，请参见第 19.1.3 节，“具有全局事务标识符的复制”。

CHANGE MASTER TO
  MASTER_HOST='source3.example.com',
  MASTER_USER='replication',
  MASTER_PASSWORD='*password*',
  MASTER_PORT=3306,
  MASTER_AUTO_POSITION = 1,
  FOR CHANNEL "source_3";

在此示例中，使用了多源复制，并且CHANGE MASTER TO语句应用于连接副本与指定主机的复制通道"source_3"。有关设置多源复制的指导，请参见第 19.1.5 节，“MySQL 多源复制”。

下一个示例显示了如何使副本应用要重复的中继日志文件中的事务。为此，源不需要可达。您可以使用CHANGE MASTER TO来定位副本应开始重新应用事务的中继日志位置，然后启动 SQL 线程：

CHANGE MASTER TO
  RELAY_LOG_FILE='replica-relay-bin.006',
  RELAY_LOG_POS=4025;
START SLAVE SQL_THREAD;

CHANGE MASTER TO也可用于跳过导致复制停止的二进制日志中的事务。执行此操作的适当方法取决于是否使用 GTID。有关使用CHANGE MASTER TO或其他方法跳过事务的说明，请参见第 19.1.7.3 节，“跳过事务”。

原文：dev.mysql.com/doc/refman/8.0/en/change-replication-filter.html

15.4.2.2 CHANGE REPLICATION FILTER Statement
CHANGE REPLICATION FILTER *filter*[, *filter*]
	[, ...] [FOR CHANNEL *channel*]

*filter*: {
    REPLICATE_DO_DB = (*db_list*)
  | REPLICATE_IGNORE_DB = (*db_list*)
  | REPLICATE_DO_TABLE = (*tbl_list*)
  | REPLICATE_IGNORE_TABLE = (*tbl_list*)
  | REPLICATE_WILD_DO_TABLE = (*wild_tbl_list*)
  | REPLICATE_WILD_IGNORE_TABLE = (*wild_tbl_list*)
  | REPLICATE_REWRITE_DB = (*db_pair_list*)
}

*db_list*:
    *db_name*[, *db_name*][, ...]

*tbl_list*:
    *db_name.table_name*[, *db_name.table_name*][, ...]
*wild_tbl_list*:
    '*db_pattern.table_pattern*'[, '*db_pattern.table_pattern*'][, ...]

*db_pair_list*:
    (*db_pair*)[, (*db_pair*)][, ...]

*db_pair*:
    *from_db*, *to_db*

CHANGE REPLICATION FILTER设置一个或多个复制过滤规则，与使用复制过滤选项（如--replicate-do-db或--replicate-wild-ignore-table的方式相同。使用此语句设置的过滤器与使用服务器选项设置的过滤器在两个关键方面有所不同：

  1. 该语句不需要重新启动服务器才能生效，只需首先停止复制 SQL 线程使用STOP REPLICA SQL_THREAD（然后使用START REPLICA SQL_THREAD重新启动）。

  2. 该语句的效果不是持久的；使用CHANGE REPLICATION FILTER设置的任何过滤器在重启复制mysqld后会丢失。

CHANGE REPLICATION FILTER需要REPLICATION_SLAVE_ADMIN权限（或已弃用的SUPER权限）。

使用FOR CHANNEL *channel*子句使复制过滤器特定于复制通道，例如在多源副本上。未附加特定FOR CHANNEL子句应用的过滤器被视为全局过滤器，这意味着它们适用于所有复制通道。

注意

不能在配置为组复制的 MySQL 服务器实例上设置全局复制过滤器，因为在某些服务器上过滤事务会使组无法达成一致状态。可以在未直接涉及组复制的复制通道上设置特定通道的复制过滤器，例如，其中一个组成员同时充当到组外源的副本。不能在group_replication_applier或group_replication_recovery通道上设置。

以下列表显示了CHANGE REPLICATION FILTER选项及其与--replicate-*服务器选项的关系：

  • REPLICATE_DO_DB: 根据数据库名称包含更新。等同于--replicate-do-db。

  • REPLICATE_IGNORE_DB: 根据数据库名称排除更新。等同于--replicate-ignore-db。

  • REPLICATE_DO_TABLE: 根据表名包含更新。等同于--replicate-do-table。

  • REPLICATE_IGNORE_TABLE: 根据表名排除更新。等同于--replicate-ignore-table。

  • REPLICATE_WILD_DO_TABLE: 根据通配符模式匹配表名包含更新。等同于--replicate-wild-do-table。

  • REPLICATE_WILD_IGNORE_TABLE: 根据通配符模式匹配表名排除更新。等同于--replicate-wild-ignore-table。

  • REPLICATE_REWRITE_DB: 在源端替换指定数据库的名称后，在副本上执行更新。等同于--replicate-rewrite-db。

REPLICATE_DO_DB和REPLICATE_IGNORE_DB过滤器的确切效果取决于是基于语句还是基于行的复制。有关更多信息，请参见第 19.2.5 节，“服务器如何评估复制过滤规则”。

可以通过在单个CHANGE REPLICATION FILTER语句中用逗号分隔规则来创建多个复制过滤规则，如下所示：

CHANGE REPLICATION FILTER
    REPLICATE_DO_DB = (d1), REPLICATE_IGNORE_DB = (d2);

发出刚才显示的语句等同于使用选项--replicate-do-db=d1 --replicate-ignore-db=d2启动副本mysqld。

在使用多个复制通道处理来自不同源的事务的多源复制中，使用FOR CHANNEL *channel*子句在复制通道上设置复制过滤器：

CHANGE REPLICATION FILTER REPLICATE_DO_DB = (d1) FOR CHANNEL channel_1;

这使您可以创建特定通道的复制过滤器，以从源中筛选出选定的数据。提供FOR CHANNEL子句时，复制过滤器语句将作用于该复制通道，删除具有与指定复制过滤器相同过滤器类型的任何现有复制过滤器，并用指定的过滤器替换它们。未在语句中明确列出的过滤器类型不会被修改。如果针对未配置的复制通道发出该语句，则该语句将失败，并显示 ER_SLAVE_CONFIGURATION 错误。如果针对 Group Replication 通道发出该语句，则该语句将失败，并显示 ER_SLAVE_CHANNEL_OPERATION_NOT_ALLOWED 错误。

在配置了多个复制通道的副本中，发出不带FOR CHANNEL子句的CHANGE REPLICATION FILTER会为每个配置的复制通道以及全局复制过滤器配置复制过滤器。对于每种过滤器类型，如果语句中列出了过滤器类型，则该类型的任何现有过滤规则都将被最近发出的语句中指定的过滤规则替换，否则过滤器类型的旧值将被保留。有关更多信息，请参见 Section 19.2.5.4, “Replication Channel Based Filters”。

如果同一过滤规则被指定多次，则实际上只使用最后一条规则。例如，这里显示的两个语句具有完全相同的效果，因为第一个语句中的第一条REPLICATE_DO_DB规则被忽略：

CHANGE REPLICATION FILTER
    REPLICATE_DO_DB = (db1, db2), REPLICATE_DO_DB = (db3, db4);

CHANGE REPLICATION FILTER
    REPLICATE_DO_DB = (db3, db4);

注意

这种行为与--replicate-*过滤选项的行为不同，其中多次指定相同选项会导致创建多个过滤规则。

不包含任何特殊字符的表和数据库名称无需加引号。与REPLICATION_WILD_TABLE和REPLICATION_WILD_IGNORE_TABLE一起使用的值是字符串表达式，可能包含（特殊）通配符字符，因此必须加引号。以下示例语句中显示了这一点：

CHANGE REPLICATION FILTER
    REPLICATE_WILD_DO_TABLE = ('db1.old%');

CHANGE REPLICATION FILTER
    REPLICATE_WILD_IGNORE_TABLE = ('db1.new%', 'db2.new%');

与REPLICATE_REWRITE_DB一起使用的值表示数据库名称的对；每个这样的值必须用括号括起来。以下语句将源数据库db1上发生的语句重写为副本数据库db2：

CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB = ((db1, db2));

刚刚显示的语句包含两组括号，一组括住数据库名称的对，另一组括住整个列表。这在下面的示例中可能更容易看到，该示例创建了两个rewrite-db规则，一个将数据库dbA重写为dbB，另一个将数据库dbC重写为dbD：

CHANGE REPLICATION FILTER
  REPLICATE_REWRITE_DB = ((dbA, dbB), (dbC, dbD));

CHANGE REPLICATION FILTER语句仅替换受语句影响的过滤类型和复制通道的复制过滤规则，而保持其他规则和通道不变。如果要取消给定类型的所有过滤器，请将过滤器的值设置为显式空列表，如此示例所示，它删除了所有现有的REPLICATE_DO_DB和REPLICATE_IGNORE_DB规则：

CHANGE REPLICATION FILTER
    REPLICATE_DO_DB = (), REPLICATE_IGNORE_DB = ();

以这种方式将过滤器设置为空会删除所有现有规则，不会创建任何新规则，并且不会恢复在启动时使用--replicate-*选项在命令行或配置文件中设置的任何规则。

RESET REPLICA ALL语句会移除在被语句删除的通道上设置的特定通道复制过滤器。当被删除的通道或通道重新创建时，任何为副本指定的全局复制过滤器都会被复制到它们，而不会应用任何特定通道的复制过滤器。

欲了解更多信息，请参阅第 19.2.5 节，“服务器如何评估复制过滤规则”。

原文：dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html

15.4.2.3 CHANGE REPLICATION SOURCE TO 语句
CHANGE REPLICATION SOURCE TO *option* [, *option*] ... [ *channel_option* ]

*option*: {
    SOURCE_BIND = '*interface_name*'
  | SOURCE_HOST = '*host_name*'
  | SOURCE_USER = '*user_name*'
  | SOURCE_PASSWORD = '*password*'
  | SOURCE_PORT = *port_num*
  | PRIVILEGE_CHECKS_USER = {NULL | '*account*'}
  | REQUIRE_ROW_FORMAT = {0|1}
  | REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF | GENERATE}
  | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | *uuid*}
  | SOURCE_LOG_FILE = '*source_log_name*'
  | SOURCE_LOG_POS = *source_log_pos*
  | SOURCE_AUTO_POSITION = {0|1}
  | RELAY_LOG_FILE = '*relay_log_name*'
  | RELAY_LOG_POS = *relay_log_pos*
  | SOURCE_HEARTBEAT_PERIOD = *interval*
  | SOURCE_CONNECT_RETRY = *interval*
  | SOURCE_RETRY_COUNT = *count*
  | SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}
  | SOURCE_DELAY = *interval*
  | SOURCE_COMPRESSION_ALGORITHMS = '*algorithm*[,*algorithm*][,*algorithm*]'
  | SOURCE_ZSTD_COMPRESSION_LEVEL = *level*
  | SOURCE_SSL = {0|1}
  | SOURCE_SSL_CA = '*ca_file_name*'
  | SOURCE_SSL_CAPATH = '*ca_directory_name*'
  | SOURCE_SSL_CERT = '*cert_file_name*'
  | SOURCE_SSL_CRL = '*crl_file_name*'
  | SOURCE_SSL_CRLPATH = '*crl_directory_name*'
  | SOURCE_SSL_KEY = '*key_file_name*'
  | SOURCE_SSL_CIPHER = '*cipher_list*'
  | SOURCE_SSL_VERIFY_SERVER_CERT = {0|1}
  | SOURCE_TLS_VERSION = '*protocol_list*'
  | SOURCE_TLS_CIPHERSUITES = '*ciphersuite_list*'
  | SOURCE_PUBLIC_KEY_PATH = '*key_file_name*'
  | GET_SOURCE_PUBLIC_KEY = {0|1}
  | NETWORK_NAMESPACE = '*namespace*'
  | IGNORE_SERVER_IDS = (*server_id_list*),
  | GTID_ONLY = {0|1}
}

*channel_option*:
    FOR CHANNEL *channel*

*server_id_list*:
    [*server_id* [, *server_id*] ... ]

CHANGE REPLICATION SOURCE TO更改副本服务器用于连接到源并从源读取数据的参数。它还更新了复制元数据存储库的内容（参见Section 19.2.4, “Relay Log and Replication Metadata Repositories”）。在 MySQL 8.0.23 及更高版本中，请使用CHANGE REPLICATION SOURCE TO代替已弃用的CHANGE MASTER TO语句。

CHANGE REPLICATION SOURCE TO需要REPLICATION_SLAVE_ADMIN权限（或已弃用的SUPER权限）。

在CHANGE REPLICATION SOURCE TO语句中未指定的选项保留其值，除非在以下讨论中另有说明。因此，在大多数情况下，无需指定不更改的选项。

用于SOURCE_HOST和其他CHANGE REPLICATION SOURCE TO选项的值会检查换行符（\n或0x0A）。这些值中存在这些字符会导致语句失败并出现错误。

可选的FOR CHANNEL *channel*子句允许您指定语句适用于哪个复制通道。提供FOR CHANNEL *channel*子句将CHANGE REPLICATION SOURCE TO语句应用于特定的复制通道，并用于添加新通道或修改现有通道。例如，要添加一个名为channel2的新通道：

CHANGE REPLICATION SOURCE TO SOURCE_HOST=host1, SOURCE_PORT=3002 FOR CHANNEL 'channel2';

如果未命名子句且不存在额外通道，则CHANGE REPLICATION SOURCE TO语句适用于默认通道，其名称为空字符串（“”）。当设置了多个复制通道时，每个CHANGE REPLICATION SOURCE TO语句必须使用FOR CHANNEL *channel*子句命名通道。有关更多信息，请参见Section 19.2.2, “Replication Channels”。

对于CHANGE REPLICATION SOURCE TO语句的某些选项，您必须在发出CHANGE REPLICATION SOURCE TO语句之前发出STOP REPLICA语句（以及之后发出START REPLICA语句）。有时，您只需要停止复制 SQL（应用程序）线程或复制 I/O（接收）线程，而不是两者都要停止：

  • 当应用程序线程停止时，您可以使用RELAY_LOG_FILE、RELAY_LOG_POS和SOURCE_DELAY选项的任何允许组合执行CHANGE REPLICATION SOURCE TO，即使复制接收线程正在运行。当接收线程正在运行时，不得使用此语句的其他选项。

  • 当接收线程停止时，您可以使用此语句的任何选项（以任何允许的组合）执行CHANGE REPLICATION SOURCE TO，除了 RELAY_LOG_FILE、RELAY_LOG_POS、SOURCE_DELAY或SOURCE_AUTO_POSITION = 1，即使应用程序线程正在运行。

  • 在发出使用SOURCE_AUTO_POSITION = 1、GTID_ONLY = 1或ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS的CHANGE REPLICATION SOURCE TO语句之前，必须停止接收线程和应用程序线程。

您可以使用SHOW REPLICA STATUS检查复制应用程序线程和复制接收线程的当前状态。请注意，Group Replication 应用程序通道（group_replication_applier）没有接收线程，只有一个应用程序线程。

CHANGE REPLICATION SOURCE TO语句具有许多您在执行之前应该了解的副作用和交互作用：

  • CHANGE REPLICATION SOURCE TO会导致正在进行的事务隐式提交。请参阅第 15.3.3 节，“导致隐式提交的语句”。

  • CHANGE REPLICATION SOURCE TO会将SOURCE_HOST、SOURCE_PORT、SOURCE_LOG_FILE和SOURCE_LOG_POS的先前值写入错误日志，以及在执行之前有关副本状态的其他信息。

  • 如果您正在使用基于语句的复制和临时表，可能会出现在CHANGE REPLICATION SOURCE TO语句之后的STOP REPLICA语句在副本上留下临时表的情况。每当发生这种情况时，都会发出警告(ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO)。在这种情况下，您可以通过确保在执行CHANGE REPLICATION SOURCE TO语句之前，Replica_open_temp_tables或Slave_open_temp_tables系统状态变量的值等于 0 来避免这种情况。

  • 当使用多线程副本（replica_parallel_workers > 0）时，停止副本可能导致已从中继日志执行的事务序列中存在间隙，无论副本是有意停止还是其他情况。当存在这样的间隙时，发出CHANGE REPLICATION SOURCE TO将失败。在这种情况下的解决方案是发出START REPLICA UNTIL SQL_AFTER_MTS_GAPS，以确保关闭这些间隙。从 MySQL 8.0.26 开始，当使用基于 GTID 的复制和 GTID 自动定位时，完全跳过检查事务序列中的间隙的过程，因为可以使用 GTID 自动定位解决事务间隙。在这种情况下，仍然可以使用CHANGE REPLICATION SOURCE TO。

下列选项适用于CHANGE REPLICATION SOURCE TO语句：

  • ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = {OFF | LOCAL | *uuid*}

    使复制通道为没有 GTID 的复制事务分配一个 GTID，从不使用基于 GTID 的复制的源复制到使用基于 GTID 的副本。对于多源副本，您可以同时使用ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS和不使用该选项的通道。默认值为OFF，表示不使用该功能。

    LOCAL分配一个包括副本自身 UUID（server_uuid设置）的 GTID。*uuid*分配一个包括指定 UUID 的 GTID，例如复制源服务器的server_uuid设置。使用非本地 UUID 可以区分在副本上发起的事务和在源上发起的事务，对于多源副本，还可以区分在不同源上发起的事务。您选择的 UUID 仅对副本自身使用有意义。如果源发送的任何事务已经具有 GTID，则保留该 GTID。

    专用于组复制的通道不能使用ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS，但是在作为组复制组成员的服务器实例上的另一个源的异步复制通道可以这样做。在这种情况下，不要将组复制组名称指定为创建 GTID 的 UUID。

    要将ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS设置为LOCAL或*uuid*，副本必须设置gtid_mode=ON，并且之后不能更改。此选项用于与具有基于二进制日志文件位置的复制的源一起使用，因此不能为通道设置SOURCE_AUTO_POSITION=1。在设置此选项之前，必须停止复制 SQL 线程和复制 I/O（接收器）线程。

    重要提示

    使用任何通道上的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS设置的副本不能在需要故障转移时晋升为替换复制源服务器，并且不能使用从副本中获取的备份来恢复复制源服务器。相同的限制也适用于替换或恢复其他使用任何通道上的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS的副本。

    有关更多限制和信息，请参阅第 19.1.3.6 节，“从没有 GTID 的源复制到具有 GTID 的副本”。

  • GET_SOURCE_PUBLIC_KEY = {0|1}

    通过请求源的公钥启用基于 RSA 密钥对的密码交换。此选项默认禁用。

    此选项适用于使用caching_sha2_password认证插件进行身份验证的复制品。对于使用此插件进行身份验证的帐户的连接，源不会发送公钥，除非请求，因此必须请求或在客户端中指定。如果给出SOURCE_PUBLIC_KEY_PATH并指定有效的公钥文件，则它优先于GET_SOURCE_PUBLIC_KEY。如果您正在使用使用caching_sha2_password插件进行身份验证的复制用户帐户（这是从 MySQL 8.0 开始的默认设置），并且您没有使用安全连接，则必须指定此选项或SOURCE_PUBLIC_KEY_PATH选项以向复制品提供 RSA 公钥。

  • GTID_ONLY = {0|1}

    停止复制通道在复制元数据存储库中持久化文件名和文件位置。GTID_ONLY从 MySQL 8.0.27 版本开始提供。GTID_ONLY选项在异步复制通道中默认禁用，但在组复制通道中默认启用，并且无法禁用。

    对于具有此设置的复制通道，仍会跟踪内存中的文件位置，并且出于调试目的，文件位置仍然可以在错误消息和通过诸如SHOW REPLICA STATUS语句（如果它们过时，则显示为无效）等接口中观察到。但是，在 GTID 基础复制实际上不需要它们的情况下，包括事务排队和应用程序过程中，避免了持久化和检查文件位置所需的写入和读取。

    只有在停止复制 SQL（应用程序）线程和复制 I/O（接收器）线程时才能使用此选项。要为复制通道设置GTID_ONLY = 1，必须在服务器上使用 GTID（gtid_mode = ON），并且源上必须使用基于行的二进制日志记录（不支持基于语句的复制）。必须为复制通道设置选项REQUIRE_ROW_FORMAT = 1和SOURCE_AUTO_POSITION = 1。

    当设置GTID_ONLY = 1时，如果服务器上的系统变量replica_parallel_workers设置为零，则复制品会使用replica_parallel_workers=1，因此它在技术上始终是一个多线程应用程序。这是因为多线程应用程序使用保存的位置而不是复制元数据存储库来定位需要重新应用的事务的起始位置。

    如果在设置GTID_ONLY后禁用它，现有的中继日志将被删除，并且现有的已知的二进制日志文件位置将被保留，即使它们已经过时。在复制元数据存储库中，二进制日志和中继日志的文件位置可能是无效的，如果是这种情况，则会返回警告。只要SOURCE_AUTO_POSITION仍然启用，GTID 自动定位将被用来提供正确的定位。

    如果你也禁用了SOURCE_AUTO_POSITION，则在复制元数据存储库中使用二进制日志和中继日志的文件位置进行定位，如果它们是有效的。如果它们被标记为无效，你必须提供一个有效的二进制日志文件名和位置（SOURCE_LOG_FILE和SOURCE_LOG_POS）。如果你还提供了一个中继日志文件名和位置（RELAY_LOG_FILE和RELAY_LOG_POS），则中继日志将被保留，而应用程序位置将被设置为指定位置。 GTID 自动跳过确保任何已经应用的事务都会被跳过，即使最终的应用程序位置不正确。

  • IGNORE_SERVER_IDS = (*server_id_list*)

    使复制忽略来自指定服务器的事件。该选项接受一个逗号分隔的 0 个或多个服务器 ID 的列表。来自服务器的日志旋转和删除事件不会被忽略，并且会记录在中继日志中。

    在循环复制中，原始服务器通常充当其自己事件的终结者，以便它们不会被应用多次。因此，在循环复制中，当圈中的一个服务器被移除时，这个选项是有用的。假设你有一个带有服务器 ID 为 1、2、3 和 4 的 4 台服务器的循环复制设置，并且服务器 3 失败了。在通过从服务器 2 开始到服务器 4 启动复制来填补这个空白时，你可以在服务器 4 上发出的CHANGE REPLICATION SOURCE TO语句中包含IGNORE_SERVER_IDS = (3)，告诉��使用服务器 2 作为其源，而不是服务器 3。这样做会导致它忽略并不传播任何源自不再使用的服务器的语句。

    如果IGNORE_SERVER_IDS包含服务器自己的 ID，并且服务器是使用--replicate-same-server-id选项启动的，则会导致错误。

    注意

    当全局事务标识符（GTID）用于复制时，已经应用的事务会自动被忽略，因此不需要使用IGNORE_SERVER_IDS函数，该函数已被弃用。如果为服务器设置了gtid_mode=ON，则如果在CHANGE REPLICATION SOURCE TO语句中包含IGNORE_SERVER_IDS选项，则会发出弃用警告。

    源元数据存储库和SHOW REPLICA STATUS的输出提供当前被忽略的服务器列表。有关更多信息，请参见第 19.2.4.2 节，“复制元数据存储库”和第 15.7.7.35 节，“显示 REPLICA 状态语句”。

    如果发出不带任何IGNORE_SERVER_IDS选项的CHANGE REPLICATION SOURCE TO语句，则会保留任何现有列表。要清除被忽略服务器的列表，必须使用带有空列表的选项：

    CHANGE REPLICATION SOURCE TO IGNORE_SERVER_IDS = ();

    RESET REPLICA ALL清除IGNORE_SERVER_IDS。

    注意

    如果在任何通道存在使用IGNORE_SERVER_IDS设置的现有服务器 ID 时发出SET GTID_MODE=ON，则会发出弃用警告。在启动基于 GTID 的复制之前，请检查并清除涉及服务器上的所有被忽略的服务器 ID 列表。SHOW REPLICA STATUS语句显示被忽略的 ID 列表（如果有）。如果收到弃用警告，仍然可以通过发出包含带有空列表的IGNORE_SERVER_IDS选项的CHANGE REPLICATION SOURCE TO语句来清除列表。

  • NETWORK_NAMESPACE = '*namespace*'

    用于 TCP/IP 连接到复制源服务器的网络命名空间，或者如果使用 MySQL 通信堆栈，则用于 Group Replication 的组通信连接。字符串值的最大长度为 64 个字符。如果省略此选项，则副本的连接将使用默认（全局）命名空间。在不实现网络命名空间支持的平台上，当副本尝试连接到源时会发生故障。有关网络命名空间的信息，请参见第 7.1.14 节，“网络命名空间支持”。NETWORK_NAMESPACE在 MySQL 8.0.22 中可用。

  • PRIVILEGE_CHECKS_USER = {NULL | '*account*'}

    为指定通道提供安全上下文的用户帐户名称。NULL是默认值，表示不使用安全上下文。PRIVILEGE_CHECKS_USER在 MySQL 8.0.18 中可用。

    用户帐户的用户名和主机名必须遵循 第 8.2.4 节“指定帐户名称” 中描述的语法，并且用户不能是匿名用户（具有空白用户名）或 CURRENT_USER。帐户必须具有 REPLICATION_APPLIER 权限，以及执行在通道上复制的事务所需的权限。有关帐户所需权限的详细信息，请参见 第 19.3.3 节“复制权限检查”。当重新启动复制通道时，权限检查将从那一点开始应用。如果您不指定通道且没有其他通道存在，则该语句将应用于默认通道。

    当设置了 PRIVILEGE_CHECKS_USER 时，强烈建议使用基于行的二进制日志记录，并且您可以设置 REQUIRE_ROW_FORMAT 来强制执行此操作。例如，要在运行中的副本上启动通道 channel_1 上的权限检查，请发出以下语句：

    STOP REPLICA FOR CHANNEL 'channel_1';

CHANGE REPLICATION SOURCE TO
    PRIVILEGE_CHECKS_USER = '*user*'@'*host*',
    REQUIRE_ROW_FORMAT = 1,
    FOR CHANNEL 'channel_1';

START REPLICA FOR CHANNEL 'channel_1';

  • RELAY_LOG_FILE = '*relay_log_file*'，RELAY_LOG_POS = '*relay_log_pos*'

    中继日志文件名及文件中的位置，在该位置，复制 SQL 线程在下次启动时开始从副本的中继日志中读取的位置。RELAY_LOG_FILE 可以使用绝对路径或相对路径，并且使用与 SOURCE_LOG_FILE 相同的基本名称。字符串值的最大长度为 511 个字符。

    当复制 SQL（应用程序）线程停止时，可以在运行中的副本上执行一个使用 RELAY_LOG_FILE、RELAY_LOG_POS 或两者选项的 CHANGE REPLICATION SOURCE TO 语句。如果至少有一个复制应用程序线程和复制 I/O（接收器）线程正在运行，则中继日志将被保留。如果两个线程都停止，则除非至少指定一个 RELAY_LOG_FILE 或 RELAY_LOG_POS，否则所有中继日志文件都将被删除。对于仅具有应用程序线程而没有接收器线程的 Group Replication 应用程序通道（group_replication_applier），如果应用程序线程停止，但是对于该通道，您不能使用 RELAY_LOG_FILE 和 RELAY_LOG_POS 选项。

  • REQUIRE_ROW_FORMAT = {0|1}

    仅允许处理基于行的复制事件的复制通道。此选项阻止复制应用程序执行诸如创建临时表和执行LOAD DATA INFILE请求等操作，从而增加了通道的安全性。对于异步复制通道，默认情况下禁用REQUIRE_ROW_FORMAT选项，但对于组复制通道，默认情况下启用，并且无法禁用。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。REQUIRE_ROW_FORMAT从 MySQL 8.0.19 开始提供。

  • REQUIRE_TABLE_PRIMARY_KEY_CHECK = {STREAM | ON | OFF | GENERATE}

    从 MySQL 8.0.20 开始提供，此选项允许复制品设置自己的主键检查策略，如下：

    • ON：复制品设置sql_require_primary_key = ON；任何复制的CREATE TABLE或ALTER TABLE语句必须生成包含主键的表。

    • OFF：复制品设置sql_require_primary_key = OFF；不会检查任何复制的CREATE TABLE或ALTER TABLE语句是否存在主键。

    • STREAM：复制品使用从源复制的sql_require_primary_key的任何值来处理每个事务。这是默认值和默认行为。

    • GENERATE：在 MySQL 8.0.32 中添加，这会导致复制品为任何缺少主键的InnoDB表生成一个不可见的主键。有关更多信息，请参见第 15.1.20.11 节，“生成的不可见主键”。

      GENERATE与组复制不兼容；您可以使用ON、OFF或STREAM。

    基于源或复制品表上仅存在生成的不可见主键的差异得到 MySQL 复制支持，只要源支持 GIPKs（MySQL 8.0.30 及更高版本），而复制品使用 MySQL 版本 8.0.32 或更高版本。如果在复制品上使用 GIPKs 并从使用 MySQL 8.0.29 或更早版本的源进行复制，则应注意，在这种情况下，除了复制品上的额外 GIPK 之外，不支持模式中的这种差异，并且可能导致复制错误。

    对于多源复制，将REQUIRE_TABLE_PRIMARY_KEY_CHECK设置为ON或OFF可以使副本在不同源的复制通道之间规范化行为，并为sql_require_primary_key保持一致的设置。使用ON可以防止在多个源更新相同的表集时意外丢失主键。使用OFF可以让可以操作主键的源与不能操作主键的源一起工作。

    在多个副本的情况下，当REQUIRE_TABLE_PRIMARY_KEY_CHECK设置为GENERATE时，给定副本添加的生成的不可见主键与其他副本上添加的任何此类键是独立的。这意味着，如果使用生成的不可见主键，不同副本上生成的主键列中的值不能保证相同。当故障转移到这样的副本时，这可能是一个问题。

    当PRIVILEGE_CHECKS_USER为NULL（默认值）时，用户帐户不需要管理级别权限来设置受限制的会话变量。将此选项设置为NULL以外的值意味着，当REQUIRE_TABLE_PRIMARY_KEY_CHECK为ON，OFF或GENERATE时，用户帐户不需要会话管理级别权限来设置受限制的会话变量，如sql_require_primary_key，避免需要授予帐户此类权限。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。

  • SOURCE_AUTO_POSITION = {0|1}

    使副本尝试使用基于 GTID 的复制的自动定位功能连接到源，而不是基于二进制日志文件的位置。此选项用于启动使用基于 GTID 的复制的副本。默认值为 0，表示不使用 GTID 自动定位和基于 GTID 的复制。只有在停止复制 SQL（应用程序）线程和复制 I/O（接收器）线程时，才能将此选项与CHANGE REPLICATION SOURCE TO一起使用。

    副本和源都必须启用 GTIDs（GTID_MODE=ON，在副本上为ON_PERMISSIVE或OFF_PERMISSIVE，在源上为GTID_MODE=ON）。SOURCE_LOG_FILE，SOURCE_LOG_POS，RELAY_LOG_FILE和RELAY_LOG_POS不能与SOURCE_AUTO_POSITION = 1一起指定。如果在副本上启用了多源复制，则需要为每个适用的复制通道设置SOURCE_AUTO_POSITION = 1选项。

    设置SOURCE_AUTO_POSITION = 1后，在初始连接握手中，副本发送一个包含其已接收、已提交或两者都包含的事务的 GTID 集。源端通过发送其二进制日志中所有 GTID 不包含在副本发送的 GTID 集中的事务来做出响应。这种交换确保源端只发送副本尚未记录或提交的具有 GTID 的事务。如果副本从多个源接收事务，如钻石拓扑结构的情况，自动跳过功能确保事务不会被应用两次。有关副本发送的 GTID 集如何计算的详细信息，请参见第 19.1.3.3 节，“GTID 自动定位”。

    如果应该由源端发送的任何事务已从源端的二进制日志中清除，或者通过其他方法添加到gtid_purged系统变量的 GTID 集中，源端将向副本发送错误ER_MASTER_HAS_PURGED_REQUIRED_GTIDS，并且复制不会启动。缺失的已清除事务的 GTID 将在源端的错误日志中被识别并列在警告消息ER_FOUND_MISSING_GTIDS中。此外，如果在事务交换过程中发现副本已记录或提交具有源端 UUID 的 GTID 的事务，但源端本身尚未提交它们，则源端将向副本发送错误ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER，并且复制不会启动。有关如何处理这些情况的信息，请参见第 19.1.3.3 节，“GTID 自动定位”。

    您可以通过检查性能模式replication_connection_status表或SHOW REPLICA STATUS语句的输出来查看是否启用了 GTID 自动定位的复制。再次禁用SOURCE_AUTO_POSITION选项会使副本恢复到基于文件的复制。

  • SOURCE_BIND = '*interface_name*'

    确定副本的哪个网络接口被选择用于连接到源端，适用于具有多个网络接口的副本。指定网络接口的 IP 地址。字符串值的最大长度为 255 个字符。

    配置此选项的 IP 地址（如果有）可以在SHOW REPLICA STATUS输出的Source_Bind列中看到。在源元数据存储库表mysql.slave_master_info中，该值可以在Source_bind列中看到。将副本绑定到特定网络接口的能力也受到 NDB Cluster 的支持。

  • SOURCE_COMPRESSION_ALGORITHMS = '*algorithm*[,*algorithm*][,*algorithm*]'

    指定连接到复制源服务器的允许压缩算法之一、两个或三个，用逗号分隔。字符串值的最大长度为 99 个字符。默认值为uncompressed。

    可用的算法是zlib、zstd和uncompressed，与protocol_compression_algorithms系统变量相同。算法可以以任何顺序指定，但这不是优先顺序 - 算法协商过程尝试使用zlib，然后zstd，然后uncompressed，如果它们被指定。SOURCE_COMPRESSION_ALGORITHMS自 MySQL 8.0.18 起可用。

    SOURCE_COMPRESSION_ALGORITHMS的值仅在禁用replica_compressed_protocol或slave_compressed_protocol系统变量时适用。如果启用了replica_compressed_protocol或slave_compressed_protocol，它优先于SOURCE_COMPRESSION_ALGORITHMS，并且如果源和副本都支持该算法，则连接到源使用zlib压缩。有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。

    二进制日志事务压缩（自 MySQL 8.0.20 起可用），由binlog_transaction_compression系统变量激活，也可用于节省带宽。如果与连接压缩结合使用，连接压缩的机会减少，但仍可压缩标头以及未压缩的事件和事务有效载荷。有关二进制日志事务压缩的更多信息，请参见第 7.4.4.5 节，“二进制日志事务压缩”。

  • SOURCE_CONNECT_RETRY = *interval*

    指定副本在连接到源超时后重新连接尝试之间的秒数间隔。默认间隔为 60。

    尝试次数受SOURCE_RETRY_COUNT选项限制。如果使用默认设置，副本在重新连接尝试之间等待 60 秒（SOURCE_CONNECT_RETRY=60），并以这个速率持续尝试重新连接 60 天（SOURCE_RETRY_COUNT=86400）。这些值记录在源元数据存储库中，并显示在replication_connection_configuration性能模式表中。

  • SOURCE_CONNECTION_AUTO_FAILOVER = {0|1}

    如果有一个或多个备用复制源服务器可用（即有多个共享复制数据的 MySQL 服务器或服务器组），则为复制通道激活异步连接故障转移机制。SOURCE_CONNECTION_AUTO_FAILOVER从 MySQL 8.0.22 版本开始提供。默认值为 0，表示未激活该机制。有关完整信息和设置此功能的说明，请参阅第 19.4.9.2 节，“副本的异步连接故障转移”。

    在由SOURCE_CONNECT_RETRY和SOURCE_RETRY_COUNT控制的重新连接尝试耗尽后，异步连接故障转移机制接管。它将副本重新连接到从指定源列表中选择的备用源，您可以使用asynchronous_connection_failover_add_source和asynchronous_connection_failover_delete_source函数进行管理。要添加和删除受管理的服务器组，请改用asynchronous_connection_failover_add_managed和asynchronous_connection_failover_delete_managed函数。有关更多信息，请参阅第 19.4.9 节，“使用异步连接故障转移切换源和副本”。

    重要提示

    1. 只有在使用 GTID 自动定位时（SOURCE_AUTO_POSITION = 1）才能设置SOURCE_CONNECTION_AUTO_FAILOVER = 1。

    2. 当你设置 SOURCE_CONNECTION_AUTO_FAILOVER = 1 时，将 SOURCE_RETRY_COUNT 和 SOURCE_CONNECT_RETRY 设置为最小值，只允许几次重试尝试与相同源进行连接，以防连接失败是由瞬时网络中断引起的。否则，异步连接故障转移机制无法及时激活。适当的值是 SOURCE_RETRY_COUNT=3 和 SOURCE_CONNECT_RETRY=10，这使得副本在每次连接尝试之间间隔 10 秒的情况下重试连接 3 次。

    3. 当你设置 SOURCE_CONNECTION_AUTO_FAILOVER = 1 时，复制元数据存储库必须包含用于连接到复制通道源列表中所有服务器的复制用户帐户的凭据。该帐户还必须对性能模式表具有 SELECT 权限。这些凭据可以使用带有 SOURCE_USER 和 SOURCE_PASSWORD 选项的 CHANGE REPLICATION SOURCE TO 语句进行设置。有关更多信息，请参见 第 19.4.9 节，“使用异步连接故障转移切换源和副本”。

    4. 从 MySQL 8.0.27 开始，当你设置 SOURCE_CONNECTION_AUTO_FAILOVER = 1 时，如果这个复制通道在单主模式下的组复制主节点上，副本的异步连接故障转移将自动激活。启用此功能后，如果正在复制的主节点下线或进入错误状态，新的主节点在选举时将在同一通道上开始复制。如果要使用此功能，这个复制通道还必须在复制组中的所有辅助服务器上设置，并在任何新加入的成员上设置。（如果使用 MySQL 的克隆功能进行服务器配置，则所有这些都会自动发生。）如果不想使用此功能，请使用 group_replication_disable_member_action() 函数禁用默认启用的 Group Replication 成员操作 mysql_start_failover_channels_if_primary。有关更多信息，请参见 第 19.4.9.2 节，“副本的异步连接故障转移”。

  • SOURCE_DELAY = *interval*

    指定副本必须滞后源多少秒。从源接收的事件直到至少延迟*interval秒后才执行。interval*必须是 0 到 2³¹−1 范围内的非负整数。默认值为 0。更多信息，请参见 Section 19.4.11, “Delayed Replication”。

    使用SOURCE_DELAY选项的CHANGE REPLICATION SOURCE TO语句可以在运行中的副本上执行，当复制 SQL 线程停止时。

  • SOURCE_HEARTBEAT_PERIOD = *interval*

    控制心跳间隔，防止在没有数据的情况下发生连接超时，如果连接仍然良好。在那么多秒后向副本发送心跳信号，并且每当源的二进制日志更新为一个事件时，等待时间就会重置。因此，只有在二进制日志文件中有一段时间没有发送的事件时，源才会发送心跳。

    心跳间隔*interval是一个十进制值，范围为 0 到 4294967 秒，分辨率为毫秒；最小的非零值为 0.001。将interval*设置为 0 会完全禁用心跳。心跳间隔默认为replica_net_timeout或slave_net_timeout系统变量值的一半。它记录在源元数据存储库中，并显示在replication_connection_configuration性能模式表中。

    系统变量replica_net_timeout（从 MySQL 8.0.26 开始）或slave_net_timeout（MySQL 8.0.26 之前）指定副本等待来自源的更多数据或心跳信号的秒数，超过该时间副本将认为连接已中断，中止读取并尝试重新连接。默认值为 60 秒（一分钟）。请注意，对replica_net_timeout或slave_net_timeout的值或默认设置的更改不会自动更改心跳间隔，无论是明确设置还是使用先前计算的默认值。如果将全局值replica_net_timeout或slave_net_timeout设置为小于当前心跳间隔的值，将发出警告。如果更改了replica_net_timeout或slave_net_timeout，还必须发出CHANGE REPLICATION SOURCE TO以将心跳间隔调整为适当的值，以便心跳信号在连接超时之前发生。如果不这样做，心跳信号将不起作用，如果未从源接收到数据，则副本可能会进行重复的重新连接尝试，从而创建僵尸转储线程。

  • SOURCE_HOST = '*host_name*'

    复制源服务器的主机名或 IP 地址。副本使用此信息连接到源。字符串值的最大长度为 255 个字符。

    如果您指定了SOURCE_HOST或SOURCE_PORT，则副本会假定源服务器与之前不同（即使选项值与当前值相同）。在这种情况下，源的二进制日志文件名和位置的旧值被认为不再适用，因此如果您在语句中未指定SOURCE_LOG_FILE和SOURCE_LOG_POS，则会自动追加SOURCE_LOG_FILE=''和SOURCE_LOG_POS=4。

    将SOURCE_HOST=''设置为（即，将其值明确设置为空字符串）不等同于根本不设置SOURCE_HOST。尝试将SOURCE_HOST设置为空字符串会导致错误。

  • SOURCE_LOG_FILE = '*source_log_name*', SOURCE_LOG_POS = *source_log_pos*

    二进制日志文件名以及在该文件中的位置，复制 I/O（接收器）线程在下次启动时从源二进制日志中开始读取的位置。如果使用基于二进制日志文件位置的复制，请指定这些选项。

    SOURCE_LOG_FILE必须包括源服务器上可用的特定二进制日志文件的数字后缀，例如，SOURCE_LOG_FILE='binlog.000145'。字符串值的最大长度为 511 个字符。

    SOURCE_LOG_POS是副本在该文件中开始读取的数字位置。SOURCE_LOG_POS=4表示二进制日志文件中事件的开始。

    如果指定了SOURCE_LOG_FILE或SOURCE_LOG_POS中的任一个，则不能指定SOURCE_AUTO_POSITION = 1，该选项用于基于 GTID 的复制。

    如果未指定SOURCE_LOG_FILE或SOURCE_LOG_POS中的任何一个，则副本使用复制 SQL 线程在发出CHANGE REPLICATION SOURCE TO之前的最后坐标。这确保了即使复制 SQL（应用程序）线程比复制 I/O（接收器）线程晚，复制也不会出现不连续。

  • SOURCE_PASSWORD = '*password*'

    用于连接到复制源服务器的复制用户帐户的密码。字符串值的最大长度为 32 个字符。如果指定了SOURCE_PASSWORD，则还需要SOURCE_USER。

    在CHANGE REPLICATION SOURCE TO语句中用于复制用户帐户的密码长度限制为 32 个字符。尝试使用超过 32 个字符的密码会导致CHANGE REPLICATION SOURCE TO失败。

    密码在 MySQL Server 的日志、性能模式表和SHOW PROCESSLIST语句中被掩盖。

  • SOURCE_PORT = *port_num*

    副本用于连接到复制源服务器的 TCP/IP 端口号。

    注意

    复制不能使用 Unix 套接字文件。您必须能够使用 TCP/IP 连接到复制源服务器。

    如果指定了SOURCE_HOST或SOURCE_PORT，则副本会假定源服务器与以前不同（即使选项值与当前值相同）。在这种情况下，源二进制日志文件名和位置的旧值被认为不再适用，因此如果在语句中不指定SOURCE_LOG_FILE和SOURCE_LOG_POS，则会自动附加SOURCE_LOG_FILE=''和SOURCE_LOG_POS=4。

  • SOURCE_PUBLIC_KEY_PATH = '*key_file_name*'

    通过提供包含源端所需的公钥副本的文件路径名，启用基于 RSA 密钥对的密码交换。文件必须采用 PEM 格式。字符串值的最大长度为 511 个字符。

    此选项适用于使用sha256_password或caching_sha2_password认证插件进行身份验证的副本。（对于sha256_password，只有在使用 OpenSSL 构建 MySQL 时才能使用SOURCE_PUBLIC_KEY_PATH。）如果您正在使用使用caching_sha2_password插件进行身份验证的复制用户帐户（这是 MySQL 8.0 的默认设置），并且您没有使用安全连接，则必须指定此选项或GET_SOURCE_PUBLIC_KEY=1选项之一以向副本提供 RSA 公钥。

  • SOURCE_RETRY_COUNT = *count*

    设置副本在与源的连接超时后进行的重新连接尝试的最大次数，由replica_net_timeout或slave_net_timeout系统变量确定。如果副本确实需要重新连接，则第一次重试会在超时后立即发生。默认值为 86400 次尝试。

    尝试之间的间隔由SOURCE_CONNECT_RETRY选项指定。如果使用默认设置，副本在重新连接尝试之间等待 60 秒（SOURCE_CONNECT_RETRY=60），并以此速率继续尝试重新连接 60 天（SOURCE_RETRY_COUNT=86400）。将SOURCE_RETRY_COUNT设置为 0 意味着没有重新连接尝试次数限制，因此副本将无限尝试重新连接。

    SOURCE_CONNECT_RETRY和SOURCE_RETRY_COUNT的值记录在源元数据存储库中，并显示在replication_connection_configuration性能模式表中。SOURCE_RETRY_COUNT取代了--master-retry-count服务器启动选项。

  • SOURCE_SSL = {0|1}

    指定副本是否加密复制连接。默认值为 0，表示副本不加密复制连接。如果设置SOURCE_SSL=1，则可以使用SOURCE_SSL_*xxx*和SOURCE_TLS_*xxx*选项配置加密。

    为复制连接设置SOURCE_SSL=1，然后不设置更多的SOURCE_SSL_*xxx*选项相当于为客户端设置--ssl-mode=REQUIRED，如加密连接的命令选项中所述。使用SOURCE_SSL=1，只有在可以建立加密连接时连接尝试才会成功。复制连接不会退回到未加密连接，因此没有与复制的--ssl-mode=PREFERRED设置相对应的设置。如果设置SOURCE_SSL=0，则相当于--ssl-mode=DISABLED。

    重要

    为了帮助防止复杂的中间人攻击，副本验证服务器的身份非常重要。您可以指定额外的SOURCE_SSL_*xxx*选项对应于设置--ssl-mode=VERIFY_CA和--ssl-mode=VERIFY_IDENTITY，这比默认设置更好地帮助防止这种类型的攻击。使用这些设置，副本会检查服务器的证书是否有效，并检查副本正在使用的主机名是否与服务器证书中的标识匹配。要实施这些验证级别之一，您必须首先确保服务器的 CA 证书可靠地可用于副本，否则将导致可用性问题。因此，它们不是默认设置。

  • SOURCE_SSL_*xxx*, SOURCE_TLS_*xxx*

    指定副本如何使用加密和密码来保护复制连接。即使在没有 SSL 支持的编译副本上也可以更改这些选项。它们保存在源元数据存储库中，但如果副本没有启用 SSL 支持，则会被忽略。字符串值为SOURCE_SSL_*xxx*和SOURCE_TLS_*xxx*选项的最大长度为 511 个字符，例外是SOURCE_TLS_CIPHERSUITES，其长度为 4000 个字符。

    SOURCE_SSL_*xxx*和SOURCE_TLS_*xxx*选项执行与加密连接的命令选项中描述的--ssl-*xxx*和--tls-*xxx*客户端选项相同的功能。两组选项之间的对应关系，以及使用SOURCE_SSL_*xxx*和SOURCE_TLS_*xxx*选项建立安全连接的方法，在第 19.3.1 节，“设置复制使用加密连接”中有解释。

  • SOURCE_USER = '*user_name*'

    复制用户帐户的用户名，用于连接到复制源服务器。字符串值的最大长度为 96 个字符。

    对于组复制，此帐户必须存在于复制组的每个成员中。如果 XCom 通信堆栈用于组，则用于分布式恢复，如果 MySQL 通信堆栈用于组，则用于组通信连接。对于 MySQL 通信堆栈，帐户必须具有GROUP_REPLICATION_STREAM权限。

    可以通过指定SOURCE_USER=''来设置空用户名称，但不能使用空用户名称启动复制通道。在 MySQL 8.0.21 之前的版本中，仅在需要出于安全目的清除先前使用的凭据时才设置空的SOURCE_USER用户名称。不要在此之后使用通道，因为在这些版本中存在一个错误，如果从存储库中读取空用户名称（例如，在组复制通道的自动重启期间），则可能会替换默认用户名称。从 MySQL 8.0.21 开始，可以设置空的SOURCE_USER用户名称，并且可以在之后使用通道，如果始终使用START REPLICA语句或START GROUP_REPLICATION语句提供用户凭据以启动复制通道。这种方法意味着复制通道始终需要操作员干预才能重新启动，但用户凭据不会记录在复制元数据存储库中。

    重要提示

    要使用使用caching_sha2_password插件进行身份验证的复制用户帐户连接到源，您必须设置安全连接，如 Section 19.3.1, “Setting Up Replication to Use Encrypted Connections”中所述，或启用不加密的连接以支持使用 RSA 密钥对进行密码交换。caching_sha2_password身份验证插件是从 MySQL 8.0 开始的新用户的默认插件（请参阅 Section 8.4.1.2, “Caching SHA-2 Pluggable Authentication”）。如果您创建或使用用于复制的用户帐户使用此身份验证插件，并且未使用安全连接，则必须启用基于 RSA 密钥对的密码交换以成功连接。您可以使用此语句的SOURCE_PUBLIC_KEY_PATH选项或GET_SOURCE_PUBLIC_KEY=1选项来执行此操作。

  • SOURCE_ZSTD_COMPRESSION_LEVEL = *level*

    用于使用zstd压缩算法的连接到复制源服务器的压缩级别。SOURCE_ZSTD_COMPRESSION_LEVEL自 MySQL 8.0.18 起可用。允许的级别为 1 到 22，较大的值表示较高级别的压缩。默认级别为 3。

    压缩级别设置对不使用zstd压缩的连接没有影响。有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。

示例

CHANGE REPLICATION SOURCE TO对于在具有源快照并记录了快照时间对应的源二进制日志坐标的情况下设置副本非常有用。在将快照加载到副本以与源同步之后，您可以在副本上运行CHANGE REPLICATION SOURCE TO SOURCE_LOG_FILE='*log_name*', SOURCE_LOG_POS=*log_pos*来指定副本应开始读取源二进制日志的坐标。以下示例更改了副本使用的源服务器并建立了副本开始读取的源二进制日志坐标：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='source2.example.com',
  SOURCE_USER='replication',
  SOURCE_PASSWORD='*password*',
  SOURCE_PORT=3306,
  SOURCE_LOG_FILE='source2-bin.001',
  SOURCE_LOG_POS=4,
  SOURCE_CONNECT_RETRY=10;

有关在故障切换期间将现有副本切换到新源的过程，请参见第 19.4.8 节，“故障切换期间切换源”。

当源和副本上使用 GTID 时，请指定 GTID 自动定位，而不是提供二进制日志文件位置，如下例所示。有关在新服务器或停止的服务器、在线服务器或其他副本上配置和启动基于 GTID 的复制的完整说明，请参见第 19.1.3 节，“具有全局事务标识符的复制”。

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='source3.example.com',
  SOURCE_USER='replication',
  SOURCE_PASSWORD='*password*',
  SOURCE_PORT=3306,
  SOURCE_AUTO_POSITION = 1,
  FOR CHANNEL "source_3";

在此示例中，使用了多源复制，并且CHANGE REPLICATION SOURCE TO语句应用于连接副本到指定主机的复制通道"source_3"。有关设置多源复制的指导，请参见第 19.1.5 节，“MySQL 多源复制”。

下一个示例显示了如何使副本应用您想要重复的中继日志文件中的事务。为此，源不需要可达。您可以使用CHANGE REPLICATION SOURCE TO来定位您希望副本开始重新应用事务的中继日志位置，然后启动 SQL 线程：

CHANGE REPLICATION SOURCE TO
  RELAY_LOG_FILE='replica-relay-bin.006',
  RELAY_LOG_POS=4025;
START REPLICA SQL_THREAD;

更改复制源为也可以用于跳过导致复制停止的二进制日志中的事务。执行此操作的适当方法取决于是否使用 GTID。有关使用更改复制源为或其他方法跳过事务的说明，请参见第 19.1.7.3 节，“跳过事务”。

原文：dev.mysql.com/doc/refman/8.0/en/reset-replica.html

15.4.2.4 RESET REPLICA Statement
RESET REPLICA [ALL] [*channel_option*]

*channel_option*:
    FOR CHANNEL *channel*

RESET REPLICA使副本忘记其在源二进制日志中的位置。从 MySQL 8.0.22 开始，请使用RESET REPLICA代替从该版本开始已弃用的RESET SLAVE。在 MySQL 8.0.22 之前的版本中，请使用RESET SLAVE。

此语句用于进行清理启动；它清除了复制元数据存储库，删除了所有中继日志文件，并启动了一个新的中继日志文件。它还将使用CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO语句（在 MySQL 8.0.23 之前）指定的复制延迟重置为 0。

注意

所有中继日志文件都将被删除，即使它们尚未完全被复制 SQL 线程执行。（这是一个可能存在的情况，如果您已经发出了STOP REPLICA语句或者如果副本负载很高。）

对于使用 GTIDs 的服务器（gtid_mode为ON），执行RESET REPLICA对 GTID 执行历史没有影响。该语句不会更改gtid_executed或gtid_purged的值，也不会更改mysql.gtid_executed表。如果需要重置 GTID 执行历史，请使用RESET MASTER，即使启用了 GTID 的服务器是一个禁用了二进制日志记录的副本。

RESET REPLICA需要RELOAD权限。

要使用RESET REPLICA，必须停止复制 SQL 线程和复制 I/O（接收器）线程，因此在运行中的副本上，在执行RESET REPLICA之前，请使用STOP REPLICA。要在 Group Replication 组成员上使用RESET REPLICA，成员状态必须为OFFLINE，表示插件已加载但成员当前不属于任何组。可以通过使用STOP GROUP REPLICATION语句将组成员下线。

可选的 FOR CHANNEL *channel* 子句使您可以命名语句适用于哪个复制通道。提供 FOR CHANNEL *channel* 子句将 RESET REPLICA 语句应用于特定的复制通道。将 FOR CHANNEL *channel* 子句与 ALL 选项结合使用会删除指定的通道。如果未命名通道且不存在额外通道，则该语句适用于默认通道。当存在多个复制通道时，发出不带 FOR CHANNEL *channel* 子句的 RESET REPLICA ALL 语句会删除 所有 复制通道，并仅重新创建默认通道。有关更多信息，请参见 Section 19.2.2, “Replication Channels”。

RESET REPLICA 不会更改任何复制连接参数，包括源主机名和端口、复制用户帐户及其密码、PRIVILEGE_CHECKS_USER 帐户、REQUIRE_ROW_FORMAT 选项、REQUIRE_TABLE_PRIMARY_KEY_CHECK 选项和 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项。如果要更改任何复制连接参数，可以在服务器启动后使用 CHANGE REPLICATION SOURCE TO 语句（从 MySQL 8.0.23 开始）或 CHANGE MASTER TO 语句（MySQL 8.0.23 之前）来实现。如果要删除所有复制连接参数，请使用 RESET REPLICA ALL。RESET REPLICA ALL 还会清除由 CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO 设置的 IGNORE_SERVER_IDS 列表。当使用了 RESET REPLICA ALL 后，如果要再次将实例用作复制品，则需要在服务器启动后发出 CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO 语句以指定新的连接参数。

从 MySQL 8.0.27 开始，可以在 CHANGE REPLICATION SOURCE TO 语句中设置 GTID_ONLY 选项，以阻止复制通道在复制元数据存储库中持久化文件名和文件位置。当发出 RESET REPLICA 语句时，复制元数据存储库会同步。RESET REPLICA ALL 删除而不是更新存储库，因此它们会隐式同步。

在发出RESET REPLICA但在发出START REPLICA之前发生意外服务器退出或故意重启时，复制连接参数的保留取决于用于复制元数据的存储库：

  • 当服务器上设置了master_info_repository=TABLE和relay_log_info_repository=TABLE时（这是 MySQL 8.0 的默认设置），复制连接参数将在InnoDB表mysql.slave_master_info和mysql.slave_relay_log_info中作为RESET REPLICA操作的一部分保留在崩溃安全的表中。它们也会保留在内存中。在发出RESET REPLICA但在发出START REPLICA之前发生意外服务器退出或故意重启时，复制连接参数将从表中检索并重新应用到通道上。这种情况适用于 MySQL 8.0.13 的连接元数据存储库，以及 MySQL 8.0.19 的应用程序元数据存储库。

  • 如果服务器上设置了master_info_repository=FILE和relay_log_info_repository=FILE，这在 MySQL 8.0 之前已经被弃用，或者 MySQL 服务器版本早于上述版本，则复制连接参数仅保留在内存中。如果由于意外服务器退出或故意重启而在发出RESET REPLICA后立即重新启动副本mysqld，连接参数将丢失。在这种情况下，您必须在服务器启动后发出CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO语句（在 MySQL 8.0.23 之前）来重新指定连接参数，然后再发出START REPLICA。

RESET REPLICA不会更改任何受该语句影响的通道的复制过滤器设置（例如--replicate-ignore-table）。但是，RESET REPLICA ALL会删除该语句删除的通道上设置的复制过滤器。当删除的通道或通道重新创建时，将复制为副本指定的任何全局复制过滤器，并且不应用特定于通道的复制过滤器。有关更多信息，请参见第 19.2.5.4 节，“基于复制通道的过滤器”。

RESET REPLICA会导致正在进行的事务隐式提交。参见 Section 15.3.3, “Statements That Cause an Implicit Commit”。

如果复制 SQL 线程在停止时正在复制临时表，并且发出RESET REPLICA，则这些复制的临时表将在副本上被删除。

注意

当在 NDB 集群副本 SQL 节点上使用RESET REPLICA时，会清除mysql.ndb_apply_status表。在使用此语句时，应该记住ndb_apply_status使用NDB存储引擎，因此被附加到集群的所有 SQL 节点共享。

您可以通过在执行RESET REPLICA之前发出SET GLOBAL @@``ndb_clear_apply_status=OFF来覆盖此行为，这样可以防止副本在这种情况下清除ndb_apply_status表。

原文：dev.mysql.com/doc/refman/8.0/en/reset-slave.html

15.4.2.5 重置从库语句
RESET {SLAVE | REPLICA} [ALL] [*channel_option*]

*channel_option*:
    FOR CHANNEL *channel*

使复制品忘记其在源二进制日志中的位置。从 MySQL 8.0.22 开始，RESET SLAVE已被弃用，应改用别名RESET REPLICA。在 MySQL 8.0.22 之前的版本中，请使用RESET SLAVE。该语句的工作方式与以前相同，只是语句及其输出所使用的术语已更改。使用时，两个版本的语句会更新相同的状态变量。请参阅RESET REPLICA的文档以获取有关该语句的描述。

原文：dev.mysql.com/doc/refman/8.0/en/start-replica.html

15.4.2.6 启动 REPLICA 语句
START REPLICA [*thread_types*] [*until_option*] [*connection_options*] [*channel_option*]

*thread_types*:
    [*thread_type* [, *thread_type*] ... ]

*thread_type*:
    IO_THREAD | SQL_THREAD

*until_option*:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = *gtid_set*
          |   MASTER_LOG_FILE = '*log_name*', MASTER_LOG_POS = *log_pos*
          |   SOURCE_LOG_FILE = '*log_name*', SOURCE_LOG_POS = *log_pos*
          |   RELAY_LOG_FILE = '*log_name*', RELAY_LOG_POS = *log_pos*
          |   SQL_AFTER_MTS_GAPS  }

*connection_options*:
    [USER='*user_name*'] [PASSWORD='*user_pass*'] [DEFAULT_AUTH='*plugin_name*'] [PLUGIN_DIR='*plugin_dir*']

*channel_option*:
    FOR CHANNEL *channel*

*gtid_set*:
    *uuid_set* [, *uuid_set*] ...
    | ''

*uuid_set*:
    *uuid*:*interval*[:*interval*]...

*uuid*:
    *hhhhhhhh*-*hhhh*-*hhhh*-*hhhh*-*hhhhhhhhhhhh*

*h*:
    [0-9,A-F]

*interval*:
    *n*[-*n*]

    (*n* >= 1)

START REPLICA启动复制线程，可以一起启动或分开启动。从 MySQL 8.0.22 开始，使用START REPLICA代替从该版本开始弃用的START SLAVE。在 MySQL 8.0.22 之前的版本中，请使用START SLAVE。

START REPLICA需要REPLICATION_SLAVE_ADMIN权限（或已弃用的SUPER权限）。START REPLICA导致正在进行的事务隐式提交。请参阅第 15.3.3 节，“导致隐式提交的语句”。

对于线程类型选项，您可以指定IO_THREAD，SQL_THREAD，这两者，或者都不指定。只有启动的线程受语句影响。

  • 没有线程类型选项的START REPLICA启动所有复制线程，同时具有线程类型选项的START REPLICA也是如此。

  • IO_THREAD启动复制接收器线程，从源服务器读取事件并将其存储在中继日志中。

  • SQL_THREAD启动复制应用程序线程，从中继日志中读取事件并执行它们。多线程复制（使用replica_parallel_workers或slave_parallel_workers>0）使用协调器线程和多个应用程序线程应用事务，而SQL_THREAD启动所有这些线程。

重要提示

START REPLICA在所有复制线程启动后向用户发送确认。然而，复制接收线程可能尚未成功连接到源，或者应用程序线程可能在启动后立即停止应用事件。START REPLICA在启动线程后不会继续监视线程，因此如果线程随后停止或无法连接，则不会警告您。您必须检查复制的错误日志以查看复制线程生成的错误消息，或者使用SHOW REPLICA STATUS检查它们是否正常运行。成功的START REPLICA语句会导致SHOW REPLICA STATUS显示Replica_SQL_Running=Yes，但可能会或可能不会显示Replica_IO_Running=Yes，因为只有在接收线程同时运行和连接时才会显示Replica_IO_Running=Yes。有关更多信息，请参见第 19.1.7.1 节，“检查复制状态”。

可选的FOR CHANNEL *channel*子句使您能够命名语句适用于哪个复制通道。提供FOR CHANNEL *channel*子句将START REPLICA语句应用于特定的复制通道。如果未命名任何子句且没有额外的通道存在，则该语句适用于默认通道。如果START REPLICA语句在使用多个通道时未定义通道，则此语句将为所有通道启动指定的线程。有关更多信息，请参见第 19.2.2 节，“复制通道”。

Group Replication 的复制通道（group_replication_applier和group_replication_recovery）由服务器实例自动管理。START REPLICA不能与group_replication_recovery通道一起使用，只能在 Group Replication 未运行时才能与group_replication_applier通道一起使用。group_replication_applier通道只有一个应用程序线程，没有接收线程，因此如果需要，可以使用SQL_THREAD选项启动它，而不使用IO_THREAD选项。

START REPLICA支持可插拔的用户密码身份验证（参见第 8.2.17 节，“可插拔身份验证”），使用USER、PASSWORD、DEFAULT_AUTH和PLUGIN_DIR选项，如下列表所述。当您使用这些选项时，必须启动接收线程（IO_THREAD选项）或所有复制线程；不能仅启动复制应用程序线程（SQL_THREAD选项）。

USER

用户账户的用户名。如果使用PASSWORD，则必须设置此选项。该选项不能设置为空或 null 字符串。

PASSWORD

指定用户账户的密码。

DEFAULT_AUTH

认证插件的名称。默认为 MySQL 本机认证。

PLUGIN_DIR

认证插件的位置。

重要

使用START REPLICA设置的密码在写入 MySQL Server 的日志、性能模式表和显示进程列表语句时会被掩码。但是，在传输过程中，它以明文形式发送到副本服务器实例。为了保护传输中的密码，使用 SSL/TLS 加密、SSH 隧道或其他方法保护连接，以防止未经授权的查看，用于发出START REPLICA的客户端与副本服务器实例之间的连接。

UNTIL子句使副本开始复制，然后处理事务直到您在UNTIL子句中指定的点，然后再次停止。UNTIL子句可用于使副本继续进行，直到您想要跳过不需要的事务的点之前，然后如第 19.1.7.3 节，“跳过事务”中所述跳过事务。要识别事务，您可以使用源二进制日志或副本中继日志的mysqlbinlog，或使用显示二进制日志事件语句。

您还可以使用UNTIL子句来通过逐个处理事务或分段处理事务来调试复制。如果您使用UNTIL子句来执行此操作，请使用--skip-slave-start选项启动副本，或从 MySQL 8.0.24 开始，使用skip_slave_start系统变量，以防止副本服务器启动时运行 SQL 线程。在过程完成后，删除选项或系统变量设置，以防止在意外服务器重新启动时被遗忘。

显示副本状态语句包括显示UNTIL条件当前值的输出字段。UNTIL条件持续时间取决于受影响线程是否仍在运行，并在它们停止时被移除。

UNTIL子句作用于复制应用程序线程（SQL_THREAD选项）。您可以使用SQL_THREAD选项或让副本默认启动两个线程。如果仅使用IO_THREAD选项，则UNTIL子句将被忽略，因为未启动应用程序线程。

您在UNTIL子句中指定的点可以是以下选项中的任何一个（且仅一个）：

SOURCE_LOG_FILE 和 SOURCE_LOG_POS（来自 MySQL 8.0.23），或 MASTER_LOG_FILE 和 MASTER_LOG_POS（到 MySQL 8.0.22）

这些选项使得复制应用程序处理事务直到其中继日志中的位置，该位置由源服务器上二进制日志中相应点的文件名和文件位置标识。应用程序线程在指定位置之后或之后找到最近的事务边界，完成应用事务，并在那里停止。对于压缩的事务有效载荷，请指定压缩的Transaction_payload_event的结束位置。

当在CHANGE REPLICATION SOURCE TO语句上设置了GTID_ONLY选项以阻止复制通道在复制元数据存储库中持久化文件名和文件位置时，仍然可以使用这些选项。文件名和文件位置在内存中被跟踪。

RELAY_LOG_FILE 和 RELAY_LOG_POS

这些选项使得复制应用程序处理事务直到副本的中继日志中的位置，该位置由中继日志文件名和该文件中的位置标识。应用程序线程在指定位置之后或之后找到最近的事务边界，完成应用事务，并在那里停止。对于压缩的事务有效载荷，请指定压缩的Transaction_payload_event的结束位置。

当在CHANGE REPLICATION SOURCE TO语句上设置了GTID_ONLY选项以阻止复制通道在复制元数据存储库中持久化文件名和文件位置时，仍然可以使用这些选项。文件名和文件位置在内存中被跟踪。

SQL_BEFORE_GTIDS

此选项使得复制应用程序开始处理事务，并在遇到任何位于指定 GTID 集中的事务时停止。来自 GTID 集的遇到的事务不会被应用，也不会应用 GTID 集中的任何其他事务。该选项接受包含一个或多个全局事务标识符的 GTID 集作为参数（参见 GTID Sets）。GTID 集中的事务不一定按照其 GTID 的顺序出现在复制流中，因此应用程序停止之前的事务不一定是最早的。

SQL_AFTER_GTIDS

此选项使得复制应用程序开始处理事务，并在处理完指定 GTID 集中的所有事务时停止。该选项接受包含一个或多个全局事务标识符的 GTID 集作为参数（参见 GTID Sets）。

使用 SQL_AFTER_GTIDS 后，复制线程在处理完 GTID 集中的所有事务后停止。事务按接收顺序处理，因此可能包括不属于 GTID 集的事务，但在集合中的所有事务提交之前接收（并处理）。例如，执行 START REPLICA UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 会导致复制获取（并处理）源中的所有事务，直到处理完序列号为 11 到 56 的所有事务，然后在达到该点后停止，不再处理任何额外的事务。

SQL_AFTER_GTIDS 与多线程应用程序不兼容。如果在多线程应用程序中使用此选项，将会引发警告，并且复制将切换到单线程模式。根据用例，可能可以使用 START REPLICA UNTIL MASTER_LOG_POS 或 START REPLICA UNTIL SQL_BEFORE_GTIDS。您还可以使用 WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()，它会等待到达正确位置，但不会停止应用程序线程。

SQL_AFTER_MTS_GAPS

对于仅多线程复制（具有replica_parallel_workers或slave_parallel_workers > 0）的情况，此选项使复制进程处理事务，直到从中继日志执行的事务序列中不再存在间隙为止。在使用多线程复制时，以下情况可能会导致间隙出现：

  • 协调器线程停止。

  • 应用程序线程发生错误。

  • mysqld 意外关闭。

当复制通道存在间隙时，复制的数据库处于可能从未存在于源上的状态。复制在内部跟踪间隙并禁止执行会删除间隙信息的 CHANGE REPLICATION SOURCE TO 语句。

在 MySQL 8.0.26 之前，在具有从中继日志执行的事务序列中存在间隙的多线程复制上发出 START REPLICA 会生成警告。要纠正这种情况，解决方案是使用 START REPLICA UNTIL SQL_AFTER_MTS_GAPS。有关更多信息，请参见 Section 19.5.1.34, “Replication and Transaction Inconsistencies”。

从 MySQL 8.0.26 开始，当使用基于 GTID 的复制和 GTID 自动定位（SOURCE_AUTO_POSITION=1）用于通道时，完全跳过检查事务序列中的间隙的过程，因为可以使用 GTID 自动定位来解决事务中的间隙。在这种情况下，START REPLICA UNTIL SQL_AFTER_MTS_GAPS只是在找到要执行的第一个事务时停止应用程序线程，并且不尝试检查事务序列中的间隙。您也可以像往常一样继续使用CHANGE REPLICATION SOURCE TO语句，并且通道可以进行中继日志恢复。

从 MySQL 8.0.27 开始，默认情况下所有副本都是多线程的。当replica_preserve_commit_order=ON或slave_preserve_commit_order=ON为副本设置时，这也是从 MySQL 8.0.27 开始的默认设置，除了在replica_preserve_commit_order和slave_preserve_commit_order的描述中列出的特定情况外，不应该出现间隙。如果为副本设置了replica_preserve_commit_order=OFF或slave_preserve_commit_order=OFF，这是在 MySQL 8.0.27 之前的默认设置，事务的提交顺序不会被保留，因此出现间隙的可能性要大得多。

如果没有使用 GTIDs，并且您需要将失败的多线程副本更改为单线程模式，您可以按照以下顺序发出以下一系列语句：

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;
START SLAVE SQL_THREAD;

Or from MySQL 8.0.26:
START REPLICA UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.replica_parallel_workers = 0;
START REPLICA SQL_THREAD;

原文：dev.mysql.com/doc/refman/8.0/en/start-slave.html

15.4.2.7 启动从库语句
START {SLAVE | REPLICA} [*thread_types*] [*until_option*] [*connection_options*] [*channel_option*]

*thread_types*:
    [*thread_type* [, *thread_type*] ... ]

*thread_type*:
    IO_THREAD | SQL_THREAD

*until_option*:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = *gtid_set*
          |   MASTER_LOG_FILE = '*log_name*', MASTER_LOG_POS = *log_pos*
          |   SOURCE_LOG_FILE = '*log_name*', SOURCE_LOG_POS = *log_pos*
          |   RELAY_LOG_FILE = '*log_name*', RELAY_LOG_POS = *log_pos*
          |   SQL_AFTER_MTS_GAPS  }

*connection_options*:
    [USER='*user_name*'] [PASSWORD='*user_pass*'] [DEFAULT_AUTH='*plugin_name*'] [PLUGIN_DIR='*plugin_dir*']

*channel_option*:
    FOR CHANNEL *channel*

*gtid_set*:
    *uuid_set* [, *uuid_set*] ...
    | ''

*uuid_set*:
    *uuid*:*interval*[:*interval*]...

*uuid*:
    *hhhhhhhh*-*hhhh*-*hhhh*-*hhhh*-*hhhhhhhhhhhh*

*h*:
    [0-9,A-F]

*interval*:
    *n*[-*n*]

    (*n* >= 1)

启动复制线程。从 MySQL 8.0.22 开始，START SLAVE 已被弃用，应改用别名 START REPLICA。该语句的工作方式与以前相同，只是语句及其输出所使用的术语已更改。使用时，两个版本的语句都会更新相同的状态变量。请参阅 START REPLICA 的文档以了解该语句的描述。

原文：dev.mysql.com/doc/refman/8.0/en/stop-replica.html

15.4.2.8 STOP REPLICA 语句
STOP REPLICA [*thread_types*] [*channel_option*]

*thread_types*:
    [*thread_type* [, *thread_type*] ... ]

*thread_type*: IO_THREAD | SQL_THREAD

*channel_option*:
    FOR CHANNEL *channel*

停止复制线程。从 MySQL 8.0.22 开始，使用 STOP REPLICA 替代已经废弃的 STOP SLAVE。在 MySQL 8.0.22 之前的版本中，请使用 STOP SLAVE。

STOP REPLICA 需要 REPLICATION_SLAVE_ADMIN 权限（或已废弃的 SUPER 权限）。推荐的最佳实践是在停止复制服务器之前在副本上执行 STOP REPLICA（有关更多信息，请参见 Section 7.1.19, “The Server Shutdown Process”）。

与 START REPLICA 类似，此语句可以与 IO_THREAD 和 SQL_THREAD 选项一起使用，以命名要停止的复制线程。请注意，Group Replication 应用程序通道（group_replication_applier）没有复制 I/O（接收器）线程，只有一个复制 SQL（应用程序）线程。因此，使用 SQL_THREAD 选项会完全停止此通道。

STOP REPLICA 导致正在进行的事务隐式提交。请参见 Section 15.3.3, “Statements That Cause an Implicit Commit”。

gtid_next 在执行此语句之前必须设置为 AUTOMATIC。

您可以通过设置系统变量 rpl_stop_replica_timeout（从 MySQL 8.0.26 开始）或 rpl_stop_slave_timeout（在 MySQL 8.0.26 之前）来控制 STOP REPLICA 在超时之前等待的时间。这可以用于避免 STOP REPLICA 与使用不同客户端连接到副本的其他 SQL 语句之间的死锁。当达到超时值时，发出命令的客户端会返回错误消息并停止等待，但 STOP REPLICA 指令仍然有效。一旦复制线程不再忙碌，STOP REPLICA 语句就会执行，副本就会停止。

在副本运行时允许一些CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO语句，具体取决于复制线程的状态。但是，在这种情况下，在执行CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO语句之前使用STOP REPLICA仍然受支持。有关更多信息，请参见第 15.4.2.3 节，“CHANGE REPLICATION SOURCE TO Statement”，第 15.4.2.1 节，“CHANGE MASTER TO Statement”和第 19.4.8 节，“故障切换期间切换源”。

可选的FOR CHANNEL *channel*子句使您可以命名语句适用于哪个复制通道。提供FOR CHANNEL *channel*子句将STOP REPLICA语句应用于特定的复制通道。如果未命名通道且没有额外通道存在，则该语句适用于默认通道。如果STOP REPLICA语句在使用多个通道时未命名通道，则此语句将停止所有通道的指定线程。有关更多信息，请参见第 19.2.2 节，“复制通道”。

Group Replication 的复制通道（group_replication_applier和group_replication_recovery）由服务器实例自动管理。STOP REPLICA不能与group_replication_recovery通道一起使用，并且仅在 Group Replication 未运行时才应与group_replication_applier通道一起使用。group_replication_applier通道仅具有一个应用程序线程，没有接收器线程，因此可以通过使用SQL_THREAD选项而不使用IO_THREAD选项来停止它。

当复制品是多线程的（replica_parallel_workers 或 slave_parallel_workers 的值不为零），从中继日志执行的事务序列中的任何间隙都将作为停止工作线程的一部分而关闭。如果复制品意外停止（例如由于工作线程中的错误或其他线程发出 KILL），而在执行 STOP REPLICA 语句时，从中继日志执行的事务序列可能变得不一致。有关更多信息，请参见 第 19.5.1.34 节，“复制和事务不一致性”。

当源使用基于行的二进制日志格式时，如果正在复制使用非事务性存储引擎的任何表，则应在关闭复制品服务器之前在复制品上执行 STOP REPLICA 或 STOP REPLICA SQL_THREAD。如果当前的复制事件组已修改了一个或多个非事务性表，STOP REPLICA 将等待最多 60 秒以完成事件组，除非您为复制 SQL 线程发出 KILL QUERY 或 KILL CONNECTION 语句。如果超时后事件组仍未完成，将记录错误消息。

当源使用基于语句的二进制日志格式时，在源具有打开临时表时更改源是潜在不安全的。这是为什么不建议使用基于语句的复制临时表的原因之一。您可以通过检查 Replica_open_temp_tables 或 Slave_open_temp_tables 的值来查看复制品上是否有任何临时表。在使用基于语句的复制时，在执行 CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO 之前，此值应为 0。如果在复制品上有任何临时表打开，在发出 STOP REPLICA 后再发出 CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO 语句会导致一个 ER_WARN_OPEN_TEMP_TABLES_MUST_BE_ZERO 警告。

原文：dev.mysql.com/doc/refman/8.0/en/stop-slave.html

15.4.2.9 停止从库语句
STOP {SLAVE | REPLICA} [*thread_types*] [*channel_option*]

*thread_types*:
    [*thread_type* [, *thread_type*] ... ]

*thread_type*: IO_THREAD | SQL_THREAD

*channel_option*:
    FOR CHANNEL *channel*

停止复制线程。从 MySQL 8.0.22 开始，STOP SLAVE已被弃用，应改用别名STOP REPLICA。该语句的工作方式与以前相同，只是语句和输出的术语已更改。使用时，两个版本的语句都会更新相同的状态变量。请参阅STOP REPLICA的文档，了解该语句的描述。

15.4.3 用于控制组复制的 SQL 语句

原文：dev.mysql.com/doc/refman/8.0/en/replication-statements-group.html

15.4.3.1 启动 GROUP_REPLICATION 语句

15.4.3.2 停止 GROUP_REPLICATION 语句

本节提供了用于控制组复制的语句的信息。

原文：dev.mysql.com/doc/refman/8.0/en/start-group-replication.html

15.4.3.1 START GROUP_REPLICATION Statement
 START GROUP_REPLICATION
          [USER='*user_name*']
          [, PASSWORD='*user_pass*']
          [, DEFAULT_AUTH='*plugin_name*']

启动组复制。此语句需要GROUP_REPLICATION_ADMIN权限（或已弃用的SUPER权限）。如果设置了super_read_only=ON并且成员应作为主服务器加入，则一旦 Group Replication 成功启动，super_read_only将设置为OFF。

参与单主模式组的服务器应使用skip_replica_start=ON。否则，服务器不允许作为辅助服务器加入组。

在 MySQL 8.0.21 及更高版本中，您可以使用USER、PASSWORD和DEFAULT_AUTH选项在START GROUP_REPLICATION语句中指定分布式恢复的用户凭据，如下所示：

  • USER: 用于分布式恢复的复制用户。有关设置此帐户的说明，请参见 Section 20.2.1.3, “User Credentials For Distributed Recovery”。如果指定了PASSWORD，则不能指定空字符串或 null 字符串，也不能省略USER选项。

  • PASSWORD: 复制用户帐户的密码。密码不能加密，但在查询日志中被掩码。

  • DEFAULT_AUTH: 用于复制用户帐户的身份验证插件的名称。如果不指定此选项，则假定使用 MySQL 本机身份验证（mysql_native_password插件）。此选项作为服务器的提示，并且在分布式恢复的捐赠者上，如果与用户帐户关联的不同插件，则会覆盖它。在 MySQL 8 中创建用户帐户时默认使用的身份验证插件是缓存 SHA-2 身份验证插件（caching_sha2_password）。有关身份验证插件的更多信息，请参见 Section 8.2.17, “Pluggable Authentication”。

这些凭据用于group_replication_recovery通道上的分布式恢复。当您在START GROUP_REPLICATION上指定用户凭据时，这些凭据仅保存在内存中，并且通过STOP GROUP_REPLICATION语句或服务器关闭而删除。您必须发出START GROUP_REPLICATION语句以再次提供凭据。因此，此方法与根据group_replication_start_on_boot系统变量在服务器启动时自动启动 Group Replication 不兼容。

在START GROUP_REPLICATION中指定的用户凭据优先于使用CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO语句（MySQL 8.0.23 之前）为group_replication_recovery通道设置的任何用户凭据。请注意，使用这些语句设置的用户凭据存储在复制元数据存储库中，并且在未指定用户凭据的情况下指定START GROUP_REPLICATION时使用，包括如果group_replication_start_on_boot系统变量设置为ON时的自动启动。为了获得在START GROUP_REPLICATION上指定用户凭据的安全性好处，请确保group_replication_start_on_boot设置为OFF（默认为ON），并按照第 20.6.3 节，“保护分布式恢复连接”中的说明清除先前为group_replication_recovery通道设置的任何用户凭据。

当成员重新加入复制组时，在组完成兼容性检查并接受其为成员之前，其状态可能显示为OFFLINE或ERROR。当成员正在赶上组的事务时，其状态为RECOVERING。

原文：dev.mysql.com/doc/refman/8.0/en/stop-group-replication.html

15.4.3.2 停止 GROUP_REPLICATION 语句
STOP GROUP_REPLICATION

停止 Group Replication。此语句需要 GROUP_REPLICATION_ADMIN 权限（或已弃用的 SUPER 权限）。一旦您发出 STOP GROUP_REPLICATION，该成员将被设置为 super_read_only=ON，这确保在 Group Replication 停止时无法对成员进行写入。该成员上运行的任何其他异步复制通道也将停止。在启动此成员上的 Group Replication 时在 START GROUP_REPLICATION 语句中指定的任何用户凭据将从内存中删除，并且在再次启动 Group Replication 时必须提供。

警告

使用此语句时要非常小心，因为它会将服务器实例从组中移除，这意味着它不再受到 Group Replication 一致性保证机制的保护。为了完全安全起见，在发出此语句之前，请确保您的应用程序无法连接到该实例，以避免任何陈旧读取的可能性。

STOP GROUP_REPLICATION 语句会停止组成员上的异步复制通道，但不像 STOP REPLICA 那样隐式提交正在进行的事务。这是因为在 Group Replication 组成员上，关闭操作期间提交的其他事务会使成员与组不一致，并导致重新加入时出现问题。为了避免在停止 Group Replication 时正在进行的事务失败提交，从 MySQL 8.0.28 开始，当将 GTID 分配为 gtid_next 系统变量的值时，不能发出 STOP GROUP_REPLICATION 语句。

group_replication_components_stop_timeout 系统变量指定了组复制在发出此语句后等待其各个模块完成正在进行的进程的时间。超时用于解决组复制组件无法正常停止的情况，这可能发生在成员在错误状态下被驱逐出组，或者在诸如 MySQL Enterprise Backup 正在持有成员表的全局锁时。在这种情况下，成员无法停止应用程序线程或完成分布式恢复过程以重新加入。STOP GROUP_REPLICATION 不会完成，直到情况得到解决（例如，通过释放锁），或者组件超时到期并且模块无论其状态如何都会关闭。在 MySQL 8.0.27 之前，默认组件超时为 31536000 秒，即 365 天。使用此设置，组件超时对于刚才描述的情况并不起作用，因此建议在这些 MySQL 8.0 版本中使用较低的设置。从 MySQL 8.0.27 开始，默认值为 300 秒；这意味着如果在此之前未解决情况，则在 5 分钟后停止组复制组件，从而允许成员重新启动并重新加入。

15.5 准备语句

原文：dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html

15.5.1 PREPARE 语句

15.5.2 EXECUTE 语句

15.5.3 DEALLOCATE PREPARE 语句

MySQL 8.0 支持服务器端准备语句。此支持利用了高效的客户端/服务器二进制协议。使用带有参数值占位符的准备语句具有以下优点：

  • 每次执行语句时解析语句的开销较小。通常，数据库应用程序处理大量几乎相同的语句，只有在查询和删除的WHERE、更新的SET以及插入的VALUES等子句中的文字或变量值发生变化。

  • 防止 SQL 注入攻击。参数值可以包含未转义的 SQL 引号和分隔符字符。

以下各节概述了准备语句的特性：

  • 应用程序中的准备语句

  • SQL 脚本中的准备语句

  • PREPARE、EXECUTE 和 DEALLOCATE PREPARE 语句

  • 准备语句中允许的 SQL 语法

应用程序中的准备语句

您可以通过客户端编程接口使用服务器端准备语句，包括用于 C 程序的 MySQL C API 客户端库，用于 Java 程序的 MySQL Connector/J，以及用于使用.NET 技术的程序的 MySQL Connector/NET。例如，C API 提供了一组构成其准备语句 API 的函数调用。请参阅 C API 准备语句接口。其他语言接口可以通过链接 C 客户端库提供支持，其中一个例子是mysqli扩展，可在 PHP 5.0 及更高版本中使用。

SQL 脚本中的准备语句

可用另一种 SQL 接口来处理准备语句。这种接口不如通过准备语句 API 使用二进制协议高效，但不需要编程，因为它直接在 SQL 级别提供：

  • 当您无法使用编程接口时，可以使用它。

  • 您可以从任何可以向服务器发送 SQL 语句以执行的程序中使用它，例如mysql客户端程序。

  • 即使客户端使用旧版本的客户端库，也可以使用它。

准备好的语句的 SQL 语法旨在用于以下情况：

  • 在编码之前测试准备好的语句在您的应用程序中的工作方式。

  • 当您没有访问支持它们的编程 API 时使用准备好的语句。

  • 与准备好的语句交互式地解决应用程序问题。

  • 创建一个重现准备好的语句问题的测试用例，以便您可以提交 bug 报告。

PREPARE、EXECUTE 和 DEALLOCATE PREPARE 语句

准备好的语句的 SQL 语法基于三个 SQL 语句：

  • PREPARE 为执行准备了一个语句（参见 Section 15.5.1, “PREPARE Statement”）。

  • EXECUTE 执行一个准备好的语句（参见 Section 15.5.2, “EXECUTE Statement”）。

  • DEALLOCATE PREPARE 释放一个准备好的语句（参见 Section 15.5.3, “DEALLOCATE PREPARE Statement”）。

以下示例展示了两种等效的准备好一个语句计算三角形的斜边长度的方法。

第一个示例展示了如何通过使用字符串文字来提供语句的文本来创建一个准备好的语句：

mysql> PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';
mysql> SET @a = 3;
mysql> SET @b = 4;
mysql> EXECUTE stmt1 USING @a, @b;
+------------+
| hypotenuse |
+------------+
|          5 |
+------------+
mysql> DEALLOCATE PREPARE stmt1;

第二个示例类似，但将语句的文本作为用户变量提供：

mysql> SET @s = 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';
mysql> PREPARE stmt2 FROM @s;
mysql> SET @a = 6;
mysql> SET @b = 8;
mysql> EXECUTE stmt2 USING @a, @b;
+------------+
| hypotenuse |
+------------+
|         10 |
+------------+
mysql> DEALLOCATE PREPARE stmt2;

以下是另一个示例，演示如何在运行时选择要执行查询的表，方法是将表名存储为用户变量：

mysql> USE test;
mysql> CREATE TABLE t1 (a INT NOT NULL);
mysql> INSERT INTO t1 VALUES (4), (8), (11), (32), (80);

mysql> SET @table = 't1';
mysql> SET @s = CONCAT('SELECT * FROM ', @table);

mysql> PREPARE stmt3 FROM @s;
mysql> EXECUTE stmt3;
+----+
| a  |
+----+
|  4 |
|  8 |
| 11 |
| 32 |
| 80 |
+----+

mysql> DEALLOCATE PREPARE stmt3;

准备好的语句特定于创建它的会话。如果您终止一个会话而没有取消分配先前准备好的语句，服务器会自动取消分配它。

准备好的语句也是会话全局的。如果您在存储过程中创建了一个准备好的语句，当存储过程结束时不会取消分配它。

为防止同时创建太多准备好的语句，设置 max_prepared_stmt_count 系统变量。要防止使用准备好的语句，将值设置为 0。

允许在准备好的语句中使用的 SQL 语法

以下 SQL 语句可用作准备好的语句：

ALTER TABLE
ALTER USER
ANALYZE TABLE
CACHE INDEX
CALL
CHANGE MASTER
CHECKSUM {TABLE | TABLES}
COMMIT
{CREATE | DROP} INDEX
{CREATE | RENAME | DROP} DATABASE
{CREATE | DROP} TABLE
{CREATE | RENAME | DROP} USER
{CREATE | DROP} VIEW
DELETE
DO
FLUSH {TABLE | TABLES | TABLES WITH READ LOCK | HOSTS | PRIVILEGES
  | LOGS | STATUS | MASTER | SLAVE | USER_RESOURCES}
GRANT
INSERT
INSTALL PLUGIN
KILL
LOAD INDEX INTO CACHE
OPTIMIZE TABLE
RENAME TABLE
REPAIR TABLE
REPLACE
RESET {MASTER | SLAVE}
REVOKE
SELECT
SET
SHOW BINLOG EVENTS
SHOW CREATE {PROCEDURE | FUNCTION | EVENT | TABLE | VIEW}
SHOW {MASTER | BINARY} LOGS
SHOW {MASTER | SLAVE} STATUS
SLAVE {START | STOP}
TRUNCATE TABLE
UNINSTALL PLUGIN
UPDATE

不支持其他语句。

为了符合 SQL 标准，该标准规定诊断语句不可准备，MySQL 不支持以下作为准备好的语句：

  • SHOW WARNINGS，SHOW COUNT(*) WARNINGS

  • SHOW ERRORS，SHOW COUNT(*) ERRORS

  • 包含对 warning_count 或 error_count 系统变量的任何引用的语句。

通常，SQL 预处理语句中不允许的语句在存储程序中也不允许。特殊情况在第 27.8 节，“存储程序的限制”中有说明。

当预处理语句引用的表或视图的元数据发生更改时，会检测到并在下次执行时自动重新准备该语句。更多信息，请参见第 10.10.3 节，“预处理语句和存储程序的缓存”。

使用预处理语句时，可以为LIMIT子句的参数使用占位符。参见第 15.2.13 节，“SELECT 语句”。

在与PREPARE和EXECUTE一起使用的预处理CALL语句中，从 MySQL 8.0 开始支持OUT和INOUT参数的占位符。请参见第 15.2.1 节，“CALL 语句”，以获取一个示例和早期版本的解决方法。无论版本如何，都可以为IN参数使用占位符。

预处理语句的 SQL 语法不能以嵌套方式使用。也就是说，传递给PREPARE的语句本身不能是PREPARE、EXECUTE或DEALLOCATE PREPARE语句。

预处理语句的 SQL 语法与使用预处理语句 API 调用是不同的。例如，你不能使用mysql_stmt_prepare() C API 函数来准备PREPARE、EXECUTE或DEALLOCATE PREPARE语句。

预处理语句的 SQL 语法可以在存储过程中使用，但不能在存储函数或触发器中使用。然而，不能对使用PREPARE和EXECUTE准备和执行的动态语句使用游标。游标的语句在游标创建时进行检查，因此语句不能是动态的。

预处理语句的 SQL 语法不支持多语句（即，在一个字符串中由;字符分隔的多个语句）。

要编写使用CALL SQL 语句执行包含准备语句的存储过程的 C 程序，必须启用CLIENT_MULTI_RESULTS标志。这是因为每个CALL都会返回一个结果以指示调用状态，除了存储过程内执行的语句可能返回的任何结果集。

当您调用mysql_real_connect()时，可以通过显式传递CLIENT_MULTI_RESULTS标志或隐式传递CLIENT_MULTI_STATEMENTS（也会启用CLIENT_MULTI_RESULTS）来启用CLIENT_MULTI_RESULTS。有关更多信息，请参见第 15.2.1 节，“CALL 语句”。

mysql错误码
liuxingbin的专栏
11-12 1万+
Mysql错误代码 Mysql错误代码分为两部分，老版本一部分，4.1版本为新的部分 第一部分: mysql的出错代码表，根据mysql的头文件mysql/include/mysqld_error.h整理而成 1005：创建表失败 1006：创建数据库失败 1007：数据库已存在，创建数据库失败 1008：数据库不存在，删除数据库失败 1009：不能删除数据库文件导致删除数据库失败 101
MySQL 中基于 XA 实现的分布式事务
加多的博客
07-07 4810
五、MySQL 中基于 XA 实现的分布式事务 5.1 XA协议 首先我们来简要看下分布式事务处理的XA规范 可知XA规范中分布式事务有AP，RM，TM组成： 其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。 资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软...
Apply Error 1399: Error
lwei_998的专栏
12-30 2248
问题描述 AWS RDS Slave 复制中断，RDS 控制台显示错误信息如下：  Apply Error 1399: Error 'XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state' on query. Default dat...
深入浅出MySQL 事务控制和锁定语句
19：30的博客
10-03 786
事务控制和锁定语句 ​ MySQL 支持对 MyISAM 和MEMORY 存储引擎的表进行表级锁定，对BDB存储引擎的表进行页级锁定，对InnoDB存储引擎的表进行行级锁定。默认情况下，表锁和行锁都是自动获得的，不需要额外的命令。但是在有的情况下，用户需要明确地进行锁表或者进行事务的控制，以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 LOCK TABLES 和 UNLOCK TABLES ​ LOCAK TABLES 可以锁定用于当前线程的表。如果表被其他线程锁定，则当前线程会等待
Mybatis时出现错误 The command cannot be executed when global transaction is in the ACTIVE state
weixin_45059961的博客
10-14 2175
项目环境 spring + mybatis +springmvc 百度了很多地方，很多都是多数据源，但是我的项目没有使用 最后检查文件发现 原来是开启了事务 而且 truncate 操作在事务里默认是不能回滚的 总结 单数据源碰到这个问题 先检查一下有没有事务所不允许的sql在运行 ...
mysql 事务 sql语句,MySQL的SQL语句 -事务性语句和锁定语句（7）- XA 事务状态
weixin_33195162的博客
03-17 531
XA 事务状态XA 事务进程包含以下状态：使用 XA START 启动 XA 事务并将其置于 ACTIVE 状态。对于 ACTIVE XA 事务，执行组成事务的 SQL 语句，然后执行 XA END 语句。XA END 将事务置于 IDLE 状态。对于 IDLE XA 事务，可以执行 XA PREPARE 语句或 XA COMMIT ... ONE PHASE 语句：■ XA PREPARE 将事...
flink checkpoint源码分析二
weixin_40809627的博客
09-22 772
概述：上一篇文文章总体接收了flinkcheckpoint的源码分析的总体概念和流程。并结合代码介绍了checkpoint的发起和任务执行过程 详细参考：https://blog.csdn.net/weixin_40809627/article/details/108537480 本篇文章将接着上篇文章，继续介绍 flink checkPoint 的检查点快照、本地状态存储、checkpoint的确认、和状态恢复等过程。 一、存储检查点状态快照 在task 触发了chckpoint 之后，对于Task而言，
MySQL8中文参考手册 MySQL DBA必备
09-02
MySQL参考手册。它的文件通过8.0.14 MySQL 8。它可以包括MySQL版本尚未发布功能的文档。关于哪个版本的信息已被释放，看到MySQL 8版本说明 MySQL集群是目前不在MySQL 8的支持。关于MySQL集群的信息，请参阅7.5、...
MySQL8中文参考手册 .chm
12-27
MySQL参考手册。它的文件通过8.0.14 MySQL 8。它可以包括MySQL版本尚未发布功能的文档。关于哪个版本的信息已被释放，看到MySQL 8版本说明 MySQL集群是目前不在MySQL 8的支持。关于MySQL集群的信息，请参阅7.5、...
MySQL8中文参考手册2022官方.zip
05-22
对于数据字典功能的其他含义，是指“数据字典的笔记“部分在MySQL 8版本说明 对MySQL数据字典的好处包括： 一个集中的数据字典，统一存储字典数据简单。看到第14，“数据字典” 基于元数据的存储文件的去除。看到...
mysql8中文参考手册
04-05
mysql8中文api，主要内容。安装和升级数据库，mysql安全，备份和恢复，字符集排序规则 ，sql语句语法。INnoDb存储引擎、 mysql数据字典、替代存储引擎，分布。mysql性能模式。连接器和api，sql模式指标 状态变量指标...
MySQL8 参考手册，中文.chm，英文 pdf 带书签
09-07
用户在学习和使用MySQL的过程中，可直接参考这些详尽的中文说明，无需频繁切换到英文界面，从而提高工作效率。 英文的mysql-8.0-英文_带书签.pdf文件则更适合那些对英文有较好掌握的用户，或者是希望能够直接参考...
mysql事物的状态_MySQL的SQL语句 -事务性语句和锁定语句（7）- XA 事务状态
weixin_39573781的博客
01-19 357
XA 事务状态XA 事务进程包含以下状态：使用 XA START 启动 XA 事务并将其置于 ACTIVE 状态。对于 ACTIVE XA 事务，执行组成事务的 SQL 语句，然后执行 XA END 语句。XA END 将事务置于 IDLE 状态。对于 IDLE XA 事务，可以执行 XA PREPARE 语句或 XA COMMIT ... ONE PHASE 语句：■ XA PREPARE 将事...
分布式事务解决方案
liushangzaibeijing的博客
06-04 2万+
本篇博文主要探究了微服务的分布式事务解决方案，内容主要包括 分布式事务概念、mysql对分布式事务框架支持、seata框架AT和TCC模式、以及最终一致性解决方案
Spring事务理解和配置
Student108的博客
09-07 2712
文章目录1 Spring事务1.1 事务简介1.1.1 什么是事务1.1.2 事物的特性1.1.3 不考虑事物会引发的安全问题1.1.4 事务隔离级别1.2 事务的传播行为1.3 编程式事务(需要手动写代码,了解)1.3.1 配置平台事务管理器1.3.2 Spring提供了事务管理的模板类1.3.3 在业务层注入事务管理的模板1.3.4 编写事务管理的代码1.4 声明式事务(xml配置)1.4.1 配置事务管理器1.4.2 配置增强1.4.3 AOP的配置1.5 声明式事务(注解)1.5.1 配置事务管理器
事务连接中断_DBLE XA事务源码分析
weixin_42161497的博客
12-29 287
原创： 高鹏 作者简介高鹏，github主页[https://github.com/tankilo]15年本科毕业，github平常心提ISSUE和PR，投稿希望能结交志同道合的朋友。本文目录：一、XA 本身（一）拓扑结构（二）MySQL XA SQL语法（三）XA事务状态变迁图（四）关注xa prepare（五）binlog二、DBLE XA实现分析（一）分库分表中间件用XA事务 解决跨库事务的...
mysql内核修改_TDSQL中修复的mysql内核bug
weixin_42469444的博客
01-19 345
在TDSQL这两年多的开发工作中，我感觉很自豪的一件事是我修复了不少mysql-5.7.17和mariadb-10.1.9的内核bug，这些bug大多已经报告给了MySQL/MariaDB官方开发团队，在每个bug描述中我会贴出来bug报告的连接。本文将大略介绍这些bug的概况，我在将来会写更多文章详细介绍每个bug的具体问题分析以及解决思路。本文列出的所有bug都已经修复，经过验证可以正确工作并...
XA 事务
weixin_30655219的博客
09-18 354
4.11.3 什么是XA 事务？ 《数据库程序员面试笔试宝典》第4章数据库基础，本章主要介绍数据库基础部分的面试题，比较适合应届毕业生，也适合由其他岗位转数据库岗位的人员。本节为大家介绍什么是XA 事务。 作者：猿媛之家来源：机械工业出版社|2018-11-09 4.11.3 什么是XA 事务？ XA（eXtended Architecture）是指由X/Open...
分布式事务之——MySQL对XA事务的支持
热门推荐
冰河的专栏
03-31 2万+
 MySQL 从5.0.3开始支持XA分布式事务，且只有InnoDB存储引擎支持。MySQL Connector/J 从5.0.0版本之后开始直接提供对XA的支持。 需要注意的是， 在DTP模型中，mysql属于资源管理器(RM)。而一个完整的分布式事务中，一般会存在多个RM，由事务管理器TM来统一进行协调。因此，这里所说的mysql对XA分布式事务的支持，一般指的是单台mysql实例如何执行自己...
MySQL8 中文参考（二）
最新发布
01-16
为了获取MySQL 8的中文参考文档或教程，可以访问《MySQL 8中文参考手册》，这是一份专门为MySQL数据库管理员(DBA)以及所有使用MySQL 8.0.14及以上版本的开发者精心准备的手册[^1]。 此外，《MySQL8中文手册》提供了...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值