--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=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-do-table）结合使用时使用 --replicate-rewrite-db 选项。

此选项支持通道特定的复制过滤器，使多源副本能够对不同的源使用特定的过滤器。指定通道名称，后跟冒号，然后是过滤器规范。第一个冒号被解释为分隔符，任何后续的冒号都解释为文字冒号。例如，要在名为 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 9.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 模式匹配运算符的含义相同。要指定多个表，请多次使用此选项，每个表一次。这适用于跨数据库更新。请参见 第 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 服务器的权限结构访问此功能，这样数据库管理员就不需要对操作系统有任何特权访问权限。

--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 系统变量但未指定值，则可能会导致意外行为；此行为取决于使用的其他选项、指定的顺序以及是在命令行还是在选项文件中指定。

如果您指定了此变量，则指定的值也将用作中继日志索引文件的基名称。您可以通过使用 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 系统变量但未指定值，则可能会导致意外行为；此行为取决于使用的其他选项、指定的顺序以及是在命令行还是在选项文件中指定。

relay_log_purge

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

relay_log_recovery

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

禁用 relay_log_recovery 时，服务器将在启动时清理中继日志，方法是执行以下操作

此全局变量在运行时是只读的。可以使用 --relay-log-recovery 选项在副本服务器启动时设置其值，这应该在副本意外停止后使用，以确保不会处理任何可能损坏的中继日志，并且必须使用它才能保证防崩溃的副本。默认值为 0（禁用）。有关副本上最能抵抗意外停止的设置组合的信息，请参见 第 19.4.2 节，“处理副本的意外停止”。

对于多线程副本（其中 replica_parallel_workers 大于 0），在启动时设置 --relay-log-recovery 会自动处理从中继日志执行的事务序列中出现的任何不一致和差距。当使用基于文件位置的复制时，这些差距可能会发生。（有关详细信息，请参见 第 19.5.1.35 节，“复制和事务不一致”。）中继日志恢复过程使用与 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 的倍数，然后存储该值。（例外：调试服务器不执行此类舍入。）无论服务器如何构建，默认值为 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 集群复制的特殊复制场景。（有关更多信息，请参见 第 25.7.10 节，“NDB 集群复制：双向和循环复制” 和 第 25.7.12 节，“NDB 集群复制冲突解决”。）NDB 集群会忽略为 replica_exec_mode 显式设置的任何值，并始终将其视为 IDEMPOTENT。

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

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

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

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 的倍数，以进行存储或使用；将 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 时，副本使用指定数量的工作线程执行事务，再加上一个协调器线程，该线程从中继日志读取事务并将其调度到工作线程。当该值为 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 9.0 也支持多线程副本。有关更多信息，请参阅 第 25.7.11 节，“使用多线程应用程序的 NDB Cluster 复制”。

增加工作线程数量会提高并行化的可能性。通常，这会提高性能，直到某个点，超过该点，增加工作线程数量会导致性能下降，因为会发生锁争用等并发效应。理想的数量取决于硬件和工作负载；很难预测，通常必须通过测试才能找到。没有主键的表始终会影响性能，它们对具有 replica_parallel_workers > 1 的副本可能具有更大的负面性能影响；因此，请确保在启用此选项之前，所有表都具有主键。

replica_pending_jobs_size_max

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

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

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

replica_preserve_commit_order

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

在 MySQL 9.0 中，副本服务器默认情况下启用多线程 (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 9.0 中的默认值。在更改 replica_preserve_commit_order 和 replica_parallel_type 的值之前，必须停止复制 SQL 线程（如果您使用多个复制通道，则停止所有复制通道的线程）。

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

当设置 replica_preserve_commit_order=ON 时，执行的工作线程将等待所有先前事务提交，然后再提交。当某个线程正在等待其他工作线程提交其事务时，它会报告其状态为 Waiting for preceding transaction to commit。使用此模式，多线程副本永远不会进入源端从未进入的状态。这支持使用复制进行读取扩展。有关更多信息，请参阅 第 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 次，然后停止并出现错误。具有非临时错误的事务不会重试。

性能模式表 replication_applier_status 显示每个复制通道上发生的重试次数，位于 COUNT_TRANSACTIONS_RETRIES 列中。性能模式表 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（零）表示文件内容仅由操作系统刷新。设置此变量会立即对所有复制通道生效，包括正在运行的通道。

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

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 9.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 使 SLAVESIDE_DISABLED 显示出来。

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

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