--master-info-file=file_name

现在不推荐使用此选项。如果已设置，它用于设置副本的连接元数据存储库的文件名 master_info_repository=FILE 。--master-info-file 和 master_info_repository 系统变量的使用已被弃用，因为连接元数据存储库的文件已被崩溃安全表取代。有关连接元数据存储库的信息，请参阅 第 17.2.4.2 节，“复制元数据存储库”。

--master-retry-count=count

副本在放弃之前尝试重新连接到源的次数。默认值为 86400 次。值 0 表示“无限”，副本尝试永远连接。当副本达到其连接超时（由 replica_net_timeout或 slave_net_timeout系统变量指定）而没有从源接收数据或心跳信号时，将触发重新连接尝试。SOURCE_CONNECT_RETRY以| 设置的时间间隔尝试重新连接 |MASTER_CONNECT_RETRY的选项 语句（默认为每 60 秒）。 CHANGE REPLICATION SOURCE TOCHANGE MASTER TO

此选项已弃用；希望在未来的 MySQL 版本中将其删除。使用 SOURCE_RETRY_COUNT| |MASTER_RETRY_COUNT的选项 声明代替。 CHANGE REPLICATION SOURCE TOCHANGE MASTER TO

--max-relay-log-size=size

服务器自动轮换中继日志文件的大小。如果此值不为零，则中继日志在其大小超过此值时会自动轮换。如果此值为零（默认值），则发生中继日志轮换的大小由 的值确定 max_binlog_size。有关详细信息，请参阅第 17.2.4.1 节，“中继日志”。

--relay-log-purge={0|1}

一旦不再需要，就禁用或启用中继日志的自动清除。默认值为 1（启用）。这是一个全局变量，可以使用 动态更改。在启用该选项时禁用清除中继日志会 冒数据一致性的风险，因此不是崩溃安全的。 SET GLOBAL relay_log_purge = N--relay-log-recovery

--relay-log-space-limit=size

此选项对副本上所有中继日志的总大小（以字节为单位）设置上限。值为 0 表示 “无限制”. 这对于磁盘空间有限的副本服务器主机很有用。当达到限制时，I/O（接收方）线程停止从源服务器读取二进制日志事件，直到 SQL 线程赶上并删除一些未使用的中继日志。请注意，此限制不是绝对的：在某些情况下，SQL（应用程序）线程需要更多事件才能删除中继日志。在这种情况下，接收线程会超过限制，直到应用程序线程可以删除一些中继日志，因为不这样做会导致死锁。您不应设置--relay-log-space-limit 为小于值的两倍 --max-relay-log-size（或者 --max-binlog-size如果 --max-relay-log-size为 0）。在那种情况下，接收线程有可能因为超出而等待空闲空间 --relay-log-space-limit，但是应用程序线程没有要清除的中继日志并且无法满足接收线程。这会强制接收线程 --relay-log-space-limit 暂时忽略。

--replicate-do-db=db_name

使用数据库的名称创建复制过滤器。也可以使用创建此类过滤器 CHANGE REPLICATION FILTER REPLICATE_DO_DB。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。channel_1在名为use 的通道上配置特定于通道的复制过滤器 。在这种情况下，第一个冒号被解释为分隔符，随后的冒号是原义冒号。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。 --replicate-do-db:channel_1:db_name

此复制筛选器的确切效果取决于是否正在使用基于语句或基于行的复制。

基于语句的复制。  告诉复制 SQL 线程将复制限制为默认数据库（即由 选定的数据库USE） 为 的语句db_name。要指定多个数据库，请多次使用此选项，每个数据库一次；但是，这样做 不会复制跨数据库语句，例如选择不同的数据库（或没有选择数据库）。 UPDATE some_db.some_table SET foo='bar'

使用基于语句的复制时无法正常工作的示例：如果副本启动--replicate-do-db=sales 并在源上发出以下语句， UPDATE则 不会复制该语句：

USE prices;
UPDATE sales.january SET amount=amount+1000;

这种“只检查默认数据库”行为 的主要原因是，很难仅从语句中知道它是否应该被复制（例如，如果您正在使用多表 DELETE语句或UPDATE 跨多个操作的多表语句数据库）。如果没有必要，只检查默认数据库而不是所有数据库也会更快。

基于行的复制。  告诉复制 SQL 线程限制复制到数据库db_name。只有属于的表db_name被更改；当前数据库对此没有影响。假设副本启动 --replicate-do-db=sales并且基于行的复制生效，然后在源上运行以下语句：

USE prices;
UPDATE sales.february SET amount=amount+100;

replica上的数据库中的february表 sales是按照UPDATE 语句改变的；无论 USE声明是否发布，都会发生这种情况。但是，在使用基于行的复制和时，在源上发出以下语句对副本没有影响--replicate-do-db=sales：

USE prices;
UPDATE prices.march SET amount=amount-25;

即使将语句USE prices更改为USE sales， UPDATE语句的效果仍然不会被复制。

--replicate-do-db与基于行的复制相比，基于语句的复制的处理方式的 另一个重要区别 在于引用多个数据库的语句。假设副本以 开始 --replicate-do-db=db1，并在源上执行以下语句：

USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

如果您使用的是基于语句的复制，那么两个表都会在副本上更新。但是，当使用基于行的复制时，只会table1影响副本；因为table2在不同的数据库中，table2所以副本不会被 UPDATE. 现在假设使用USE db1了一个 USE db4语句而不是语句：

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

在这种情况下，UPDATE 当使用基于语句的复制时，该语句对副本没有影响。但是，如果您使用的是基于行的复制， 副本UPDATE会发生变化 table1，但不会 table2——换句话说，只有命名为 的数据库中的表 --replicate-do-db会发生变化，默认数据库的选择对此行为没有影响。

如果您需要跨数据库更新才能工作，请 改用。请参阅第 17.2.5 节，“服务器如何评估复制过滤规则”。 --replicate-wild-do-table=db_name.%

--replicate-ignore-db=db_name

使用数据库的名称创建复制过滤器。也可以使用创建此类过滤器 CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。channel_1在名为use 的通道上配置特定于通道的复制过滤器 。在这种情况下，第一个冒号被解释为分隔符，随后的冒号是原义冒号。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。 --replicate-ignore-db:channel_1:db_name

要指定多个要忽略的数据库，请多次使用此选项，每个数据库一次。因为数据库名称可以包含逗号，所以如果您提供以逗号分隔的列表，它将被视为单个数据库的名称。

与 一样--replicate-do-db，此过滤的精确效果取决于使用的是基于语句的复制还是基于行的复制，这将在接下来的几段中进行描述。

基于语句的复制。  告诉复制 SQL 线程不要复制默认数据库（即由 选定的数据库USE）为 的任何语句db_name。

基于行的复制。  告诉复制 SQL 线程不要更新数据库中的任何表db_name。默认数据库没有影响。

使用基于语句的复制时，以下示例不会像您预期的那样工作。假设副本开始于 --replicate-ignore-db=sales 并且您在源上发出以下语句：

USE prices;
UPDATE sales.january SET amount=amount+1000;

在这种情况下 会复制 该UPDATE语句 ，因为它仅适用于默认数据库（由该 语句确定）。因为 在语句中明确指定了数据库，所以语句没有被过滤。但是，当使用基于行的复制时， 语句的效果不会传播到副本，副本的 表副本也不会改变；在这种情况下， 导致对源的副本中的表进行的所有更改--replicate-ignore-dbUSEsalesUPDATEsales.january--replicate-ignore-db=salessales 被副本忽略的数据库。

如果您正在使用跨数据库更新并且不希望复制这些更新，则不应使用此选项。请参阅第 17.2.5 节，“服务器如何评估复制过滤规则”。

如果您需要跨数据库更新才能工作，请 改用。请参阅第 17.2.5 节，“服务器如何评估复制过滤规则”。 --replicate-wild-ignore-table=db_name.%

--replicate-do-table=db_name.tbl_name

通过告诉复制 SQL 线程将复制限制到给定的表来创建复制过滤器。要指定多个表，请多次使用此选项，每个表一次。这适用于跨数据库更新和默认数据库更新，与 --replicate-do-db. 请参阅 第 17.2.5 节，“服务器如何评估复制过滤规则”。您还可以通过发出 CHANGE REPLICATION FILTER REPLICATE_DO_TABLE语句来创建这样的过滤器。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。channel_1在名为use 的通道上配置特定于通道的复制过滤器 。在这种情况下，第一个冒号被解释为分隔符，随后的冒号是原义冒号。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。 --replicate-do-table:channel_1:db_name.tbl_name

此选项仅影响适用于表的语句。它不影响仅适用于其他数据库对象的语句，例如存储例程。要过滤对存储例程进行操作的语句，请使用一个或多个 --replicate-*-db选项。

--replicate-ignore-table=db_name.tbl_name

通过告诉复制 SQL 线程不要复制任何更新指定表的语句来创建复制过滤器，即使任何其他表可能由同一语句更新。要指定要忽略的多个表，请多次使用此选项，每个表一次。这适用于跨数据库更新，与 --replicate-ignore-db. 请参阅 第 17.2.5 节，“服务器如何评估复制过滤规则”。您还可以通过发出 CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE 语句来创建这样的过滤器。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。channel_1在名为use 的通道上配置特定于通道的复制过滤器 。在这种情况下，第一个冒号被解释为分隔符，随后的冒号是原义冒号。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。 --replicate-ignore-table:channel_1:db_name.tbl_name

此选项仅影响适用于表的语句。它不影响仅适用于其他数据库对象的语句，例如存储例程。要过滤对存储例程进行操作的语句，请使用一个或多个 --replicate-*-db选项。

--replicate-rewrite-db=from_name->to_name

告诉副本创建一个复制过滤器，将指定的数据库转换为 to_name它是否 from_name在源上。只有涉及表的语句会受到影响，而 、 和 等语句不会CREATE DATABASE受到 DROP DATABASE影响 ALTER DATABASE。

要指定多次重写，请多次使用此选项。服务器使用具有 from_name匹配值的第一个。数据库名称翻译 在 测试规则之前完成。--replicate-*您还可以通过发出 CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB语句来创建这样的过滤器。

如果您 --replicate-rewrite-db在命令行上使用该选项并且该> 字符对于您的命令解释器来说是特殊的，请引用该选项值。例如：

$> mysqld --replicate-rewrite-db="olddb->newdb"

该 --replicate-rewrite-db选项的效果因查询使用的是基于语句还是基于行的二进制日志记录格式而异。使用基于语句的格式，DML 语句根据语句指定的当前数据库进行转换 USE。使用基于行的格式，DML 语句根据修改表所在的数据库进行转换。DDL 语句始终根据 USE语句指定的当前数据库进行过滤，而不管二进制日志记录格式如何。

为确保重写产生预期结果，尤其是与其他复制过滤选项结合使用时，请在使用该 --replicate-rewrite-db 选项时遵循以下建议：

如果遵循这些建议，则可以安全地将 --replicate-rewrite-db选项与表级复制过滤选项结合使用，例如 --replicate-do-table.

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。指定通道名称后跟一个冒号，然后是过滤器规范。第一个冒号被解释为分隔符，任何后续冒号都被解释为文字冒号。例如，要在名为 的通道上配置特定于通道的复制过滤器 channel_1，请使用：

$> mysqld --replicate-rewrite-db=channel_1:db_name1->db_name2

如果您使用冒号但未指定通道名称，则该选项会为默认复制通道配置复制过滤器。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。

--replicate-same-server-id

此选项用于副本。默认值为 0 ( FALSE)。将此选项设置为 1 ( TRUE)，副本不会跳过具有自己的服务器 ID 的事件。此设置通常仅在极少数配置中有用。

在副本上启用二进制日志记录时， 如果服务器是循环复制拓扑的一部分，副本上的--replicate-same-server-id 和选项的组合可能会导致复制无限循环。--log-slave-updates（在 MySQL 8.0 中，默认启用二进制日志记录，启用二进制日志记录时默认启用副本更新日志记录。）但是，全局事务标识符 (GTID) 的使用通过跳过已经执行的事务的执行来防止这种情况。应用。如果 gtid_mode=ON在副本上设置，您可以使用此选项组合启动服务器，但您不能在服务器运行时更​​改为任何其他 GTID 模式。如果设置了任何其他 GTID 模式，则服务器不会使用此选项组合启动。

默认情况下，复制 I/O（接收方）线程不会将二进制日志事件写入中继日志，如果它们具有副本的服务器 ID（此优化有助于节省磁盘使用量）。如果你想使用 --replicate-same-server-id，请确保在让副本读取它自己的你希望复制 SQL（应用程序）线程执行的事件之前使用此选项启动副本。

--replicate-wild-do-table=db_name.tbl_name

通过告知复制 SQL（应用程序）线程将复制限制为任何更新表与指定数据库和表名称模式匹配的语句来创建复制过滤器。模式可以包含 %和_通配符，其含义与 LIKE模式匹配运算符相同。要指定多个表，请多次使用此选项，每个表一次。这适用于跨数据库更新。请参阅第 17.2.5 节，“服务器如何评估复制过滤规则”。您还可以通过发出 CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE 语句来创建这样的过滤器。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。channel_1在名为use 的通道上配置特定于通道的复制过滤器 。在这种情况下，第一个冒号被解释为分隔符，随后的冒号是原义冒号。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。 --replicate-wild-do-table:channel_1:db_name.tbl_name

该 --replicate-wild-do-table 选项指定的复制过滤器适用于表、视图和触发器。它不适用于存储过程和函数或事件。要过滤对后面的对象进行操作的语句，请使用一个或多个--replicate-*-db选项。

例如， --replicate-wild-do-table=foo%.bar% 仅复制使用数据库名称以 开头foo且表名称以 开头的表的更新bar。

如果表名模式是%，它匹配任何表名并且该选项也适用于数据库级语句（CREATE DATABASE、DROP DATABASE和ALTER DATABASE）。例如，如果您使用 --replicate-wild-do-table=foo%.%，如果数据库名称与模式匹配，则会复制数据库级语句foo%。

要在数据库或表名称模式中包含文字通配符，请使用反斜杠对它们进行转义。例如，要复制名为 的数据库的所有表 my_own%db，但不复制my1ownAABCdb数据库中的表，您应该转义_和% 字符，如下所示： --replicate-wild-do-table=my\_own\%db。如果您在命令行上使用该选项，则可能需要加倍反斜杠或引用选项值，具体取决于您的命令解释器。例如，对于 bash shell，您需要键入 --replicate-wild-do-table=my\\_own\\%db.

--replicate-wild-ignore-table=db_name.tbl_name

创建一个复制过滤器，防止复制 SQL 线程复制任何表与给定通配符模式匹配的语句。要指定要忽略的多个表，请多次使用此选项，每个表一次。这适用于跨数据库更新。请参阅 第 17.2.5 节，“服务器如何评估复制过滤规则”。您还可以通过发出 CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE 语句来创建这样的过滤器。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。channel_1在名为use 的通道上配置特定于通道的复制过滤器 。在这种情况下，第一个冒号被解释为分隔符，随后的冒号是原义冒号。有关更多信息，请参阅 第 17.2.5.4 节，“基于复制通道的过滤器” 。 --replicate-wild-ignore:channel_1:db_name.tbl_name

例如， --replicate-wild-ignore-table=foo%.bar% 不复制使用数据库名称以 开头foo且表名称以 开头的表的更新bar。有关匹配如何工作的信息，请参阅--replicate-wild-do-table 选项的描述。在选项值中包含文字通配符的规则也与 for 相同 --replicate-wild-ignore-table 。

如果您需要过滤掉 GRANT语句或其他管理语句，一个可能的解决方法是使用--replicate-ignore-db 过滤器。此过滤器在当前有效的默认数据库上运行，由 USE语句确定。因此，您可以创建一个过滤器来忽略未复制的数据库的语句，然后 USE在发出您想要忽略的任何管理语句之前立即发出将默认数据库切换到该数据库的语句。在管理语句中，命名应用该语句的实际数据库。

例如，如果 --replicate-ignore-db=nonreplicated 在副本服务器上配置，则以下语句序列会导致该 GRANT语句被忽略，因为默认数据库 nonreplicated有效：

USE nonreplicated;
GRANT SELECT, INSERT ON replicated.t1 TO 'someuser'@'somehost';

--skip-replica-start

从 MySQL 8.0.26 开始，使用 --skip-replica-start代替--skip-slave-start，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 --skip-slave-start.

--skip-replica-start告诉副本服务器在服务器启动时不要启动复制 I/O（接收方）和 SQL（应用程序）线程。要稍后启动线程，请使用 START REPLICA语句。

您可以使用 skip_replica_start系统变量代替命令行选项，以允许使用 MySQL Server 的特权结构访问此功能，这样数据库管理员就不需要对操作系统的任何特权访问。

--skip-slave-start

从 MySQL 8.0.26 开始， 已弃用，应改用--skip-slave-start别名 。--skip-replica-start在 MySQL 8.0.26 之前的版本中，使用 --skip-slave-start.

告诉副本服务器在服务器启动时不要启动复制 I/O（接收方）和 SQL（应用程序）线程。要稍后启动线程，请使用 START REPLICA语句。

从 MySQL 8.0.24 开始，您可以使用 skip_slave_start系统变量代替命令行选项，以允许使用 MySQL Server 的权限结构访问此功能，这样数据库管理员就不需要对操作系统的任何特权访问。

--slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]

通常，当副本发生错误时，复制会停止，这使您有机会手动解决数据中的不一致问题。当语句返回选项值中列出的任何错误时，此选项会导致复制 SQL 线程继续复制。

除非您完全理解为什么会出错，否则不要使用此选项。如果您的复制设置和客户端程序没有错误，并且 MySQL 本身也没有错误，那么停止复制的错误应该永远不会发生。不加选择地使用此选项会导致副本与源完全不同步，而您不知道为什么会发生这种情况。

对于错误代码，您应该使用副本的错误日志和 的输出中的错误消息提供的数字SHOW REPLICA STATUS。附录 B，错误消息和常见问题，列出了服务器错误代码。

速记值ddl_exist_errors相当于错误代码列表 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146。

您也可以（但不应该）使用非常不推荐的值all来使副本忽略所有错误消息并继续运行而不管发生什么。不用说，如果您使用all，则无法保证数据的完整性。在这种情况下，如果副本的数据与源上的数据相去甚远，请不要抱怨（或提交错误报告）。你已被警告。

NDB由于检查纪元序列号 的内部机制，在 NDB 集群之间复制时，此选项不会以相同的方式工作 ；通常，一旦 NDB检测到缺少或顺序不正确的纪元号，它会立即停止副本应用程序线程。从 NDB 8.0.28 开始，您可以通过同时指定 --ndb-applier-allow-skip-epoch with来覆盖此行为--slave-skip-errors；这样做会导致NDB忽略跳过的纪元交易。

例子：

--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors

--slave-sql-verify-checksum={0|1}

启用此选项后，副本会检查从中继日志中读取的校验和。如果不匹配，副本会因错误而停止。

--abort-slave-event-count

当此选项设置为 value0（默认值）以外的某个正整数时，它会影响复制行为，如下所示：复制 SQL 线程启动后， value允许执行日志事件；之后，复制 SQL 线程不再接收任何事件，就像来自源的网络连接被切断一样。复制 SQL 线程继续运行，输出 SHOW REPLICA STATUS显示Yes在Replica_IO_Running和 Replica_SQL_Running列中，但没有从中继日志中读取更多事件。

MySQL 测试套件在内部使用此选项进行复制测试和调试。它不适用于生产环境。从 MySQL 8.0.29 开始，它已被弃用，并可能在未来版本的 MySQL 中删除。

--disconnect-slave-event-count

MySQL 测试套件在内部使用此选项进行复制测试和调试。它不适用于生产环境。从 MySQL 8.0.29 开始，它已被弃用，并可能在未来版本的 MySQL 中删除。

init_replica

从 MySQL 8.0.26 开始，使用 init_replica代替 init_slave，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用init_slave.

init_replica类似于 init_connect，但它是每次复制 SQL 线程启动时由副本服务器执行的字符串。init_connect字符串的格式与变量的格式相同 。START REPLICA该变量的设置对后续语句 生效 。

init_slave

从 MySQL 8.0.26 开始， 已弃用， 应改用init_slave别名。init_replica在 MySQL 8.0.26 之前的版本中，使用 init_slave.

init_slave类似于 init_connect，但它是每次复制 SQL 线程启动时由副本服务器执行的字符串。init_connect字符串的格式与变量的格式相同 。START REPLICA该变量的设置对后续语句 生效 。

log_slow_replica_statements

从 MySQL 8.0.26 开始，使用 log_slow_replica_statements 代替 log_slow_slave_statements，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 log_slow_slave_statements.

启用慢速查询日志后， 为在副本上执行时间log_slow_replica_statements 超过几秒的查询启用日志记录 。long_query_time请注意，如果基于行的复制正在使用 ( binlog_format=ROW)， log_slow_replica_statements 则无效。只有在二进制日志中以语句格式记录查询时，查询才会添加到副本的慢查询日志中，即 binlog_format=STATEMENT设置为 when 时，或者 binlog_format=MIXED设置为 statement 格式时记录语句。设置时以行格式记录的慢速查询 binlog_format=MIXED，或记录时 binlog_format=ROW已设置，即使 log_slow_replica_statements 已启用，也不会添加到副本的慢查询日志中。

设置 log_slow_replica_statements 不会立即生效。变量的状态适用于所有后续 START REPLICA语句。另请注意，全局设置long_query_time 适用于 SQL 线程的生命周期。如果更改该设置，则必须停止并重新启动复制 SQL 线程以在那里实施更改（例如，通过发出带有选项STOP REPLICA的 START REPLICA语句 SQL_THREAD）。

log_slow_slave_statements

从 MySQL 8.0.26 开始， 已弃用， 应改用log_slow_slave_statements 别名 。log_slow_replica_statements在 MySQL 8.0.26 之前的版本中，使用 log_slow_slave_statements.

启用慢速查询日志后， 为在副本上执行时间log_slow_slave_statements 超过几秒的查询启用日志记录 。long_query_time请注意，如果基于行的复制正在使用 ( binlog_format=ROW)， log_slow_slave_statements 则无效。只有在二进制日志中以语句格式记录查询时，查询才会添加到副本的慢查询日志中，即 binlog_format=STATEMENT设置为 when 时，或者 binlog_format=MIXED设置为 statement 格式时记录语句。设置时以行格式记录的慢速查询 binlog_format=MIXED，或记录时 binlog_format=ROW已设置，即使 log_slow_slave_statements 已启用，也不会添加到副本的慢查询日志中。

设置 log_slow_slave_statements 不会立即生效。变量的状态适用于所有后续 START REPLICA语句。另请注意，全局设置long_query_time 适用于 SQL 线程的生命周期。如果更改该设置，则必须停止并重新启动复制 SQL 线程以在那里实施更改（例如，通过发出带有选项STOP REPLICA的 START REPLICA语句 SQL_THREAD）。

master_info_repository

现在不推荐使用此系统变量。该设置TABLE是默认设置，并且在配置多个复制通道时是必需的。替代设置FILE以前已弃用。

使用默认设置，副本将有关源的元数据（包括状态和连接信息）记录到系统数据库中名为 的InnoDB表中 。有关连接元数据存储库的更多信息，请参阅 第 17.2.4 节，“中继日志和复制元数据存储库”。 mysqlmysql.slave_master_info

该FILE设置将副本的连接元数据存储库写入 master.info默认命名的文件。可以使用该 --master-info-file选项更改名称。

max_relay_log_size

如果副本对其中继日志的写入导致当前日志文件大小超过此变量的值，则副本将轮转中继日志（关闭当前文件并打开下一个文件）。如果 max_relay_log_size为 0，则服务器 max_binlog_size同时使用二进制日志和中继日志。如果 max_relay_log_size大于 0，它会限制中继日志的大小，这使您可以为两个日志设置不同的大小。您必须设置 max_relay_log_size在 4096 字节和 1GB（含）之间，或设置为 0。默认值为 0。请参阅 第 17.2.3 节，“复制线程”。

relay_log

中继日志文件的基本名称。对于默认复制通道，中继日志的默认基本名称是 host_name-relay-bin. 对于非默认复制通道，中继日志的默认基本名称是 ，其中是记录在此中继日志中的复制通道的名称。 host_name-relay-bin-channelchannel

服务器将文件写入数据目录，除非给定基本名称和前导绝对路径名以指定不同的目录。服务器通过向基本名称添加数字后缀来按顺序创建中继日志文件。

复制服务器上的中继日志和中继日志索引不能与二进制日志和二进制日志索引重名，二进制日志和二进制日志索引的名称由 --log-bin和 --log-bin-index选项指定。如果二进制日志和中继日志文件的基本名称相同，服务器会发出一条错误消息并且不会启动。

由于 MySQL 解析服务器选项的方式，如果您在服务器启动时指定此变量，则必须提供一个值；仅当未实际指定该选项时才使用默认基本名称。如果relay_log在服务器启动时指定系统变量而不指定值，则可能会导致意外行为；此行为取决于使用的其他选项、​​指定它们的顺序以及它们是在命令行上还是在选项文件中指定。有关 MySQL 如何处理服务器选项的更多信息，请参阅 第 4.2.2 节，“指定程序选项”。

如果指定此变量，则指定的值也用作中继日志索引文件的基本名称。relay_log_index您可以通过使用系统变量 指定不同的中继日志索引文件基本名称来覆盖此行为 。

当服务器从索引文件中读取一个条目时，它会检查该条目是否包含相对路径。如果是，则路径的相对部分将替换为使用 relay_log系统变量设置的绝对路径。绝对路径保持不变；在这种情况下，必须手动编辑索引以启用要使用的新路径。

您可能会发现relay_log 系统变量在执行以下任务时很有用：

relay_log_basename您可以从系统变量 中获取中继日志文件名（和路径） 。

relay_log_basename

保存中继日志文件的基本名称和完整路径。最大变量长度为 256。该变量由服务器设置并且是只读的。

relay_log_index

中继日志索引文件的名称。最大变量长度是 256。如果你没有指定这个变量，但是指定了 relay_log系统变量，它的值被用作中继日志索引文件的默认基本名称。如果 relay_log也未指定，则对于默认复制通道，默认名称为 host_name-relay-bin.index，使用主机名。对于非默认复制通道，默认名称为 ，其中是记录在该中继日志索引中的复制通道的名称。 host_name-relay-bin-channel.indexchannel

中继日志文件的默认位置是数据目录，或使用relay_log系统变量指定的任何其他位置。您可以使用 relay_log_index系统变量来指定替代位置，方法是将前导绝对​​路径名添加到基本名称以指定不同的目录。

复制服务器上的中继日志和中继日志索引不能与二进制日志和二进制日志索引重名，二进制日志和二进制日志索引的名称由 --log-bin和 --log-bin-index选项指定。如果二进制日志和中继日志文件的基本名称相同，服务器会发出一条错误消息并且不会启动。

由于 MySQL 解析服务器选项的方式，如果您在服务器启动时指定此变量，则必须提供一个值；仅当未实际指定该选项时才使用默认基本名称。如果relay_log_index在服务器启动时指定系统变量而不指定值，则可能会导致意外行为；此行为取决于使用的其他选项、​​指定它们的顺序以及它们是在命令行上还是在选项文件中指定。有关 MySQL 如何处理服务器选项的更多信息，请参阅 第 4.2.2 节，“指定程序选项”。

relay_log_info_file

现在不推荐使用此系统变量。如果已设置，它用于设置副本的应用程序元数据存储库的文件名 relay_log_info_repository=FILE 。 relay_log_info_file和 relay_log_info_repository 系统变量的使用已被弃用，因为应用程序元数据存储库的文件已被崩溃安全表取代。有关应用程序元数据存储库的信息，请参阅 第 17.2.4.2 节，“复制元数据存储库”。

relay_log_info_repository

现在不推荐使用此系统变量。该设置TABLE是默认设置，并且在配置多个复制通道时是必需的。副本的应用程序元数据存储库的TABLE设置也需要使复制对意外停止具有弹性。有关更多信息，请参阅 第 17.4.2 节，“处理副本的意外停止” 。替代设置 FILE以前已弃用。

使用默认设置，副本将其应用程序元数据存储库存储为名为 的系统数据库 中的InnoDB表。有关应用程序元数据存储库的更多信息，请参阅 第 17.2.4 节，“中继日志和复制元数据存储库”。 mysqlmysql.slave_relay_log_info

该FILE设置将副本的应用程序元数据存储库写入 relay-log.info默认命名的文件。可以使用 relay_log_info_file系统变量更改名称。

relay_log_purge

一旦不再需要，禁用或启用中继日志文件的自动清除。默认值为 1 ( ON)。

relay_log_recovery

如果启用，此变量会在服务器启动后立即启用自动中继日志恢复。恢复过程创建一个新的中继日志文件，将 SQL（应用程序）线程位置初始化到这个新的中继日志，并将 I/O（接收方）线程初始化到应用程序线程位置。然后继续从源读取中继日志。如果SOURCE_AUTO_POSITION=1使用该 CHANGE REPLICATION SOURCE TO选项为复制通道设置，则用于启动复制的源位置可能是在连接中接收到的位置，而不是在此过程中分配的位置。

这个全局变量在运行时是只读的。它的值可以 --relay-log-recovery在副本服务器启动时使用选项设置，应该在副本意外停止后使用，以确保没有处理可能损坏的中继日志，并且必须使用它来保证崩溃安全的副本。默认值为 0（禁用）。有关对意外停止最具弹性的副本设置组合的信息，请参阅 第 17.4.2 节，“处理副本的意外停止”。

对于多线程副本（ replica_parallel_workers或 slave_parallel_workers大于 0）， --relay-log-recovery启动时的设置会自动处理从中继日志执行的事务序列中的任何不一致和间隙。当使用基于文件位置的复制时，可能会出现这些间隙。（有关更多详细信息，请参阅 第 17.5.1.34 节，“复制和事务不一致”。）中继日志恢复过程使用与 START REPLICA UNTIL SQL_AFTER_MTS_GAPS语句会。当副本达到一致的无间隙状态时，中继日志恢复过程继续从 SQL（应用程序）线程位置开始从源获取更多事务。当使用基于 GTID 的复制时，从 MySQL 8.0.18 开始，多线程副本首先检查是否 MASTER_AUTO_POSITION设置为 ON，如果是，则省略计算应该跳过或不跳过的事务的步骤，以便旧的中继日志恢复过程不需要。

relay_log_space_limit

用于所有中继日志的最大空间量。

replica_checkpoint_group

从 MySQL 8.0.26 开始，使用 replica_checkpoint_group代替 slave_checkpoint_group，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_checkpoint_group.

replica_checkpoint_group 设置在调用检查点操作以更新其状态之前多线程副本可以处理的最大事务数，如 所示 SHOW REPLICA STATUS。设置此变量对未启用多线程的副本没有影响。设置此变量不会立即生效。变量的状态适用于所有后续 START REPLICA 命令。

该变量与 replica_checkpoint_period 系统变量结合使用，当超过任一限制时，将执行检查点，并重置跟踪交易数量和自上次检查点以来经过的时间的计数器。

此变量的最小允许值为 32，除非服务器是使用构建的 -DWITH_DEBUG，在这种情况下最小值为 1。有效值始终为 8 的倍数；您可以将它设置为一个不是这样的倍数的值，但服务器在存储该值之前将其向下舍入为下一个较小的 8 倍数。（例外：调试服务器不执行此类舍入。）无论服务器是如何构建的，默认值为 512，最大允许值为 524280。

replica_checkpoint_period

从 MySQL 8.0.26 开始，使用 replica_sql_verify_checksum 代替 slave_sql_verify_checksum，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_sql_verify_checksum.

replica_checkpoint_period 设置在调用检查点操作以更新多线程副本的状态之前允许通过的最长时间（以毫秒为单位），如 所示 SHOW REPLICA STATUS。设置此变量对未启用多线程的副本没有影响。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

该变量与 replica_checkpoint_group 系统变量结合使用，当超过任一限制时，将执行检查点，并重置跟踪交易数量和自上次检查点以来经过的时间的计数器。

此变量的最小允许值为 1，除非服务器是使用 构建的 -DWITH_DEBUG，在这种情况下最小值为 0。无论服务器是如何构建的，默认值为 300 毫秒，最大可能值为 4294967295 毫秒（约 49.7 天）。

replica_compressed_protocol

从 MySQL 8.0.26 开始，使用 replica_compressed_protocol 代替 slave_compressed_protocol，已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_compressed_protocol.

replica_compressed_protocol 如果源和副本都支持，则指定是否使用源/副本连接协议的压缩。如果此变量被禁用（默认），连接将被解压缩。对此变量的更改会在后续的连接尝试中生效；这包括在发出一条START REPLICA语句之后，以及由正在运行的复制 I/O（接收方）线程进行的重新连接。

由系统变量激活的二进制日志事务压缩（自 MySQL 8.0.20 起可用） binlog_transaction_compression 也可用于节省带宽。如果将二进制日志事务压缩与协议压缩结合使用，则协议压缩对数据进行操作的机会较少，但仍可以压缩标头以及那些未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参阅 第 5.4.4.5 节，“二进制日志事务压缩”。

如果 replica_compressed_protocol 启用，它优先于 为语句SOURCE_COMPRESSION_ALGORITHMS指定的任何选项。在这种情况下，如果源和副本都支持该算法，则与CHANGE REPLICATION SOURCE TO源的连接将使用压缩。zlib如果 replica_compressed_protocol 禁用，则 SOURCE_COMPRESSION_ALGORITHMS应用的值。有关更多信息，请参阅 第 4.2.8 节，“连接压缩控制”。

replica_exec_mode

从 MySQL 8.0.26 开始，使用 replica_exec_mode代替slave_exec_mode，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_exec_mode.

replica_exec_mode控制复制线程如何解决复制期间的冲突和错误。IDEMPOTENT模式导致抑制重复键和未找到键的错误； STRICT意味着不会发生这种抑制。

IDEMPOTENTmode 旨在用于 NDB Cluster Replication 的多源复制、循环复制和其他一些特殊复制场景。（有关更多信息，请参阅 第 23.7.10 节，“NDB Cluster 复制：双向和循环复制”和 第 23.7.11 节，“NDB Cluster 复制冲突解决”。）NDB Cluster 忽略为明确设置的任何值 replica_exec_mode，并始终将其视为作为IDEMPOTENT。

在 MySQL Server 8.0 中，STRICT mode 是默认值。

设置此变量对所有复制通道（包括正在运行的通道）立即生效。

对于除 之外的存储引擎 NDB， IDEMPOTENT仅当您绝对确定可以安全地忽略重复键错误和未找到键错误时，才应使用模式。它旨在用于采用多源复制或循环复制的 NDB Cluster 的故障转移场景，不建议在其他情况下使用。

replica_load_tmpdir

从 MySQL 8.0.26 开始，使用 replica_load_tmpdir代替slave_load_tmpdir，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_load_tmpdir.

replica_load_tmpdir 指定副本创建临时文件的目录名称。设置此变量会立即对所有复制通道生效，包括正在运行的通道。默认情况下，变量值等于tmpdir系统变量的值，或者在未指定该系统变量时应用的默认值。

复制 SQL 线程在复制一条 LOAD DATA语句时，会从中继日志中提取要加载的文件到临时文件中，然后将这些文件加载​​到表中。如果源上加载的文件很大，则副本上的临时文件也很大。因此，建议使用此选项告诉副本将临时文件放在某个具有大量可用空间的文件系统中的目录中。在那种情况下，中继日志也很大，因此您可能还需要设置 relay_log系统变量以将中继日志放置在该文件系统中。

此选项指定的目录应位于基于磁盘的文件系统（而不是基于内存的文件系统）中，以便用于复制 LOAD DATA语句的临时文件可以在机器重新启动后继续存在。该目录也不应该是在系统启动过程中被操作系统清除的目录。但是，如果临时文件已被删除，复制现在可以在重新启动后继续。

replica_max_allowed_packet

从 MySQL 8.0.26 开始，使用 replica_max_allowed_packet 代替 slave_max_allowed_packet，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_max_allowed_packet.

replica_max_allowed_packet 设置复制 SQL（应用程序）和 I/O（接收方）线程可以处理的最大数据包大小（以字节为单位）。设置此变量会立即对所有复制通道生效，包括正在运行的通道。添加事件标头后，源可能会写入比其 max_allowed_packet设置更长的二进制日志事件。的设置 replica_max_allowed_packet 必须大于 max_allowed_packet源上的设置，以便使用基于行的复制的大型更新不会导致复制失败。

这个全局变量的值始终是 1024 的正整数倍；如果您将其设置为某个不是的值，则该值将向下舍入为下一个最高的 1024 倍数，因为它已被存储或使用；设置 replica_max_allowed_packet为 0 会导致使用 1024。（在所有此类情况下都会发出截断警告。）默认值和最大值为 1073741824 (1 GB)；最小值为 1024。

replica_net_timeout

从 MySQL 8.0.26 开始，使用 replica_net_timeout代替slave_net_timeout，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_net_timeout.

replica_net_timeout 指定在副本认为连接断开、中止读取并尝试重新连接之前等待更多数据或来自源的心跳信号的秒数。设置此变量不会立即生效。变量的状态适用于所有后续 START REPLICA命令。

默认值为 60 秒（一分钟）。第一次重试在超时后立即发生。重试之间的间隔由语句的 SOURCE_CONNECT_RETRY选项 控制CHANGE REPLICATION SOURCE TO ，重新连接尝试的次数受SOURCE_RETRY_COUNT选项限制。

心跳间隔，如果连接仍然良好，则停止在没有数据的情况下发生的连接超时，由 语句的SOURCE_HEARTBEAT_PERIOD选项 控制。CHANGE REPLICATION SOURCE TO心跳间隔默认为 值的一半replica_net_timeout，它记录在副本的连接元数据存储库中，并显示在 replication_connection_configuration Performance Schema 表中。请注意，更改值或默认设置 replica_net_timeout不会自动更改心跳间隔，无论是已明确设置还是使用先前计算的默认值。如果更改了连接超时，您还必须CHANGE REPLICATION SOURCE TO将心跳间隔调整为适当的值，以便在连接超时之前发生。

replica_parallel_type

从 MySQL 8.0.26 开始，使用 replica_parallel_type代替 slave_parallel_type，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_parallel_type.

对于多线程副本（ replica_parallel_workers或 slave_parallel_workers设置为大于 0 的值的副本）， replica_parallel_type 指定用于决定允许哪些事务在副本上并行执行的策略。该变量对未启用多线程的副本没有影响。可能的值是：

replica_preserve_commit_order 启用或 时 slave_preserve_commit_order ，您必须使用LOGICAL_CLOCK. 在 MySQL 8.0.27 之前，DATABASE是默认的。从 MySQL 8.0.27 开始，副本服务器默认启用多线程（replica_parallel_workers=4 默认情况下），并且LOGICAL_CLOCK是默认的。（在 MySQL 8.0.27 及更高版本中， replica_preserve_commit_order 也默认启用。）

当复制拓扑使用多个级别的副本时，LOGICAL_CLOCK对于副本远离源的每个级别，可能会实现较少的并行化。为了补偿这种影响，您应该 在源 上以及每个中间副本上设置或 设置binlog_transaction_dependency_tracking， 以指定在可能的情况下使用写入集而不是时间戳来进行并行化。 WRITESETWRITESET_SESSION

binlog_transaction_compression 当使用系统变量 启用二进制日志事务压缩时 ，如果replica_parallel_type设置为DATABASE，则在调度事务之前映射所有受事务影响的数据库。DATABASE与为每个事件映射和调度的未压缩事务相比，将 二进制日志事务压缩与策略一起使用可以降低并行度。

replica_parallel_type从 MySQL 8.0.29 开始弃用，支持使用数据库分区的事务并行化。期望在未来的版本中删除对这些的支持，并在以后LOGICAL_CLOCK专门使用。

replica_parallel_workers

从 MySQL 8.0.26 开始，使用 replica_parallel_workers代替 slave_parallel_workers，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_parallel_workers.

replica_parallel_workers 在副本上启用多线程并设置用于并行执行复制事务的应用程序线程数。当该值为大于 1 的数字时，副本是一个多线程副本，具有指定数量的应用程序线程，加上一个协调器线程来管理它们。如果您使用多个复制通道，则每个通道都有此数量的线程。

在 MySQL 8.0.27 之前，这个系统变量默认为 0，所以副本默认是单线程的。从 MySQL 8.0.27 开始，默认值为 4，因此副本默认为多线程。

从 MySQL 8.0.30 开始，不推荐将此变量设置为 0，这样做会引发警告；0 作为允许的值replica_parallel_workers将在未来的 MySQL 版本中删除；改为将其设置为 1，效果相同。

在副本上启用多线程时支持重试事务。replica_preserve_commit_order=ON 设置或 设置时 slave_preserve_commit_order=ON ，副本上的事务将按照它们在副本的中继日志中出现的相同顺序在副本上外部化。事务在应用程序线程之间分布的方式由 replica_parallel_type（从 MySQL 8.0.26 开始）或 slave_parallel_type（在 MySQL 8.0.26 之前）配置。从 MySQL 8.0.27 开始，这些系统变量也有适合多线程的默认值。

要禁用并行执行，请设置 replica_parallel_workers为 1，这会为副本提供单个应用程序线程而没有协调程序线程。使用此设置， replica_parallel_typeor slave_parallel_type和 replica_preserve_commit_order or slave_preserve_commit_order 系统变量将不起作用并被忽略。CHANGE REPLICATION SOURCE TO 从 MySQL 8.0.27 开始，如果在副本上启用该选项时禁用并行执行 GTID_ONLY，则副本实际上使用一个并行工作程序来利用重试事务而不访问文件位置的方法。对于一个并行工作人员， replica_preserve_commit_order 或者 slave_preserve_commit_order 系统变量也没有作用。

设置 replica_parallel_workers 不会立即生效。变量的状态适用于所有后续 START REPLICA语句。

replica_pending_jobs_size_max

从 MySQL 8.0.26 开始，使用 replica_pending_jobs_size_max 代替 slave_pending_jobs_size_max，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_pending_jobs_size_max.

对于多线程副本，此变量设置可用于持有尚未应用的事件的应用程序队列的最大内存量（以字节为单位）。设置此变量对未启用多线程的副本没有影响。设置此变量不会立即生效。变量的状态适用于所有后续 START REPLICA命令。

此变量的最小可能值为 1024 字节；默认值为 128MB。最大可能值为 18446744073709551615（16 exbibytes）。在存储之前，不是 1024 字节的精确倍数的值将向下舍入为下一个较低的 1024 字节倍数。

此变量的值是一个软限制，可以设置为与正常工作负载相匹配。如果异常大的事件超过此大小，事务将被暂停，直到所有工作线程的队列都为空，然后再进行处理。所有后续交易都将暂停，直到大笔交易完成。

replica_preserve_commit_order

从 MySQL 8.0.26 开始，使用 replica_preserve_commit_order 代替 slave_preserve_commit_order，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_preserve_commit_order.

对于多线程副本（ replica_parallel_workers设置为大于 0 的值的副本），设置 replica_preserve_commit_order=ON 确保事务在副本上执行和提交的顺序与它们在副本的中继日志中出现的顺序相同。这可以防止从副本的中继日志执行的事务序列中出现间隙，并在副本上保留与源上相同的事务历史记录（具有下面列出的限制）。此变量对未启用多线程的副本没有影响。

在 MySQL 8.0.27 之前，该系统变量默认为 OFF，这意味着事务可能会乱序提交。从MySQL 8.0.27开始，副本服务器默认开启多线程（replica_parallel_workers=4 by default）， replica_preserve_commit_order=ON 也是默认的，设置 replica_parallel_type=LOGICAL_CLOCK 也是默认的。同样从 MySQL 8.0.27 开始， replica_preserve_commit_order 如果设置为 1，则忽略 replica_parallel_workers设置，因为在这种情况下，无论如何都会保留事务的顺序。

副本上不需要二进制日志记录和副本更新日志记录来设置 replica_preserve_commit_order=ON，并且可以根据需要禁用。设置 replica_preserve_commit_order=ON 要求 replica_parallel_type设置为LOGICAL_CLOCK，这 不是MySQL 8.0.27之前的默认设置。replica_preserve_commit_order 在更改和的值之前 replica_parallel_type，必须停止复制 SQL 线程（对于所有复制通道，如果您使用多个复制通道）。

设置时 replica_preserve_commit_order=OFF ，多线程副本并行应用的事务可能会乱序提交。因此，检查最近执行的事务并不能保证来自源的所有先前事务都已在副本上执行。从副本的中继日志执行的事务序列中可能存在间隙。这对使用多线程副本时的日志记录和恢复有影响。有关更多信息，请参阅 第 17.5.1.34 节，“复制和事务不一致” 。

设置时 replica_preserve_commit_order=ON ，正在执行的工作线程会等到所有先前的事务都已提交后再提交。当给定的线程正在等待其他工作线程提交它们的事务时，它将其状态报告为Waiting for preceding transaction to commit。使用此模式，多线程副本永远不会进入源未处于的状态。这支持使用复制进行读取扩展。请参阅 第 17.4.5 节，“使用复制进行横向扩展”。

replica_sql_verify_checksum

从 MySQL 8.0.26 开始，使用 replica_sql_verify_checksum 代替 slave_sql_verify_checksum，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_sql_verify_checksum.

slave_sql_verify_checksum 使复制 SQL（应用程序）线程使用从中继日志读取的校验和来验证数据。如果不匹配，副本会因错误而停止。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

replica_transaction_retries

从 MySQL 8.0.26 开始，使用 replica_transaction_retries 代替 slave_transaction_retries，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_transaction_retries.

replica_transaction_retries 设置单线程或多线程副本上复制 SQL 线程在停止前自动重试失败事务的最大次数。设置此变量会立即对所有复制通道生效，包括正在运行的通道。默认值为 10。将变量设置为 0 将禁用事务的自动重试。

InnoDB如果复制 SQL 线程由于死锁或因为事务的执行时间超过 InnoDBs innodb_lock_wait_timeout或 NDBs TransactionDeadlockDetectionTimeout 或 而无法执行事务，它会 在因错误而停止之前TransactionInactiveTimeout自动重试 times。replica_transaction_retries不会重试具有非临时错误的事务。

Performance Schema 表 在列中replication_applier_status 显示了每个复制通道上发生的重试次数 COUNT_TRANSACTIONS_RETRIES。Performance Schema 表 replication_applier_status_by_worker 显示了单线程或多线程副本上各个应用程序线程重试事务的详细信息，并标识了导致最后一个事务和当前正在进行的事务被重试的错误。

replica_type_conversions

从 MySQL 8.0.26 开始，使用 replica_type_conversions代替 slave_type_conversions，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_type_conversions.

replica_type_conversions 使用基于行的复制时，控制对副本有效的类型转换模式。它的值是一个逗号分隔的集合，由列表中的零个或多个元素组成： ALL_LOSSY, ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED。将此变量设置为空字符串以禁止源和副本之间的类型转换。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

有关适用于基于行的复制中的属性提升和降级的类型转换模式的其他信息，请参阅 基于行的复制：属性提升和降级。

replication_optimize_for_static_plugin_config

使用共享锁，避免不必要的锁获取，以提高半同步复制的性能。随着副本数量的增加，此设置 replication_sender_observe_commit_only 会有所帮助，因为争用锁会降低性能。启用此系统变量后，无法卸载半同步复制插件，因此您必须在卸载完成之前禁用该系统变量。

该系统变量可以在安装半同步复制插件之前或之后启用，也可以在复制运行时启用。半同步复制源服务器也可以通过启用此系统变量获得性能优势，因为它们使用与副本相同的锁定机制。

replication_optimize_for_static_plugin_config 可以在服务器上使用组复制时启用。在这种情况下，当由于高工作负载而争用锁时，它可能会提高性能。

replication_sender_observe_commit_only

限制回调以提高半同步复制的性能。随着副本数量的增加，此设置 replication_optimize_for_static_plugin_config 会有所帮助，因为争用锁会降低性能。

该系统变量可以在安装半同步复制插件之前或之后启用，也可以在复制运行时启用。半同步复制源服务器也可以通过启用此系统变量获得性能优势，因为它们使用与副本相同的锁定机制。

report_host

在副本注册期间要报告给源的副本的主机名或 IP 地址。该值出现在 SHOW REPLICAS源服务器上的输出中。如果您不希望副本向源注册自己，请保留该值。

report_password

副本注册时上报给源的副本账号密码。如果源是用或 启动的，则此值出现在 SHOW REPLICAS源服务器上 的输出中。 --show-replica-auth-info--show-slave-auth-info

尽管此变量的名称可能另有含义， report_password但未连接到 MySQL 用户权限系统，因此不一定（甚至可能）与 MySQL 复制用户帐户的密码相同。

report_port

用于连接到副本的 TCP/IP 端口号，将在副本注册期间报告给源。仅当副本在非默认端口上侦听或者如果您有从源或其他客户端到副本的特殊隧道时才设置此项。如果不确定，请不要使用此选项。

此选项的默认值是副本实际使用的端口号。这也是 显示的默认值 SHOW REPLICAS。

report_user

在副本注册期间要报告给源的副本的帐户用户名。如果源是用或 启动的，则此值出现在 SHOW REPLICAS源服务器上 的输出中。 --show-replica-auth-info--show-slave-auth-info

尽管此变量的名称可能另有含义， report_user但未连接到 MySQL 用户权限系统，因此不一定（甚至可能）与 MySQL 复制用户帐户的名称相同。

rpl_read_size

rpl_read_size系统变量控制从二进制日志文件和中继日志文件读取的最小数据量（以字节为单位） 。如果这些文件的繁重磁盘 I/O 活动阻碍了数据库的性能，那么当文件数据当前未被操作系统缓存时，增加读取大小可能会减少文件读取和 I/O 停顿。

的最小值和默认值为 rpl_read_size8192 字节。该值必须是 4KB 的倍数。请注意，为从二进制日志和中继日志文件读取的每个线程分配了此值大小的缓冲区，包括源上的转储线程和副本上的协调器线程。因此，设置较大的值可能会对服务器的内存消耗产生影响。

rpl_semi_sync_replica_enabled

rpl_semi_sync_replica_enabledrpl_semi_sync_replica 在副本上安装了( semisync_replica.solibrary ) 插件以设置半同步复制 时可用 。如果安装了rpl_semi_sync_slave 插件（semisync_slave.so库）， rpl_semi_sync_slave_enabled 则可用。

rpl_semi_sync_replica_enabled 控制是否在副本服务器上启用半同步复制。要启用或禁用插件，请分别将此变量设置为ON或 OFF（或 1 或 0）。默认值为OFF。

此变量仅在安装了副本端半同步复制插件时可用。

rpl_semi_sync_replica_trace_level

rpl_semi_sync_replica_trace_levelrpl_semi_sync_replica 在副本上安装了( semisync_replica.solibrary ) 插件以设置半同步复制 时可用 。如果安装了rpl_semi_sync_slave 插件（semisync_slave.so库）， rpl_semi_sync_slave_trace_level 则可用。

rpl_semi_sync_replica_trace_level 控制副本服务器上的半同步复制调试跟踪级别。请参阅 rpl_semi_sync_master_trace_level 允许值。

此变量仅在安装了副本端半同步复制插件时可用。

rpl_semi_sync_slave_enabled

rpl_semi_sync_slave_enabledrpl_semi_sync_slave 在副本上安装了( semisync_slave.solibrary ) 插件以设置半同步复制 时可用。如果安装了rpl_semi_sync_replica 插件（semisync_replica.so库）， rpl_semi_sync_replica_enabled 则可用。

rpl_semi_sync_slave_enabled 控制是否在副本服务器上启用半同步复制。要启用或禁用插件，请分别将此变量设置为ON或 OFF（或 1 或 0）。默认值为OFF。

此变量仅在安装了副本端半同步复制插件时可用。

rpl_semi_sync_slave_trace_level

rpl_semi_sync_slave_trace_levelrpl_semi_sync_slave 在副本上安装了( semisync_slave.solibrary ) 插件以设置半同步复制 时可用。如果安装了rpl_semi_sync_replica 插件（semisync_replica.so库）， rpl_semi_sync_replica_trace_level 则可用。

rpl_semi_sync_slave_trace_level 控制副本服务器上的半同步复制调试跟踪级别。请参阅 rpl_semi_sync_master_trace_level 允许值。

此变量仅在安装了副本端半同步复制插件时可用。

rpl_stop_replica_timeout

从 MySQL 8.0.26 开始，使用 rpl_stop_replica_timeout代替 rpl_stop_slave_timeout，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 rpl_stop_slave_timeout.

STOP REPLICA您可以通过设置此变量来控制超时前等待 的时间长度（以秒为单位） 。这可用于避免 STOP REPLICA使用与副本的不同客户端连接的其他 SQL 语句之间的死锁。

的最大值和默认值为 rpl_stop_replica_timeout31536000 秒（1 年）。最小值为 2 秒。STOP REPLICA对此变量的更改对后续语句 生效 。

此变量仅影响发出 STOP REPLICA语句的客户端。当达到超时时，发出命令的客户端返回一条错误消息，指出命令执行未完成。客户端然后停止等待复制 I/O（接收方）和 SQL（应用程序）线程停止，但复制线程继续尝试停止， STOP REPLICA指令仍然有效。一旦复制线程不再繁忙， STOP REPLICA就会执行语句并停止副本。

rpl_stop_slave_timeout

从 MySQL 8.0.26 开始， 已弃用， 应改用rpl_stop_slave_timeout别名 。rpl_stop_replica_timeout在 MySQL 8.0.26 之前的版本中，使用 rpl_stop_slave_timeout.

STOP REPLICA您可以通过设置此变量来控制超时前等待 的时间长度（以秒为单位） 。这可用于避免 STOP REPLICA使用与副本的不同客户端连接的其他 SQL 语句之间的死锁。

的最大值和默认值为 rpl_stop_slave_timeout31536000 秒（1 年）。最小值为 2 秒。STOP REPLICA对此变量的更改对后续语句 生效 。

此变量仅影响发出 STOP REPLICA语句的客户端。当达到超时时，发出命令的客户端返回一条错误消息，指出命令执行未完成。客户端然后停止等待复制 I/O（接收方）和 SQL（应用程序）线程停止，但复制线程继续尝试停止， STOP REPLICA指令仍然有效。一旦复制线程不再繁忙， STOP REPLICA就会执行语句并停止副本。

skip_replica_start

从 MySQL 8.0.26 开始，使用 skip_replica_start代替skip_slave_start，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 skip_slave_start.

skip_replica_start告诉副本服务器在服务器启动时不要启动复制 I/O（接收方）和 SQL（应用程序）线程。要稍后启动线程，请使用 START REPLICA 语句。

该系统变量是只读的，可以通过使用PERSIST_ONLY关键字或 带有语句的@@persist_only限定符 来设置。SET命令行选项也设置这个 --skip-replica-start系统变量。您可以使用系统变量代替命令行选项，以允许使用 MySQL Server 的特权结构访问此功能，这样数据库管理员就不需要对操作系统的任何特权访问。

skip_slave_start

从 MySQL 8.0.26 开始， 已弃用，应改用skip_slave_start别名 。skip_replica_start在 MySQL 8.0.26 之前的版本中，使用 skip_slave_start.

告诉副本服务器在服务器启动时不要启动复制 I/O（接收方）和 SQL（应用程序）线程。要稍后启动线程，请使用 START REPLICA语句。

此系统变量可从 MySQL 8.0.24 获得。它是只读的，可以通过 在语句中使用PERSIST_ONLY关键字或 @@persist_only限定符 来设置。SET命令行选项也设置这个 --skip-slave-start系统变量。您可以使用系统变量代替命令行选项，以允许使用 MySQL Server 的特权结构访问此功能，这样数据库管理员就不需要对操作系统的任何特权访问。

slave_checkpoint_group

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_checkpoint_group别名 。replica_checkpoint_group在 MySQL 8.0.26 之前的版本中，使用 slave_checkpoint_group.

slave_checkpoint_group设置在调用检查点操作以更新其状态之前多线程副本可以处理的最大事务数，如 所示 SHOW REPLICA STATUS。设置此变量对未启用多线程的副本没有影响。设置此变量不会立即生效。变量的状态适用于所有后续 START REPLICA命令。

该变量与 slave_checkpoint_period 系统变量结合使用，当超过任一限制时，将执行检查点，并重置跟踪交易数量和自上次检查点以来经过的时间的计数器。

此变量的最小允许值为 32，除非服务器是使用构建的 -DWITH_DEBUG，在这种情况下最小值为 1。有效值始终为 8 的倍数；您可以将它设置为一个不是这样的倍数的值，但服务器在存储该值之前将其向下舍入为下一个较小的 8 倍数。（例外：调试服务器不执行此类舍入。）无论服务器是如何构建的，默认值为 512，最大允许值为 524280。

slave_checkpoint_period

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_checkpoint_period别名 。replica_checkpoint_period在 MySQL 8.0.26 之前的版本中，使用 slave_checkpoint_period.

slave_checkpoint_period 设置在调用检查点操作以更新多线程副本的状态之前允许通过的最长时间（以毫秒为单位），如 所示 SHOW REPLICA STATUS。设置此变量对未启用多线程的副本没有影响。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

该变量与 slave_checkpoint_group 系统变量结合使用，当超过任一限制时，将执行检查点，并重置跟踪交易数量和自上次检查点以来经过的时间的计数器。

此变量的最小允许值为 1，除非服务器是使用 构建的 -DWITH_DEBUG，在这种情况下最小值为 0。无论服务器是如何构建的，默认值为 300 毫秒，最大可能值为 4294967295 毫秒（约 49.7 天）。

slave_compressed_protocol

slave_compressed_protocol 已弃用，从 MySQL 8.0.26 开始， replica_compressed_protocol 应改用别名。在 MySQL 8.0.26 之前的版本中，使用 slave_compressed_protocol.

slave_compressed_protocol 如果源和副本都支持，控制是否使用源/副本连接协议的压缩。如果此变量被禁用（默认），连接将被解压缩。对此变量的更改会在后续的连接尝试中生效；这包括在发出一条START REPLICA语句之后，以及由正在运行的复制 I/O（接收方）线程进行的重新连接。

由系统变量激活的二进制日志事务压缩（自 MySQL 8.0.20 起可用） binlog_transaction_compression 也可用于节省带宽。如果将二进制日志事务压缩与协议压缩结合使用，则协议压缩对数据进行操作的机会较少，但仍可以压缩标头以及那些未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参阅 第 5.4.4.5 节，“二进制日志事务压缩”。

从 MySQL 8.0.18 开始，如果 slave_compressed_protocol 启用，它优先于任何 SOURCE_COMPRESSION_ALGORITHMS| 为|MASTER_COMPRESSION_ALGORITHMS指定的选项 陈述。在这种情况下，如果源和副本都支持该算法，则与源的连接将使用压缩。如果 禁用， | 的值 适用。有关更多信息，请参阅 第 4.2.8 节，“连接压缩控制”。 CHANGE REPLICATION SOURCE TOCHANGE MASTER TOzlibslave_compressed_protocolSOURCE_COMPRESSION_ALGORITHMSMASTER_COMPRESSION_ALGORITHMS

从 MySQL 8.0.18 开始，不推荐使用此系统变量。你应该期望它会在未来版本的 MySQL 中被删除。请参阅 配置传统连接压缩。

slave_exec_mode

从 MySQL 8.0.26 开始， 已弃用，应改用slave_exec_mode别名 。replica_exec_mode在 MySQL 8.0.26 之前的版本中，使用 slave_exec_mode.

slave_exec_mode控制复制线程如何解决复制期间的冲突和错误。IDEMPOTENT模式导致抑制重复键和未找到键的错误； STRICT意味着不会发生这种抑制。

IDEMPOTENTmode 旨在用于 NDB Cluster Replication 的多源复制、循环复制和其他一些特殊复制场景。（有关更多信息，请参阅 第 23.7.10 节，“NDB Cluster 复制：双向和循环复制”和 第 23.7.11 节，“NDB Cluster 复制冲突解决”。）NDB Cluster 忽略为明确设置的任何值 slave_exec_mode，并始终将其视为作为IDEMPOTENT。

在 MySQL Server 8.0 中，STRICT mode 是默认值。

设置此变量对所有复制通道（包括正在运行的通道）立即生效。

对于除 之外的存储引擎 NDB， IDEMPOTENT仅当您绝对确定可以安全地忽略重复键错误和未找到键错误时，才应使用模式。它旨在用于采用多源复制或循环复制的 NDB Cluster 的故障转移场景，不建议在其他情况下使用。

slave_load_tmpdir

从 MySQL 8.0.26 开始， 已弃用，应改用slave_load_tmpdir别名 。replica_load_tmpdir在 MySQL 8.0.26 之前的版本中，使用 slave_load_tmpdir.

slave_load_tmpdir指定副本创建临时文件的目录名称。设置此变量会立即对所有复制通道生效，包括正在运行的通道。默认情况下，变量值等于tmpdir系统变量的值，或者在未指定该系统变量时应用的默认值。

复制 SQL 线程在复制一条 LOAD DATA语句时，会从中继日志中提取要加载的文件到临时文件中，然后将这些文件加载​​到表中。如果源上加载的文件很大，则副本上的临时文件也很大。因此，建议使用此选项告诉副本将临时文件放在某个具有大量可用空间的文件系统中的目录中。在那种情况下，中继日志也很大，因此您可能还需要设置 relay_log系统变量以将中继日志放置在该文件系统中。

此选项指定的目录应位于基于磁盘的文件系统（而不是基于内存的文件系统）中，以便用于复制 LOAD DATA语句的临时文件可以在机器重新启动后继续存在。该目录也不应该是在系统启动过程中被操作系统清除的目录。但是，如果临时文件已被删除，复制现在可以在重新启动后继续。

slave_max_allowed_packet

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_max_allowed_packet别名 。replica_max_allowed_packet在 MySQL 8.0.26 之前的版本中，使用 slave_max_allowed_packet.

slave_max_allowed_packet 设置复制 SQL（应用程序）和 I/O（接收方）线程可以处理的最大数据包大小（以字节为单位）。设置此变量会立即对所有复制通道生效，包括正在运行的通道。添加事件标头后，源可能会写入比其 max_allowed_packet设置更长的二进制日志事件。的设置 slave_max_allowed_packet 必须大于 max_allowed_packet源上的设置，以便使用基于行的复制的大型更新不会导致复制失败。

这个全局变量的值始终是 1024 的正整数倍；如果您将其设置为某个不是的值，则该值将向下舍入为下一个最高的 1024 倍数，因为它已被存储或使用；设置 slave_max_allowed_packet为 0 会导致使用 1024。（在所有此类情况下都会发出截断警告。）默认值和最大值为 1073741824 (1 GB)；最小值为 1024。

slave_net_timeout

从 MySQL 8.0.26 开始， 已弃用，应改用slave_net_timeout别名 。replica_net_timeout在 MySQL 8.0.26 之前的版本中，使用 slave_net_timeout.

slave_net_timeout指定在副本认为连接断开、中止读取并尝试重新连接之前等待更多数据或来自源的心跳信号的秒数。设置此变量不会立即生效。变量的状态适用于所有后续 START REPLICA命令。

默认值为 60 秒（一分钟）。第一次重试在超时后立即发生。重试之间的间隔由 SOURCE_CONNECT_RETRY| 控制。 |MASTER_CONNECT_RETRY的选项 声明，并且重新连接尝试的次数受 | 限制 选项。 CHANGE REPLICATION SOURCE TOCHANGE MASTER TOSOURCE_RETRY_COUNTMASTER_RETRY_COUNT

心跳间隔，如果连接仍然良好，它会停止在没有数据的情况下发生的连接超时，由 SOURCE_HEARTBEAT_PERIOD| 控制。 |MASTER_HEARTBEAT_PERIOD的选项 陈述。心跳间隔默认为 值的一半 ，它记录在副本的连接元数据存储库中，并显示在 Performance Schema 表中。请注意，更改值或默认设置 CHANGE REPLICATION SOURCE TOCHANGE MASTER TOslave_net_timeoutreplication_connection_configurationslave_net_timeout不会自动更改心跳间隔，无论是已明确设置还是使用先前计算的默认值。如果更改了连接超时，您还必须发出CHANGE REPLICATION SOURCE TO| CHANGE MASTER TO将心跳间隔调整为适当的值，使其发生在连接超时之前。

slave_parallel_type

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_parallel_type别名 。replica_parallel_type在 MySQL 8.0.26 之前的版本中，使用 slave_parallel_type.

对于多线程副本（ replica_parallel_workers或 slave_parallel_workers设置为大于 0 的值的副本）， slave_parallel_type 指定用于决定允许哪些事务在副本上并行执行的策略。该变量对未启用多线程的副本没有影响。可能的值是：

当 replica_preserve_commit_order=ON or slave_preserve_commit_order=ON 被设置时，你只能使用LOGICAL_CLOCK. 在 MySQL 8.0.27 之前，DATABASE是默认的。从MySQL 8.0.27开始，副本服务器默认开启多线程（replica_parallel_workers=4 by default），LOGICAL_CLOCK也是默认的，设置 replica_preserve_commit_order=ON 也是默认的。

当您的复制拓扑使用多个级别的副本时，LOGICAL_CLOCK对于副本远离源的每个级别，可能会实现较少的并行化。binlog_transaction_dependency_tracking 您可以通过在源上使用来指定在可能的情况下使用写入集而不是时间戳来 减少这种影响 。

binlog_transaction_compression 当使用系统变量 启用二进制日志事务压缩时 ，如果replica_parallel_type或 slave_parallel_type设置为DATABASE，则在调度事务之前映射所有受事务影响的数据库。DATABASE与为每个事件映射和调度的未压缩事务相比，将 二进制日志事务压缩与策略一起使用可以降低并行度。

slave_parallel_workers

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_parallel_workers别名 。replica_parallel_workers在 MySQL 8.0.26 之前的版本中，使用 slave_parallel_workers.

slave_parallel_workers 在副本上启用多线程并设置用于并行执行复制事务的应用程序线程数。当该值为大于 0 的数字时，副本是一个多线程副本，具有指定数量的应用程序线程，加上一个协调器线程来管理它们。如果您使用多个复制通道，则每个通道都有此数量的线程。

在 MySQL 8.0.27 之前，这个系统变量默认为 0，所以副本默认不是多线程的。从 MySQL 8.0.27 开始，默认值为 4，因此副本默认为多线程。

在副本上启用多线程时支持重试事务。replica_preserve_commit_order=ON 设置或 设置时 slave_preserve_commit_order=ON ，副本上的事务将按照它们在副本的中继日志中出现的相同顺序在副本上外部化。事务在应用程序线程之间分布的方式由 replica_parallel_type（从 MySQL 8.0.26 开始）或 slave_parallel_type（在 MySQL 8.0.26 之前）配置。从 MySQL 8.0.27 开始，这些系统变量也有适合多线程的默认值。

要禁用并行执行，请设置 replica_parallel_workers为 0，这会为副本提供单个应用程序线程而没有协调程序线程。使用此设置， replica_parallel_typeor slave_parallel_type和 replica_preserve_commit_order or slave_preserve_commit_order 系统变量将不起作用并被忽略。CHANGE REPLICATION SOURCE TO 从 MySQL 8.0.27 开始，如果在副本上启用该选项时禁用并行执行 GTID_ONLY，则副本实际上使用一个并行工作程序来利用重试事务而不访问文件位置的方法。对于一个并行工作者， replica_preserve_commit_order (slave_preserve_commit_order) 系统变量也无效。

设置 replica_parallel_workers 不会立即生效。变量的状态适用于所有后续 START REPLICA语句。

NDB Cluster 当前不支持多线程副本。有关如何 处理此变量的设置的 更多信息，请参阅 第 23.7.3 节，“NDB Cluster 复制中的已知问题” 。NDB

slave_pending_jobs_size_max

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_pending_jobs_size_max 别名 。replica_pending_jobs_size_max在 MySQL 8.0.26 之前的版本中，使用 slave_pending_jobs_size_max.

对于多线程副本，此变量设置可用于持有尚未应用的事件的应用程序队列的最大内存量（以字节为单位）。设置此变量对未启用多线程的副本没有影响。设置此变量不会立即生效。变量的状态适用于所有后续 START REPLICA命令。

此变量的最小可能值为 1024 字节；默认值为 128MB。最大可能值为 18446744073709551615（16 exbibytes）。在存储之前，不是 1024 字节的精确倍数的值将向下舍入为下一个较低的 1024 字节倍数。

此变量的值是一个软限制，可以设置为与正常工作负载相匹配。如果异常大的事件超过此大小，事务将被暂停，直到所有工作线程的队列都为空，然后再进行处理。所有后续交易都将暂停，直到大笔交易完成。

slave_preserve_commit_order

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_preserve_commit_order 别名 。replica_preserve_commit_order在 MySQL 8.0.26 之前的版本中，使用 slave_preserve_commit_order.

对于多线程副本（ replica_parallel_workers或 slave_parallel_workers设置为大于 0 的值的副本），设置 slave_preserve_commit_order=1 确保事务在副本上执行和提交的顺序与它们在副本的中继日志中出现的顺序相同。这可以防止从副本的中继日志执行的事务序列中出现间隙，并在副本上保留与源上相同的事务历史记录（具有下面列出的限制）。此变量对未启用多线程的副本没有影响。

在 MySQL 8.0.27 之前，该系统变量默认为 OFF，这意味着事务可能会乱序提交。从MySQL 8.0.27开始，副本服务器默认开启多线程（replica_parallel_workers=4 by default）， slave_preserve_commit_order=ON 也是默认的，设置 slave_parallel_type=LOGICAL_CLOCK 也是默认的。同样从 MySQL 8.0.27 开始， slave_preserve_commit_order 如果设置为 1，则忽略 slave_parallel_workers设置，因为在这种情况下，无论如何都会保留事务的顺序。

直到并包括 MySQL 8.0.18，设置 slave_preserve_commit_order=ON 要求在副本上启用二进制日志记录 ( log_bin) 和副本更新日志记录 ( log_slave_updates)，这是 MySQL 8.0 的默认设置。从 MySQL 8.0.19 开始，副本上不需要二进制日志记录和副本更新日志记录来设置 slave_preserve_commit_order=ON，并且可以根据需要禁用。在所有版本中，设置都 slave_preserve_commit_order=ON 要求 slave_parallel_type设置为LOGICAL_CLOCK，这 不是MySQL 8.0.27 之前的默认设置。slave_preserve_commit_order 在更改和的值之前 slave_parallel_type，必须停止复制 SQL 线程（对于所有复制通道，如果您使用多个复制通道）。

设置时 slave_preserve_commit_order=OFF ，这是默认设置，多线程副本并行应用的事务可能会乱序提交。因此，检查最近执行的事务并不能保证来自源的所有先前事务都已在副本上执行。从副本的中继日志执行的事务序列中可能存在间隙。这对使用多线程副本时的日志记录和恢复有影响。有关更多信息，请参阅 第 17.5.1.34 节，“复制和事务不一致” 。

设置时 slave_preserve_commit_order=ON ，正在执行的工作线程会等到所有先前的事务都已提交后再提交。当给定的线程正在等待其他工作线程提交它们的事务时，它将其状态报告为Waiting for preceding transaction to commit。使用此模式，多线程副本永远不会进入源未处于的状态。这支持使用复制进行读取扩展。请参阅 第 17.4.5 节，“使用复制进行横向扩展”。

slave_rows_search_algorithms

在为基于行的日志记录和复制准备成批的行时，此系统变量控制如何在行中搜索匹配项，特别是是否使用散列扫描。现在不推荐使用此系统变量。默认设置INDEX_SCAN,HASH_SCAN是性能最佳的，并且在所有情况下都能正常工作。请参阅 第 17.5.1.27 节，“复制和行搜索”。

slave_skip_errors

从 MySQL 8.0.26 开始， 已弃用，应改用slave_skip_errors别名 。replica_skip_errors在 MySQL 8.0.26 之前的版本中，使用 slave_skip_errors.

通常，当副本发生错误时，复制会停止，这使您有机会手动解决数据中的不一致问题。当语句返回变量值中列出的任何错误时，此变量会导致复制 SQL 线程继续复制。

replica_skip_errors

从 MySQL 8.0.26 开始，使用 replica_skip_errors代替slave_skip_errors，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 slave_skip_errors.

通常，当副本发生错误时，复制会停止，这使您有机会手动解决数据中的不一致问题。当语句返回变量值中列出的任何错误时，此变量会导致复制 SQL 线程继续复制。

slave_sql_verify_checksum

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_sql_verify_checksum 别名 。replica_sql_verify_checksum在 MySQL 8.0.26 之前的版本中，使用 slave_sql_verify_checksum.

slave_sql_verify_checksum 使复制 SQL 线程使用从中继日志读取的校验和来验证数据。如果不匹配，副本会因错误而停止。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

slave_transaction_retries

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_transaction_retries 别名 。replica_transaction_retries在 MySQL 8.0.26 之前的版本中，使用 slave_transaction_retries.

slave_transaction_retries 设置单线程或多线程副本上复制 SQL 线程在停止前自动重试失败事务的最大次数。设置此变量会立即对所有复制通道生效，包括正在运行的通道。默认值为 10。将变量设置为 0 将禁用事务的自动重试。

InnoDB如果复制 SQL 线程由于死锁或因为事务的执行时间超过 InnoDBs innodb_lock_wait_timeout或 NDBs TransactionDeadlockDetectionTimeout 或 而无法执行事务，它会 在因错误而停止之前TransactionInactiveTimeout自动重试 times。slave_transaction_retries不会重试具有非临时错误的事务。

Performance Schema 表 在列中replication_applier_status 显示了每个复制通道上发生的重试次数 COUNT_TRANSACTIONS_RETRIES。Performance Schema 表 replication_applier_status_by_worker 显示了单线程或多线程副本上各个应用程序线程重试事务的详细信息，并标识了导致最后一个事务和当前正在进行的事务被重试的错误。

slave_type_conversions

从 MySQL 8.0.26 开始， 已弃用， 应改用slave_type_conversions别名 。replica_type_conversions在 MySQL 8.0.26 之前的版本中，使用 slave_type_conversions.

slave_type_conversions 使用基于行的复制时，控制对副本有效的类型转换模式。它的值是一个逗号分隔的集合，由列表中的零个或多个元素组成： ALL_LOSSY, ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED。将此变量设置为空字符串以禁止源和副本之间的类型转换。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

有关适用于基于行的复制中的属性提升和降级的类型转换模式的其他信息，请参阅 基于行的复制：属性提升和降级。

sql_replica_skip_counter

从 MySQL 8.0.26 开始，使用 sql_replica_skip_counter代替 sql_slave_skip_counter，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 sql_slave_skip_counter.

sql_replica_skip_counter 指定副本应跳过的来自源的事件数。设置选项不会立即生效。该变量适用于下 START REPLICA一条语句；下 START REPLICA一条语句也将值改回 0。当此变量设置为非零值并且配置了多个复制通道时，该 START REPLICA语句只能与该 子句一起使用。 FOR CHANNEL channel

此选项与基于 GTID 的复制不兼容，并且在设置时不得设置为非零值 gtid_mode=ON。如果在使用 GTID 时需要跳过事务，请改用 gtid_executed源代码。如果您使用语句 的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项在复制通道上启用了 GTID 分配 ，则可用。请参阅 第 17.1.7.3 节，“跳过事务”。 CHANGE REPLICATION SOURCE TOsql_replica_skip_counter

sql_slave_skip_counter

从 MySQL 8.0.26 开始， 已弃用， 应改用sql_slave_skip_counter别名 。sql_replica_skip_counter在 MySQL 8.0.26 之前的版本中，使用 sql_slave_skip_counter.

sql_slave_skip_counter 指定副本应跳过的来自源的事件数。设置选项不会立即生效。该变量适用于下 START REPLICA一条语句；下 START REPLICA一条语句也将值改回 0。当此变量设置为非零值并且配置了多个复制通道时，该 START REPLICA语句只能与该 子句一起使用。 FOR CHANNEL channel

此选项与基于 GTID 的复制不兼容，并且在设置时不得设置为非零值 gtid_mode=ON。如果在使用 GTID 时需要跳过事务，请改用 gtid_executed源代码。如果您使用语句 的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项在复制通道上启用了 GTID 分配 ，则可用。请参阅 第 17.1.7.3 节，“跳过事务”。 CHANGE REPLICATION SOURCE TOsql_slave_skip_counter

sync_master_info

从 MySQL 8.0.26 开始， 已弃用，应改用sync_master_info别名 。sync_source_info在 MySQL 8.0.26 之前的版本中，使用 sync_master_info.

sync_master_info指定副本更新连接元数据存储库之后的事件数。当连接元数据存储库存储为 InnoDB表时（这是 MySQL 8.0 的默认设置），它会在发生此事件数后更新。如果连接元数据存储库存储为一个文件，这在 MySQL 8.0 中已弃用，则副本会在发生此事件数后将其master.info文件同步到磁盘（使用fdatasync()）。默认值为 10000，零值意味着存储库永远不会更新。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

sync_relay_log

如果此变量的值大于 0，则 fdatasync()在每个 sync_relay_log事件写入中继日志后，MySQL 服务器将其中继日志同步到磁盘（使用）。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

设置sync_relay_log为 0 会导致不对磁盘进行同步；在这种情况下，服务器依靠操作系统不时刷新中继日志的内容，就像任何其他文件一样。

值 1 是最安全的选择，因为在意外停止的情况下，您最多会从中继日志中丢失一个事件。然而，它也是最慢的选择（除非磁盘有电池备份缓存，这使得同步非常快）。有关对意外停止最具弹性的副本设置组合的信息，请参阅 第 17.4.2 节，“处理副本的意外停止”。

sync_relay_log_info

副本更新应用程序元数据存储库之后的事务数。当 applier 元数据存储库存储为 InnoDB表时，这是 MySQL 8.0 的默认设置，它会在每个事务后更新，并且忽略此系统变量。如果 applier 元数据存储库存储为文件，这在 MySQL 8.0 中已弃用，则副本 在该事务数后将其relay-log.info文件同步到磁盘（使用 ）。fdatasync()默认值为 sync_relay_log_info为 10000，零值表示文件内容仅由操作系统刷新。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

sync_source_info

从 MySQL 8.0.26 开始，使用 sync_source_info代替sync_master_info，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 sync_source_info.

sync_source_info指定副本更新连接元数据存储库之后的事件数。当连接元数据存储库存储为 InnoDB表时（这是 MySQL 8.0 的默认设置），它会在发生此事件数后更新。如果连接元数据存储库存储为一个文件，这在 MySQL 8.0 中已弃用，则副本会在发生此事件数后将其master.info文件同步到磁盘（使用fdatasync()）。默认值为 10000，零值意味着存储库永远不会更新。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

terminology_use_previous

在 MySQL 8.0.26 中，对包含术语 “ master ”的检测名称进行了不兼容的更改，更改为 “ source ”，“ slave ”更改为“ replica ”，以及“ mts ” （表示“ multithreaded slave ”） )，改为“ mta ”（表示“多线程应用程序”). 使用这些工具名称的监视工具可能会受到影响。如果不兼容的更改对您有影响，请将 terminology_use_previous 系统变量设置为BEFORE_8_0_26以使 MySQL 服务器使用先前列表中指定的对象的旧版本名称。这使得依赖旧名称的监视工具能够继续工作，直到它们可以更新为使用新名称。

将 terminology_use_previous 具有会话范围的系统变量设置为支持单个函数，或将全局范围设置为所有新会话的默认值。使用全局范围时，慢速查询日志包含名称的旧版本。

受影响的仪器名称在以下列表中给出。terminology_use_previous 系统变量只影响这些项目。 它不影响 MySQL 8.0.26 中也引入的系统变量、状态变量和命令行选项的新别名，这些在设置时仍然可以使用。