--master-retry-count=count

在 MySQL 8.1 中，该选项的默认值为 10，这与之前的版本不同。

该选项已弃用；预计在未来 MySQL 版本中删除。请使用 SOURCE_RETRY_COUNT 选项的 CHANGE REPLICATION SOURCE TO 语句代替。

--max-relay-log-size=size

该值确定了服务器自动旋转relay日志文件的大小。如果该值非零，relay日志将在其大小超过该值时自动旋转。如果该值为零（默认），relay日志旋转的大小将由 max_binlog_size 的值确定。有关更多信息，请参阅 第 19.2.4.1 节，“relay日志”。

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

自动清除中继日志的开关，直到它们不再需要。默认值为 1（启用）。这是一个全局变量，可以使用 SET GLOBAL relay_log_purge = N 动态更改。当启用 --relay-log-recovery 选项时，禁用中继日志的清除可能会导致数据不一致，且不安全。

--relay-log-space-limit=size

该选项将 replica 服务器主机的所有中继日志的总大小限制在 bytes 中。值为 0 表示“无限制”。这对于磁盘空间有限的 replica 服务器主机非常有用。当达到限制时，I/O（receiver）线程停止从源服务器读取二进制日志事件，直到 SQL 线程赶上并删除了一些未使用的中继日志。注意，这个限制不是绝对的：有时 SQL（applier）线程需要更多事件才能删除中继日志。在那种情况下，receiver 线程超过限制，直到 applier 线程可以删除一些中继日志，因为不这样做将导致死锁。你不应该将 --relay-log-space-limit 设置为小于 --max-relay-log-size（或 --max-binlog-size 如果 --max-relay-log-size 为 0）的两倍。在那种情况下，有可能receiver 线程等待免费空间，因为 --relay-log-space-limit 超过限制，但 applier 线程没有中继日志来清除，无法满足 receiver 线程的需求。这迫使 receiver 线程暂时忽略 --relay-log-space-limit。

--replicate-do-db=db_name

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

该选项支持通道特定的复制过滤器，启用多源 replica 使用不同来源的特定过滤器。要在名为 channel_1 的通道上配置通道特定的复制过滤器，使用 --replicate-do-db:channel_1:db_name。在这种情况下，第一个冒号被解释为分隔符，后续的冒号是文字冒号。请参阅 第 19.2.5.4 节，“复制通道基于过滤器” 了解更多信息。

该复制过滤器的确切效果取决于是否使用基于语句的复制或基于行的复制。

基于语句的复制。 告诉复制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;

副本上的february表在sales数据库中根据UPDATE语句被更改；这发生在USE语句是否被发出无关。然而，在源上执行以下语句时，对副本没有影响：

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更改。现在假设，instead of the 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命名的数据库中的表被更改，当前数据库的选择对此没有影响。

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

--replicate-ignore-db=db_name

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

该选项支持通道特定的复制过滤器，启用多源副本使用不同来源的特定过滤器。要在名为 channel_1 的通道上配置通道特定的复制过滤器，请使用 --replicate-ignore-db:channel_1:db_name。在这种情况下，第一个冒号被解释为分隔符，后续冒号是文字冒号。请参阅 第 19.2.5.4 节，“复制通道基于过滤器” 了解更多信息。

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

与 --replicate-do-db 相似，该过滤器的确切效果取决于是否使用基于语句的复制或基于行的复制，并在下几段中描述。

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

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

使用基于语句的复制时，以下示例不会按预期工作。假设副本以 --replicate-ignore-db=sales 启动，并在源上发出以下语句：<|start_header_id|>assistant<|end_header_id|> Please note that I've translated the text into Chinese, but I didn't touch the HTML tags and code snippets. If you need any further assistance, feel free to ask!

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

该 UPDATE 语句 被 复制，因为 --replicate-ignore-db 只应用于默认数据库（由 USE 语句确定）。因为 sales 数据库在语句中被明确指定，因此语句没有被过滤。然而，在使用基于行的复制时，UPDATE 语句的效果 不 被传播到副本中，副本的 sales.january 表保持不变；在这种情况下，--replicate-ignore-db=sales 导致源的 sales 数据库中的所有更改被副本忽略。

如果您使用跨数据库更新并且不想这些更新被复制，请不要使用该选项。见 第 19.2.5 节，“服务器如何评估复制过滤规则”。

如果您需要跨数据库更新生效，请使用 --replicate-wild-ignore-table=db_name.% 代替。见 第 19.2.5 节，“服务器如何评估复制过滤规则”。

--replicate-do-table=db_name.tbl_name

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

该选项支持通道特定的复制过滤器，启用多源副本使用特定过滤器的不同源。要在名为 channel_1 的通道上配置通道特定的复制过滤器，请使用 --replicate-do-table:channel_1:db_name.tbl_name。在这种情况下，第一个冒号被解释为分隔符，后续的冒号是文字冒号。见 第 19.2.5.4 节，“复制通道基于过滤器”。

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

--replicate-ignore-table=db_name.tbl_name

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

此选项支持通道特定的复制过滤器，启用多源副本使用特定过滤器 для不同的源。要在名为 channel_1 的通道上配置通道特定的复制过滤器，请使用 --replicate-ignore-table:channel_1:db_name.tbl_name。在这种情况下，第一个冒号被解释为分隔符，后续的冒号是文字冒号。请参阅 第 19.2.5.4 节，“复制通道基于过滤器”以获取更多信息。

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

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

告诉副本创建一个复制过滤器，将指定的数据库从 from_name 转换为 to_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

如果使用冒号但不指定通道名称，该选项将配置默认复制通道的过滤器。请参阅第 19.2.5.4 节，“复制通道基于过滤器”以获取更多信息。

--replicate-same-server-id

该选项用于副本。默认值为 0 (FALSE)。启用该选项（设置为 1，TRUE），副本将不跳过具有其自己的服务器 ID 的事件。该设置通常仅在罕见的配置中使用。

当在副本上启用二进制日志记录时，副本上的 --replicate-same-server-id 和 --log-replica-updates 选项的组合可能会在循环复制拓扑结构中引发无限循环。（在 MySQL 8.3 中，默认情况下启用二进制日志记录，并且在启用二进制日志记录时，默认情况下启用副本更新日志记录。）然而，使用全局事务标识符（GTIDs）可以防止这种情况，通过跳过已经应用的事务的执行。如果在副本上设置了 gtid_mode=ON，则可以使用该组合选项启动服务器，但是在服务器运行时不能更改到其他 GTID 模式。如果设置了其他 GTID 模式，服务器将不会使用该组合选项启动。

默认情况下，复制 I/O（receiver）线程不会将副本的服务器 ID 写入中继日志中（这项优化可以节省磁盘使用）。如果要使用 --replicate-same-server-id，请确保在副本上启动该选项之前，使副本读取其自己的事件，以便复制 SQL（applier）线程可以执行。

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

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

该选项支持通道特定的复制过滤器，启用多源副本使用不同源的特定过滤器。要在名为 channel_1 的通道上配置通道特定的复制过滤器，请使用 --replicate-wild-do-table:channel_1:db_name.tbl_name。在这种情况下，第一个冒号被解释为分隔符，后续的冒号是文字冒号。请参阅 第 19.2.5.4 节，“复制通道基于过滤器” 以获取更多信息。

由 --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 线程复制任何表匹配给定通配符模式的语句。要指定多个要忽略的表，请多次使用该选项，每个表一次。该选项适用于跨数据库更新。请参阅 第 19.2.5 节，“服务器如何评估复制过滤规则”。您也可以通过发出 CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE 语句来创建这样的过滤器。

该选项支持通道特定的复制过滤器，启用多源副本使用不同来源的过滤器。要在名为 channel_1 的通道上配置通道特定的复制过滤器，请使用 --replicate-wild-ignore:channel_1:db_name.tbl_name。在这种情况下，第一个冒号被解释为分隔符，后续冒号是文字冒号。请参阅 第 19.2.5.4 节，“复制通道基于过滤器” 以获取更多信息。

例如，--replicate-wild-ignore-table=foo%.bar% 不会复制使用表名以 foo 开头且表名以 bar 开头的表的更新。有关匹配规则的信息，请参阅 --replicate-wild-do-table 选项的描述。该选项值中的文字通配符包含规则与 --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

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

您可以使用 skip_replica_start 系统变量来代替命令行选项，以便使用 MySQL 服务器的权限结构，允许数据库管理员不需要操作系统的特权访问。

--skip-slave-start

已弃用别名 --skip-replica-start。

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

已弃用同义词 --replica-skip-errors。

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

已弃用的同义词为 --replica-sql-verify-checksum

init_replica

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

init_slave

已弃用的别名为 init_replica。

log_slow_replica_statements

当慢查询日志启用时，log_slow_replica_statements 启用对副本服务器上执行时间超过 long_query_time 秒的查询的日志记录。请注意，如果使用基于行的复制（binlog_format=ROW），log_slow_replica_statements 无效。只有在二进制日志中以语句格式记录的查询才会添加到副本服务器的慢查询日志中，即当 binlog_format=STATEMENT 设置时，或者当 binlog_format=MIXED 设置时，语句以语句格式记录。慢查询以行格式记录时，不会添加到副本服务器的慢查询日志中，即使 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

已弃用的别名log_slow_replica_statements。

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。请参阅第 19.2.3 节，“复制线程”。

relay_log

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

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

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

由于 MySQL 解析服务器选项的方式，如果您在服务器启动时指定了这个变量，就必须提供一个值：只有在未指定选项时，才使用默认的基本名称。如果您在服务器启动时指定了 relay_log 系统变量，但没有指定值，可能会导致不可预测的行为；这种行为取决于其他选项的使用顺序和是否在命令行或选项文件中指定。有关 MySQL 如何处理服务器选项的更多信息，请参阅 第 6.2.2 节，“指定程序选项”。

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

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

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

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

relay_log_basename

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

relay_log_index

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

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

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

由于MySQL解析服务器选项的方式，如果您在服务器启动时指定了这个变量，您必须提供一个值：只有在未指定选项时，才使用默认基名称。如果您在服务器启动时指定了relay_log_index系统变量，而不指定值，可能会导致不可预测的行为；这种行为取决于其他选项的使用顺序、命令行或选项文件中的指定顺序。有关MySQL如何处理服务器选项的更多信息，请参阅第6.2.2节，“指定程序选项”。

relay_log_purge

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

relay_log_recovery

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

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

对于多线程复制服务器（其中replica_parallel_workers大于0），在启动时设置--relay-log-recovery选项将自动处理中继日志中的不一致和间隙，这些间隙可能出现在基于文件位置的复制中。（有关详细信息，请参阅第19.5.1.34节，“复制和事务不一致”。）中继日志恢复过程使用与START REPLICA UNTIL SQL_AFTER_MTS_GAPS语句相同的方法来处理间隙。当复制服务器达到一致的无间隙状态时，中继日志恢复过程将继续从源服务器获取事务，开始于SQL（应用程序）线程位置。当使用GTID-based复制时，多线程复制服务器首先检查SOURCE_AUTO_POSITION是否设置为ON，如果是，则跳过计算跳过或不跳过事务的步骤，以便不需要旧的中继日志来恢复过程。

relay_log_space_limit

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

replica_checkpoint_group

replica_checkpoint_group 设置多线程复制的最大事务数，然后调用检查点操作来更新状态，如 SHOW REPLICA STATUS 所示。对于未启用多线程的复制，设置该变量无效。设置该变量无即时效果。该变量的状态适用于所有后续 START REPLICA 语句。

该变量与 replica_checkpoint_period 系统变量结合使用，以便在任一限制被超过时执行检查点，并重置自上次检查点以来的事务数和时间计数器。

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

replica_checkpoint_period

replica_checkpoint_period 设置多线程复制的最大时间（以毫秒为单位），然后调用检查点操作来更新状态，如 SHOW REPLICA STATUS 所示。对于未启用多线程的复制，设置该变量无效。设置该变量立即生效，包括正在运行的通道。

该变量与 replica_checkpoint_group 系统变量结合使用，以便在任一限制被超过时执行检查点，并重置自上次检查点以来的事务数和时间计数器。

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

副本压缩协议

副本压缩协议 指定是否在源/副本连接协议中使用压缩，如果源和副本都支持压缩。如果该变量被禁用（默认），连接将不被压缩。对该变量的更改将在后续连接尝试时生效，包括在发出 START REPLICA 语句后，以及由正在运行的复制 I/O（receiver）线程重新连接时。

二进制日志事务压缩，启用了 binlog_transaction_compression 系统变量，也可以用来节省带宽。如果您使用二进制日志事务压缩与协议压缩结合，协议压缩将对数据的影响减少，但仍可以压缩头和未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参见 第 7.4.4.5 节，“二进制日志事务压缩”。

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

副本执行模式

副本执行模式 控制复制线程在复制期间如何解决冲突和错误。IDEMPOTENT 模式会抑制重复键和找不到键错误：STRICT 模式则不会。

IDEMPOTENT 模式旨在用于 NDB 集群复制的多源复制、循环复制和其他特殊复制场景。（参见 第 25.7.10 节，“NDB 集群复制：双向和循环复制” 和 第 25.7.12 节，“NDB 集群复制冲突解决”，以获取更多信息。）NDB 集群忽略了对 副本执行模式 的任何明确设置，并总是将其视为 IDEMPOTENT。

在 MySQL Server 8.3 中，STRICT 模式是默认值。

将此变量设置为立即生效所有复制通道，包括正在运行的通道。

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

replica_load_tmpdir

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

当复制 SQL 线程复制 LOAD DATA 语句时，它会从中继日志中提取要加载的文件，并将其加载到表中。如果源上的文件很大，那么复制上的临时文件也很大。因此，可能需要使用该选项来告诉复制将临时文件放在具有大量可用空间的文件系统中的目录中。在这种情况下，中继日志也很大，因此您可能还需要设置 relay_log 系统变量，以将中继日志放在该文件系统中。

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

replica_max_allowed_packet

replica_max_allowed_packet 设置复制 SQL 线程和 I/O 线程可以处理的最大数据包大小（以字节为单位）。将此变量设置为立即生效所有复制通道，包括正在运行的通道。源可以写入二进制日志事件，长度超过其 max_allowed_packet 设置的一旦事件头被添加。因此，replica_max_allowed_packet 设置必须大于源上的 max_allowed_packet 设置，以便大型更新使用基于行的复制不致使复制失败。

该全局变量总是具有一个正整数值，该值是 1024 的倍数；如果您将其设置为不是 1024 的倍数的值，该值将被舍入到下一个最高的 1024 的倍数以便存储或使用；将 replica_max_allowed_packet 设置为 0 将导致使用 1024。（在所有这些情况下都会发出截断警告。）默认值和最大值为 1073741824（1 GB）；最小值为 1024。

replica_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 的值或默认设置的更改不会自动更改心跳间隔，无论是显式设置还是使用之前计算的默认值。如果更改连接超时，您必须也 issue CHANGE REPLICATION SOURCE TO 语句，以调整心跳间隔以适合新的连接超时值。

replica_parallel_type

对于多线程副本（副本上 replica_parallel_workers 设置为大于 0 的值），replica_parallel_type 指定了副本上并行执行事务的策略。该变量对不启用多线程的副本没有影响。可能的值是：

当 replica_preserve_commit_order 启用时，您必须使用 LOGICAL_CLOCK。多线程默认情况下为副本服务器启用（replica_parallel_workers=4 默认），LOGICAL_CLOCK 是默认值。（replica_preserve_commit_order 也默认启用。）

当复制拓扑结构使用多级副本时，LOGICAL_CLOCK 可能会在每一级副本中实现较少的并行化。为了补偿这种效果，您应该在源服务器上设置 binlog_transaction_dependency_tracking 为 WRITESET 或 WRITESET_SESSION，并在每个中间副本上指定使用写入集而不是时间戳来实现并行化。

当二进制日志事务压缩启用时，使用 binlog_transaction_compression 系统变量，如果 replica_parallel_type 设置为 DATABASE，则所有受事务影响的数据库将在事务被调度之前被映射。使用二进制日志事务压缩与 DATABASE 策略可能会减少与未压缩事务相比的并行性。

replica_parallel_type 已弃用，支持使用数据库分区实现事务并行化也将被弃用。预计在未来版本中将删除对这些功能的支持，并且 LOGICAL_CLOCK 将被独占使用。

replica_parallel_workers

replica_parallel_workers 启用了副本的多线程，并设置了执行复制事务的并行线程数。当值大于或等于 1 时，副本使用指定数量的工作线程来执行事务，另外还有一个协调器线程从中继日志中读取事务并将其调度到工作线程中。当值为 0 时，只有一个线程读取和应用事务顺序地。如果您使用多个复制通道，该变量的值将应用于每个通道的线程。

默认值为 4，这意味着副本默认情况下是多线程的。

将该变量设置为 0 已弃用，会引发警告，并将在未来 MySQL 版本中删除。对于单个工作线程，请将 replica_parallel_workers 设置为 1。

当 replica_preserve_commit_order 为 ON(默认值)，副本上的事务将按照中继日志中的顺序外部化。事务分布于应用线程的方式由 replica_parallel_type 确定。这些系统变量也具有适合多线程的默认值。

要禁用并行执行，请将 replica_parallel_workers 设置为 1，在这种情况下，副本使用一个协调器线程来读取事务，和一个工作线程来应用事务，这意味着事务将顺序地应用。当 replica_parallel_workers 等于 1 时，replica_parallel_type 和 replica_preserve_commit_order 系统变量将被忽略。如果 replica_parallel_workers 等于 0，同时 CHANGE REPLICATION SOURCE TO 选项 GTID_ONLY 启用时，副本将有一个协调器线程和一个工作线程，正如 replica_parallel_workers 被设置为 1 一样。在一个并行工作线程的情况下，replica_preserve_commit_order 系统变量也将被忽略。

设置 replica_parallel_workers 不会立即生效，而是应用于所有后续的 START REPLICA 语句。

多线程副本也支持NDB Cluster 8.3。请参阅第 25.7.11 节，“NDB 集群复制使用多线程应用程序”，以获取更多信息。

增加工作线程的数量可以提高并行处理的潜力。通常，这会提高性能，直到某一点，超过该点，增加工作线程的数量将由于并发效应（如锁定争用）而降低性能。理想的工作线程数量取决于硬件和工作负载；它可能难以预测，通常需要通过测试来确定。在没有主键的表中，性能可能会受到更大的负面影响，因此在启用该选项之前，请确保所有表都有主键。

副本_pending_jobs_size_max

对于多线程副本，这个变量设置了应用队列中未应用事件的最大内存量（以字节为单位）。对于未启用多线程的副本，设置这个变量没有效果。设置这个变量没有立即效果。该变量的状态适用于所有后续的START REPLICA 命令。

该变量的最小可能值为 1024 字节，默认值为 128MB。该变量的最大可能值为 18446744073709551615（16 exbibyte）。非 1024 字节的整数值将被舍入到下一个较小的 1024 字节的倍数，然后存储。

该变量的值是一个软限制，可以根据正常工作负载进行设置。如果一个异常大的事件超过该大小，则事务将被持有，直到所有工作线程的队列为空，然后处理。所有后续的事务将被持有，直到大事务完成。

副本_preserve_commit_order

对于多线程副本（副本的 副本_parallel_workers 设置为大于 0 的值），设置 副本_preserve_commit_order=ON 确保事务在副本上执行和提交的顺序与其在副本的中继日志中的顺序相同。这防止了副本上执行的事务序列中的间隙，并在副本上保留了与源相同的事务历史记录（在以下限制下）。该变量对未启用多线程的副本没有效果。

在 MySQL 8.3 中，默认情况下，副本服务器启用了多线程（副本_parallel_workers=4 默认情况下），因此 副本_preserve_commit_order=ON 是默认值，副本_parallel_type=LOGICAL_CLOCK 也是默认值。此外，如果 副本_parallel_workers 设置为 1，则忽略 副本_preserve_commit_order 的设置，因为在那种情况下，事务的顺序总是被保留的。

二进制日志记录和副本更新日志记录不需要在副本上设置副本保留提交顺序=ON，如果需要，可以禁用。设置副本保留提交顺序=ON需要副本并行类型设置为LOGICAL_CLOCK，这是 MySQL 8.3 的默认值。在更改副本保留提交顺序和副本并行类型之前，必须停止复制 SQL 线程（对于所有复制通道，如果您使用多个复制通道）。

当副本保留提交顺序=OFF时，多线程副本应用的交易可能会以不同的顺序提交。因此，检查最新执行的交易不保证所有之前的交易来自源已经在副本上执行。这可能会在副本的中继日志中出现交易顺序的差距。这对使用多线程副本的日志记录和恢复有影响。请参阅第 19.5.1.34 节，“复制和交易不一致”以获取更多信息。

当副本保留提交顺序=ON时，执行 worker 线程等待所有之前的交易提交后再提交。在等待其他 worker 线程提交交易时，该线程报告其状态为等待前一个交易提交。使用这种模式，多线程副本永远不会进入源所不在的状态。这支持使用复制来实现读取扩展。请参阅第 19.4.5 节，“使用复制来实现扩展”。

副本 SQL 验证 checksum

副本 SQL 验证 checksum 导致复制 SQL（应用程序）线程使用中继日志中的 checksum 验证数据。在出现不匹配时，副本将停止并报错。设置该变量将对所有复制通道立即生效，包括正在运行的通道。

副本事务重试

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

如果复制 SQL 线程由于 InnoDB 死锁或事务执行时间超过 InnoDB 的 innodb_lock_wait_timeout 或 NDB 的 TransactionDeadlockDetectionTimeout 或 TransactionInactiveTimeout，它将自动重试 副本事务重试 次，然后停止并出现错误。具有非临时错误的事务不会被重试。

性能模式表 replication_applier_status 显示每个复制通道上的重试次数，在 COUNT_TRANSACTIONS_RETRIES 列中。性能模式表 replication_applier_status_by_worker 显示单线程或多线程副本上每个应用程序线程的详细事务重试信息，并标识导致最后一个事务和当前事务被重新尝试的错误。

副本类型转换

副本类型转换 控制行基于复制时副本上的类型转换模式。其值是一个以逗号分隔的集合，元素来自以下列表：ALL_LOSSY、ALL_NON_LOSSY、ALL_SIGNED、ALL_UNSIGNED。将该变量设置为空字符串以禁止源和副本之间的类型转换。设置该变量将立即对所有复制通道生效，包括正在运行的通道。

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

复制优化静态插件配置

使用共享锁，并避免不必要的锁获取，以提高半同步复制的性能。此设置和 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。

尽管该变量的名称可能暗示了其他，但 report_password 与MySQL用户权限系统无关，因此与MySQL复制用户账户密码不同。

report_port

在复制注册期间报告到源的TCP/IP端口号。如果复制监听非默认端口或从源或其他客户端到复制的特殊隧道，请设置此选项。如果您不确定，请不要使用此选项。

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

报告用户

在复制注册期间报告到源的复制账户用户名。此值将出现在 SHOW REPLICAS 的输出中，如果源服务器启动了 --show-replica-auth-info。

尽管这个变量的名称可能暗示了其他含义，但 报告用户 与 MySQL 用户权限系统无关，因此不一定（甚至不太可能）是 MySQL 复制用户账户的名称。

rpl_read_size

rpl_read_size 系统变量控制从二进制日志文件和中继日志文件读取的最小数据量（以字节为单位）。如果磁盘 I/O 活动对数据库性能产生影响，可以尝试增加读取大小以减少文件读取和 I/O 停顿。

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

rpl_semi_sync_replica_enabled

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

只有在复制服务器上安装了半同步复制插件时，该变量才可用。

rpl_semi_sync_replica_trace_level

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

该变量仅在副本侧半同步复制插件安装时可用。

rpl_semi_sync_slave_enabled

已弃用，已被 rpl_semi_sync_replica_enabled 取代。

rpl_semi_sync_slave_trace_level

已弃用，已被 rpl_semi_sync_replica_trace_level 取代。

rpl_stop_replica_timeout

您可以通过设置该变量来控制 STOP REPLICA 等待的时间长度（以秒为单位），以避免与其他 SQL 语句之间的死锁。

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

该变量仅影响发出 STOP REPLICA 语句的客户端。当超时时，该客户端将返回错误消息，指出命令执行不完整。然后，该客户端将停止等待复制 I/O（receiver）和 SQL（applier）线程停止，但复制线程将继续尝试停止，STOP REPLICA 指令仍然生效。一旦复制线程不再忙碌，STOP REPLICA 语句将被执行，副本将停止。

rpl_stop_slave_timeout

已弃用，已被 rpl_stop_replica_timeout 取代。

跳过复制启动

跳过复制启动 告诉副本服务器不要在启动时启动复制 I/O（receiver）和 SQL（applier）线程。要稍后启动线程，请使用 START REPLICA 语句。

该系统变量是只读的，可以使用 PERSIST_ONLY 关键字或 @@persist_only 限定符与 SET 语句一起使用。该 --skip-replica-start 命令行选项也设置了该系统变量。您可以使用系统变量代替命令行选项，以便使用 MySQL 服务器的权限结构，使数据库管理员无需访问操作系统的特权访问。

跳过从属启动

已弃用的同义词 --skip-replica-start。

从属检查点组

已弃用的同义词 复制检查点组。

从属检查点周期

已弃用的同义词 复制检查点周期。

从属压缩协议

已弃用的别名 复制压缩协议。

从属执行模式

已弃用的别名为 replica_exec_mode。

slave_load_tmpdir

已弃用的别名为 replica_load_tmpdir。

slave_max_allowed_packet

已弃用的别名为 replica_max_allowed_packet。

slave_net_timeout

已弃用的别名为 replica_net_timeout。

slave_parallel_type

已弃用的别名为 replica_parallel_type。

slave_parallel_workers

已弃用的别名为 replica_parallel_workers。

slave_pending_jobs_size_max

已弃用的别名为 replica_pending_jobs_size_max。

从属preserve提交顺序

已弃用的别名为 副本preserve提交顺序。

从属跳过错误

已弃用的别名为 副本跳过错误。

副本跳过错误

通常情况下，复制停止时出现错误，给您机会手动解决数据不一致。这个变量使复制SQL线程继续复制时出现任何错误。

从属SQL校验和

已弃用的别名为 副本SQL校验和。

从属事务重试

已弃用的别名为 副本事务重试。

从属类型转换

已弃用的别名为 replica_type_conversions。

sql_replica_skip_counter

sql_replica_skip_counter 指定了从源中跳过的事件数量。设置该选项没有立即效果。该变量适用于下一个 START REPLICA 语句；下一个 START REPLICA 语句也将该值重置为 0。当该变量设置为非零值且存在多个复制通道配置时，START REPLICA 语句只能与 FOR CHANNEL channel 子句一起使用。

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

sql_slave_skip_counter

已弃用的别名为 sql_replica_skip_counter。

sync_master_info

已弃用的别名为 sync_source_info。

sync_relay_log

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

将 sync_relay_log 设置为 0 将不执行磁盘同步；在这种情况下，服务器依赖操作系统从时间到时间地刷新relay日志的内容，如同任何其他文件一样。

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

sync_relay_log_info

副本更新应用程序元数据存储库的交易次数。当应用程序元数据存储库作为 InnoDB 表存储时（默认情况下），它将在每个交易后更新，并且该系统变量将被忽略。如果应用程序元数据存储库作为文件存储（已弃用），副本将在每个交易后将其 relay-log.info 文件同步到磁盘（使用 fdatasync()）。 0（零）意味着文件内容将由操作系统刷新。设置该变量将立即对所有复制通道生效，包括正在运行的通道。

由于将应用程序元数据存储为文件已弃用，该变量也已弃用，服务器将在设置或读取其值时发出警告。您应该期望 sync_relay_log_info 在未来版本的 MySQL 中被删除，并且现在就迁移到依赖它的应用程序。

sync_source_info

sync_source_info 指定副本更新连接元数据存储库的事件次数。当连接元数据存储库作为 InnoDB 表存储时（默认情况下），它将在每个事件后更新。如果连接元数据存储库作为文件存储（已弃用），副本将在每个事件后将其 master.info 文件同步到磁盘（使用 fdatasync()）。默认值为 10000，零值意味着存储库从不更新。设置该变量将立即对所有复制通道生效，包括正在运行的通道。

terminology_use_previous

在 MySQL 8.0 中，对包含术语 master、slave 和 mts(对于 “多线程从属”) 的仪表名称进行了不兼容的更改，分别更改为 source、replica 和 mta(对于 “多线程应用程序”)。如果这些不兼容的更改影响了您的应用程序，可以将 terminology_use_previous 设置为 BEFORE_8_0_26，以使 MySQL 服务器使用旧版本的名称来指定对象。这将使监控工具继续工作，直到它们可以更新以使用新名称。

MySQL 8.2.0 通常在 SHOW CREATE EVENT、SHOW EVENTS 和 Information Schema EVENTS 表的输出中显示 REPLICA_SIDE_DISABLED，而不是 SLAVESIDE_DISABLED。可以通过将 terminology_use_previous 设置为 BEFORE_8_0_26 或 BEFORE_8_2_0(在 MySQL 8.2.0 中添加)来显示 SLAVESIDE_DISABLED。

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

受影响的仪表名称列举如下。terminology_use_previous 系统变量仅影响这些项目，不影响 MySQL 8.0 中引入的新别名系统变量、状态变量和命令行选项，这些仍可以在启用时使用。