--master-retry-count=count

此选项已弃用；预计它将在将来的 MySQL 版本中删除。请改用 CHANGE REPLICATION SOURCE TO 语句的 SOURCE_RETRY_COUNT 选项。

--max-relay-log-size=size

服务器自动旋转中继日志文件的尺寸。如果此值非零，则当中继日志的大小超过此值时，将自动旋转中继日志。如果此值为零（默认值），则中继日志旋转发生的尺寸由 max_binlog_size 的值决定。有关更多信息，请参见 第 19.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 的通道上配置通道特定的复制过滤器，请使用 --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;

副本上的 sales 数据库中的 february 表将根据 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 的另一个重要区别在于，针对引用多个数据库的语句，会出现这种区别。假设副本使用 --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 命名的数据库中的表，默认数据库的选择对此行为没有影响。

如果您需要跨数据库更新生效，请改用 --replicate-wild-do-table=db_name.%。请参见 第 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 启动，您在源上发出以下语句

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.4 中，二进制日志记录默认启用，并且当启用二进制日志记录时，副本更新日志记录为默认值。）但是，使用全局事务标识符 (GTID) 可以通过跳过已应用的事务的执行来防止这种情况。如果在副本上设置了gtid_mode=ON，则可以使用此选项组合启动服务器，但不能在服务器运行时更改为任何其他 GTID 模式。如果设置了任何其他 GTID 模式，则服务器不会使用此选项组合启动。

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

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

通过告诉复制 SQL（应用器）线程将复制限制在任何更新的表都与指定的数据库和表名模式匹配的语句来创建复制过滤器。模式可以包含% 和_ 通配符，它们的含义与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（接收器）和 SQL（应用器）线程。要稍后启动线程，请使用 START REPLICA 语句。

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

--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 并且语句以语句格式记录时。当设置了 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

已弃用的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也未指定，则对于默认复制通道，默认名称为host_name-relay-bin.index，使用主机名称。对于非默认复制通道，默认名称为host_name-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禁用时，服务器将在启动时清理中继日志，执行以下操作

此全局变量在运行时是只读的。其值可以使用副本服务器启动时的--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 的复制时，多线程副本首先会检查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 天）。

replica_compressed_protocol

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

由 binlog_transaction_compression 系统变量启用的二进制日志事务压缩也可以用于节省带宽。如果将二进制日志事务压缩与协议压缩结合使用，则协议压缩对数据的处理机会减少，但仍然可以压缩标题以及那些未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参见 第 7.4.4.5 节“二进制日志事务压缩”。

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

replica_exec_mode

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

IDEMPOTENT 模式旨在用于多源复制、循环复制以及 NDB Cluster 复制中的一些其他特殊复制场景。（有关更多信息，请参见 第 25.7.10 节“NDB Cluster 复制：双向和循环复制” 和 第 25.7.12 节“NDB Cluster 复制冲突解决”。）NDB Cluster 忽略为 replica_exec_mode 显式设置的任何值，并始终将其视为 IDEMPOTENT。

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

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

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

replica_load_tmpdir

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

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

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

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 秒（一分钟）。第一次重试在超时后立即发生。重试之间的间隔由 CHANGE REPLICATION SOURCE TO 语句的 SOURCE_CONNECT_RETRY 选项控制，并且重新连接尝试的次数受 SOURCE_RETRY_COUNT 选项限制。

心跳间隔会阻止连接超时在没有数据的情况下发生（如果连接仍然良好），由 CHANGE REPLICATION SOURCE TO 语句的 SOURCE_HEARTBEAT_PERIOD 选项控制。心跳间隔默认为 replica_net_timeout 值的一半，它记录在副本的连接元数据存储库中，并在 replication_connection_configuration Performance Schema 表中显示。请注意，对 replica_net_timeout 的值或默认设置的更改不会自动更改心跳间隔，无论该间隔是显式设置的还是使用先前计算的默认值。如果连接超时已更改，您还必须发出 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_compression 系统变量启用二进制日志事务压缩时，如果 replica_parallel_type 设置为 DATABASE，则在调度事务之前映射受事务影响的所有数据库。与未压缩的事务相比，使用 DATABASE 策略的二进制日志事务压缩可能会降低并行度，而未压缩的事务会为每个事件映射和调度。

replica_parallel_type 已弃用，使用数据库分区进行事务并行化的支持也已弃用。预计将在将来的版本中删除对这些的支持，并在此之后专门使用 LOGICAL_CLOCK。

replica_parallel_workers

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

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

将此变量设置为 0 已被弃用，会发出警告，并且可能会在将来的 MySQL 版本中被删除。对于单个 worker，请将 replica_parallel_workers 设置为 1。

当 replica_preserve_commit_order 为 ON（默认值）时，副本上的事务在副本上外部化的顺序与其在副本的中继日志中出现的顺序相同。事务在应用线程之间分配的方式由 replica_parallel_type 决定。这些系统变量也具有适合多线程的默认值。

要禁用并行执行，请将 replica_parallel_workers 设置为 1，在这种情况下，副本将使用一个协调器线程来读取事务，以及一个 worker 线程来应用事务，这意味着事务将按顺序应用。当 replica_parallel_workers 等于 1 时，replica_parallel_type 和 replica_preserve_commit_order 系统变量没有效果，并且会被忽略。如果 replica_parallel_workers 等于 0，而 CHANGE REPLICATION SOURCE TO 选项 GTID_ONLY 已启用，则副本将拥有一个协调器线程和一个 worker 线程，就像 replica_parallel_workers 设置为 1 一样。对于一个并行 worker，replica_preserve_commit_order 系统变量也没有效果。

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

NDB 集群 8.4 也支持多线程副本。有关更多信息，请参阅 第 25.7.11 节“使用多线程应用程序的 NDB 集群复制”。

增加 worker 数量会提高并行性的可能性。通常，这会提高性能，直到达到某个点，超过该点，增加 worker 数量会因并发效应（如锁争用）而降低性能。理想数量取决于硬件和工作负载；可能难以预测，通常需要通过测试才能找到。没有主键的表（始终会影响性能）可能会对具有 replica_parallel_workers > 1 的副本产生更大的负面性能影响；因此，请确保在启用此选项之前所有表都具有主键。

replica_pending_jobs_size_max

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

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

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

replica_preserve_commit_order

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

在 MySQL 8.4 中，副本服务器默认情况下启用了多线程 (replica_parallel_workers=4 是默认值)，因此 replica_preserve_commit_order=ON 是默认值，并且设置 replica_parallel_type=LOGICAL_CLOCK 也是默认值。此外，如果 replica_parallel_workers 设置为 1，则 replica_preserve_commit_order 的设置将被忽略，因为在这种情况下，事务的顺序始终会保留。

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

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

当设置 replica_preserve_commit_order=ON 时，正在执行的 worker 线程会等待所有先前的事务提交，然后才提交。当给定线程正在等待其他 worker 线程提交其事务时，它会将其状态报告为 等待前面的事务提交。使用此模式，多线程副本永远不会进入源未处于的状态。这支持将复制用于读取扩展。请参阅 第 19.4.5 节“使用复制进行扩展”。

replica_sql_verify_checksum

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

replica_transaction_retries

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

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

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

replica_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-replica-auth-info，则此值将显示在源服务器上 SHOW REPLICAS 的输出中。

虽然此变量的名称可能暗示了其他含义，但 report_password 与 MySQL 用户权限系统无关，因此不一定（甚至可能）与 MySQL 复制用户帐户的密码相同。

report_port

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

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

report_user

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

虽然此变量的名称可能暗示了其他含义，但 report_user 与 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_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 在超时之前等待的时间长度（以秒为单位）。这可用于避免 STOP REPLICA 与使用不同客户端连接到副本的其他 SQL 语句之间的死锁。

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

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

rpl_stop_slave_timeout

已弃用的 rpl_stop_replica_timeout 的同义词。

skip_replica_start

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

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

skip_slave_start

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

slave_checkpoint_group

已弃用的 replica_checkpoint_group 的同义词。

slave_checkpoint_period

已弃用的 replica_checkpoint_period 的同义词。

slave_compressed_protocol

已弃用的 replica_compressed_protocol 的别名。

slave_exec_mode

已弃用的 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 的别名。

slave_preserve_commit_order

已弃用的 replica_preserve_commit_order 的别名。

slave_skip_errors

已弃用的 replica_skip_errors 的别名。

replica_skip_errors

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

slave_sql_verify_checksum

已弃用的 replica_sql_verify_checksum 的别名。

slave_transaction_retries

已弃用的 replica_transaction_retries 的别名。

slave_type_conversions

已弃用的 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。如果您使用 CHANGE REPLICATION SOURCE TO 语句的 ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 选项在复制通道上启用了 GTID 分配，则 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 事件写入中继日志后，将其中继日志同步到磁盘（使用 fdatasync()）。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

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

值为 1 是最安全的选项，因为在发生意外停止的情况下，您最多会丢失中继日志中的一个事件。但是，它也是最慢的选项（除非磁盘具有电池支持的缓存，这使得同步非常快）。有关在副本上最能抵御意外停止的设置组合的信息，请参阅 第 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，值为 0 表示永远不会更新存储库。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

terminology_use_previous

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

MySQL 8.4 通常在 SHOW CREATE EVENT、SHOW EVENTS 和针对 Information Schema EVENTS 表的查询的输出中显示 REPLICA_SIDE_DISABLED，而不是 SLAVESIDE_DISABLED。您可以通过将 terminology_use_previous 设置为 BEFORE_8_0_26 或 BEFORE_8_2_0 来使显示 SLAVESIDE_DISABLED。

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

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