MySQL8 中文参考(七十七)
19.1.4 在在线服务器上更改 GTID 模式
原文:
dev.mysql.com/doc/refman/8.0/en/replication-mode-change-online.html
19.1.4.1 复制模式概念
19.1.4.2 在线启用 GTID 事务
19.1.4.3 在线禁用 GTID 事务
19.1.4.4 验证匿名事务的复制
本节描述如何在不必使服务器脱机的情况下更改复制模式从 GTID 模式到其他模式。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-mode-change-online-concepts.html
19.1.4.1 复制模式概念
在设置在线服务器的复制模式之前,了解一些复制的关键概念非常重要。本节解释了这些概念,在尝试修改在线服务器的复制模式之前,这是必读的内容。
MySQL 中可用的复制模式依赖于不同的技术来识别已记录的事务。复制使用的事务类型在此处列出:
-
GTID 事务由全局事务标识符(GTID)标识,其形式为
UUID:NUMBER。二进制日志中的每个 GTID 事务都以Gtid_log_event开头。GTID 事务可以通过其 GTID 或记录在其中的文件的名称及其在该文件中的位置来寻址。 -
匿名事务没有 GTID;MySQL 8.0 确保日志中的每个匿名事务都以
Anonymous_gtid_log_event开头。(在 MySQL 的先前版本中,匿名事务不会以任何特定事件开头。)匿名事务只能通过文件名和位置来寻址。
使用 GTID 时,您可以利用 GTID 自动定位和自动故障转移,并使用WAIT_FOR_EXECUTED_GTID_SET()、session_track_gtids和性能模式表来监视复制事务(请参阅第 29.12.11 节,“性能模式复制表”)。
来自运行先前版本的 MySQL 的源的中继日志中的事务可能不会以任何特定事件开头,但在被重放并记录在副本的二进制日志中之后,它将以Anonymous_gtid_log_event开头。
要在线更改复制模式,需要使用具有足够权限设置全局系统变量的帐户来设置gtid_mode和enforce_gtid_consistency变量;请参阅第 7.1.9.1 节,“系统变量权限”。gtid_mode的允许值按顺序列在此处,并附有其含义:
-
OFF:只有匿名事务可以被复制。 -
OFF_PERMISSIVE:新事务是匿名的;复制的事务可以是 GTID 或匿名的。 -
ON_PERMISSIVE:新事务使用 GTID;复制的事务可以是 GTID 或匿名的。 -
ON:所有事务必须具有 GTID;匿名事务无法被复制。
可以在同一复制拓扑中同时使用匿名事务和 GTID 事务的服务器。例如,一个源,其中gtid_mode=ON可以复制到一个副本,其中gtid_mode=ON_PERMISSIVE。
gtid_mode只能一次更改一步,根据前面列表中显示的值的顺序。例如,如果gtid_mode设置为OFF_PERMISSIVE,则可以将其更改为OFF或ON_PERMISSIVE,但不能更改为ON。这是为了确保服务器正确处理从匿名事务到 GTID 事务在线更改的过程;GTID 状态(即gtid_executed的值)是持久的。这确保了服务器应用的 GTID 设置始终保留并正确,而不受gtid_mode值的任何更改影响。
显示 GTID 集的系统变量,如gtid_executed和gtid_purged,性能模式replication_connection_status表的RECEIVED_TRANSACTION_SET列,以及SHOW REPLICA STATUS输出中与 GTID 相关的结果,当没有 GTID 时都返回空字符串。关于单个 GTID 的信息来源,例如性能模式replication_applier_status_by_worker表中显示的CURRENT_TRANSACTION列中显示ANONYMOUS,当未使用 GTID 事务时。
使用gtid_mode=ON从源复制提供了使用 GTID 自动定位的能力,通过CHANGE REPLICATION SOURCE TO语句的SOURCE_AUTO_POSITION选项进行配置。正在使用的复制拓扑结构会影响是否可以启用自动定位,因为此功能依赖于 GTIDs,并且与匿名事务不兼容。强烈建议在启用自动定位之前确保拓扑结构中没有匿名事务;参见第 19.1.4.2 节,“在线启用 GTID 事务”。
源和副本上 gtid_mode 和自动定位的有效组合如下表所示。每个条目的含义如下:
-
Y: 源和副本上的gtid_mode的值兼容。 -
N: 源和副本上的gtid_mode的值不兼容。 -
*: 可以使用此值组合进行自动定位。
表 19.1 源和副本 gtid_mode 的有效组合
gtid_mode | 源 OFF | 源 OFF_PERMISSIVE | 源 ON_PERMISSIVE | 源 ON |
|---|---|---|---|---|
副本 OFF | Y | Y | N | N |
副本 OFF_PERMISSIVE | Y | Y | Y | Y* |
副本 ON_PERMISSIVE | Y | Y | Y | Y* |
副本 ON | N | N | Y | Y* |
当前的 gtid_mode 值也会影响 gtid_next。下表显示了服务器对不同值的 gtid_mode 和 gtid_next 组合的行为。每个条目的含义如下:
-
匿名: 生成匿名事务。 -
错误: 生成错误,并且不执行SET GTID_NEXT。 -
UUID:NUMBER: 生成具有指定 UUID:NUMBER 的 GTID。 -
新 GTID: 生成带有自动生成编号的 GTID。
表 19.2 gtid_mode 和 gtid_next 的有效组合
gtid_next 自动二进制日志开启 | gtid_next 自动二进制日志关闭 | gtid_next 匿名 | gtid_next UUID:NUMBER | |
|---|---|---|---|---|
gtid_mode OFF | 匿名 | 匿名 | 匿名 | 错误 |
gtid_mode OFF_PERMISSIVE | 匿名 | 匿名 | 匿名 | UUID:NUMBER |
gtid_mode ON_PERMISSIVE | 新 GTID | 匿名 | 匿名 | UUID:NUMBER |
gtid_mode ON | 新 GTID | 匿名 | 错误 | UUID:NUMBER |
当未使用二进制日志记录且 gtid_next 为 AUTOMATIC 时,不会生成任何 GTID,这与 MySQL 之前版本的行为一致。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-mode-change-online-enable-gtids.html
19.1.4.2 启用 GTID 事务在线
本节描述了如何在已在线并使用匿名事务的服务器上启用 GTID 事务,以及可选的自动定位。此过程不需要将服务器脱机,并适用于生产环境。但是,如果在启用 GTID 事务时有可能将服务器脱机,则该过程更容易。
从 MySQL 8.0.23 开始,您可以设置复制通道,为尚未具有 GTID 的复制事务分配 GTID。此功能使得可以从不使用基于 GTID 的复制的源服务器复制到使用该功能的副本服务器。如果可能在复制源服务器上启用 GTID,如本过程中所述,请使用此方法。分配 GTID 适用于无法启用 GTID 的复制源服务器。有关此选项的更多信息,请参阅第 19.1.3.6 节,“从不具有 GTID 的源复制到具有 GTID 的副本”。
在开始之前,请确保服务器满足以下先决条件:
-
您的拓扑中的所有服务器必须使用 MySQL 5.7.6 或更高版本。除非所有拓扑中的服务器都使用此版本,否则无法在任何单个服务器上在线启用 GTID 事务。
-
所有服务器的
gtid_mode设置为默认值OFF。
以下过程可以随时暂停,并在原地恢复,或通过跳转到第 19.1.4.3 节,“在线禁用 GTID 事务”的相应步骤来撤销。这使得该过程具有容错性,因为在过程中可能出现的任何不相关问题都可以像往常一样处理,然后继续在离开的地方继续进行。
注意
在继续下一步之前,您必须完成每个步骤。
要启用 GTID 事务:
-
在每台服务器上执行:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;让服务器在正常工作负载下运行一段时间,并监视日志。如果此步骤在日志中引发任何警告,请调整应用程序,使其仅使用 GTID 兼容功能,并且不生成任何警告。
重要
这是第一个重要的步骤。在继续下一步之前,您必须确保错误日志中没有生成任何警告。
-
在每台服务器上执行:
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; -
在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;不重要哪个服务器首先执行此语句,但重要的是所有服务器在任何服务器开始下一步之前完成此步骤。
-
在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;这个语句首先由哪台服务器执行并不重要。
-
在每台服务器上,等待直到状态变量
ONGOING_ANONYMOUS_TRANSACTION_COUNT为零。可以使用以下方式进行检查:SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';注意
在副本上,理论上可能会显示零,然后再次显示非零。这不是问题,只要它显示零一次即可。
-
等待生成到第 5 步的所有事务复制到所有服务器。您可以在不停止更新的情况下执行此操作:唯一重要的是所有匿名事务都得到复制。
参见 Section 19.1.4.4, “验证匿名事务的复制” 以了解检查所有匿名事务是否已复制到所有服务器的一种方法。
-
如果您将二进制日志用于除复制之外的任何其他用途,例如时间点备份和恢复,请等到您不再需要具有不带 GTIDs 事务的旧二进制日志。
例如,在第 6 步完成后,您可以在正在进行备份的服务器上执行
FLUSH LOGS。然后要么明确地进行备份,要么等待您设置的任何定期备份例程的下一次迭代。理想情况下,等待服务器清除在完成第 6 步时存在的所有二进制日志。还要等待在第 6 步之前进行的任何备份过期。
重要
这是第二个重要的要点。理解二进制日志中包含的匿名事务,如果没有 GTIDs,在下一步之后将无法使用。在此步骤之后,您必须确保在拓扑结构中不存在不带 GTIDs 的事务。
-
在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = ON; -
在每台服务器上,将
gtid_mode=ON和enforce_gtid_consistency=ON添加到my.cnf。现在,您可以确保所有事务都具有 GTID(除了在第 5 步或更早生成的事务已经被处理)。为了开始使用 GTID 协议,以便稍后执行自动故障转移,在每个副本上执行以下操作。可选地,如果使用多源复制,请为每个通道执行此操作,并包括
FOR CHANNEL *channel*子句:STOP SLAVE [FOR CHANNEL 'channel']; CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel']; START SLAVE [FOR CHANNEL 'channel']; Or from MySQL 8.0.22 / 8.0.23: STOP REPLICA [FOR CHANNEL 'channel']; CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1 [FOR CHANNEL 'channel']; START REPLICA [FOR CHANNEL 'channel'];
原文:
dev.mysql.com/doc/refman/8.0/en/replication-mode-change-online-disable-gtids.html
19.1.4.3 在线禁用 GTID 事务
本节描述了如何在已经在线的服务器上禁用 GTID 事务。此过程无需将服务器脱机,并适用于在生产环境中使用。但是,如果您有可能在禁用 GTID 模式时将服务器脱机,那么该过程会更加简单。
该过程类似于在服务器在线时启用 GTID 事务,但是步骤相反。唯一不同的是等待已记录事务复制的时间点。
在开始之前,请确保服务器满足以下先决条件:
-
您的拓扑中的所有服务器必须使用 MySQL 5.7.6 或更高版本。除非拓扑中的所有服务器都使用此版本,否则无法在线禁用 GTID 事务。
-
所有服务器的
gtid_mode设置为ON。 -
任何服务器上都未设置
--replicate-same-server-id选项。如果此选项与--log-slave-updates选项(默认情况下)和启用了二进制日志记录(也是默认情况)一起设置,则无法禁用 GTID 事务。在没有 GTID 的情况下,这些选项的组合会在循环复制中导致无限循环。
-
在每个副本上执行以下操作,如果您正在使用多源复制,请为每个通道执行,并包括
FOR CHANNEL通道子句:STOP SLAVE [FOR CHANNEL 'channel']; CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE = file, \ MASTER_LOG_POS = position [FOR CHANNEL 'channel']; START SLAVE [FOR CHANNEL 'channel']; Or from MySQL 8.0.22 / 8.0.23: STOP REPLICA [FOR CHANNEL 'channel']; CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 0, SOURCE_LOG_FILE = file, \ SOURCE_LOG_POS = position [FOR CHANNEL 'channel']; START REPLICA [FOR CHANNEL 'channel']; -
在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE; -
在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE; -
在每台服务器上,等待变量@@GLOBAL.GTID_OWNED 等于空字符串。可以使用以下方式进行检查:
SELECT @@GLOBAL.GTID_OWNED;理论上,在副本上,这可能为空,然后再次变为非空。这不是问题,只要它曾经为空就足够了。
-
等待当前存在于任何二进制日志中的所有事务在所有副本中复制。参见 Section 19.1.4.4, “验证匿名事务的复制”,了解检查所有匿名事务是否已复制到所有服务器的一种方法。
-
如果您将二进制日志用于除复制之外的任何其他用途,例如进行时间点备份或还原:请等待您不再需要具有 GTID 事务的旧二进制日志。
例如,在完成第 5 步之后,您可以在正在进行备份的服务器上执行
FLUSH LOGS。然后,要么明确进行备份,要么等待您设置的任何定期备份例程的下一次迭代。理想情况下,等待服务器清除在步骤 5 完成时存在的所有二进制日志。还要等待在步骤 5 之前备份的任何备份过期。
重要提示
这是整个过程中的一个重要点。重要的是要理解,包含 GTID 事务的日志在下一步之后不能再使用。在继续之前,您必须确保拓扑结构中不存在任何 GTID 事务。
-
在每台服务器上执行:
SET @@GLOBAL.GTID_MODE = OFF; -
在每台服务器上,在
my.cnf中设置gtid_mode=OFF。如果您想设置
enforce_gtid_consistency=OFF,现在可以这样做。设置后,您应该将enforce_gtid_consistency=OFF添加到您的配置文件中。
如果您想降级到 MySQL 的早期版本,现在可以使用正常的降级过程进行操作。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-mode-change-online-verify-transactions.html
19.1.4.4 验证匿名事务的复制
本节解释了如何监视复制拓扑并验证所有匿名事务是否已被复制。在在线更改复制模式时,这很有帮助,因为您可以验证更改为 GTID 事务是安全的。
有几种等待事务复制的可能方法:
最简单的方法是,无论您的拓扑如何,但依赖于时间的方法如下:如果您确信副本永远不会落后于 N 秒,只需等待多于 N 秒。或者等待一天,或者您认为对于您的部署是安全的任何时间段。
在某种意义上更安全的方法,因为它不依赖于时间:如果您只有一个带有一个或多个副本的源,则执行以下操作:
-
在源端执行:
SHOW MASTER STATUS;记下“文件”和“位置”列中的值。
-
在每个副本上,使用源端的文件和位置信息执行:
SELECT MASTER_POS_WAIT(file, position); Or from MySQL 8.0.26: SELECT SOURCE_POS_WAIT(file, position);
如果您有一个源和多个级别的副本,或者换句话说,您有副本的副本,请从源开始,然后在每个级别上重复步骤 2,然后所有直接副本,然后所有副本的副本,依此类推。
如果您使用循环复制拓扑,其中多个服务器可能有写客户端,请为每个源-副本连接执行步骤 2,直到完成整个循环。重复整个过程,以便完成整个循环两次。
例如,假设您有三台服务器 A、B 和 C,在一个循环中进行复制,即 A -> B -> C -> A。然后,操作步骤如下:
-
在 A 上执行步骤 1,在 B 上执行步骤 2。
-
在 B 上执行步骤 1,在 C 上执行步骤 2。
-
在 C 上执行步骤 1,在 A 上执行步骤 2。
-
在 A 上执行步骤 1,在 B 上执行步骤 2。
-
在 B 上执行步骤 1,在 C 上执行步骤 2。
-
在 C 上执行步骤 1,在 A 上执行步骤 2。
19.1.5 MySQL 多源复制
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html
19.1.5.1 配置多源复制
19.1.5.2 为基于 GTID 的复制配置多源复制副本
19.1.5.3 向多源复制副本添加基于 GTID 的源
19.1.5.4 向多源复制副本添加基于二进制日志的复制源
19.1.5.5 启动多源复制副本
19.1.5.6 停止多源复制副本
19.1.5.7 重置多源复制副本
19.1.5.8 监控多源复制
MySQL 多源复制使副本能够并行接收来自多个直接源的事务。在多源复制拓扑中,副本为应该接收事务的每个源创建一个复制通道。有关复制通道功能的更多信息,请参见第 19.2.2 节,“复制通道”。
您可能选择实现多源复制以实现以下目标:
-
将多个服务器备份到单个服务器。
-
合并表分片。
-
将数据从多个服务器整合到单个服务器。
多源复制在应用事务时不实现任何冲突检测或解决方案,如果需要,这些任务由应用程序自行处理。
注意
多源复制副本上的每个通道必须从不同的源复制。您不能从单个副本设置多个复制通道到单个源。这是因为在复制拓扑中,副本的服务器 ID 必须是唯一的。源仅通过副本的服务器 ID 区分副本,而不是通过复制通道的名称,因此它无法识别来自同一副本的不同复制通道。
多源复制副本也可以设置为多线程复制副本,方法是将系统变量replica_parallel_workers(从 MySQL 8.0.26 开始)或slave_parallel_workers设置为大于 0 的值。当在多源复制副本上执行此操作时,副本上的每个通道都有指定数量的应用程序线程,以及一个协调器线程来管理它们。您无法为单个通道配置应用程序线程的数量。
从 MySQL 8.0 开始,可以在特定复制通道上配置多源副本的复制过滤器。当相同数据库或表存在于多个源上,并且您只需要副本从一个源复制它时,可以使用特定通道的复制过滤器。对于基于 GTID 的复制,如果同一事务可能来自多个源(例如在钻石拓扑中),您必须确保所有通道上的过滤设置相同。有关更多信息,请参见 Section 19.2.5.4, “Replication Channel Based Filters”。
本节提供了关于如何配置多源复制的源和副本、如何启动、停止和重置多源副本以及如何监控多源复制的教程。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-configuration.html
19.1.5.1 配置多源复制
多源复制拓扑至少需要配置两个源和一个副本。在这些教程中,我们假设您有两个源source1和source2,以及一个副本replicahost。副本从每个源复制一个数据库,从source1复制db1,从source2复制db2。
多源复制拓扑中的源可以配置为使用基于 GTID 的复制,或者基于二进制日志位置的复制。查看第 19.1.3.4 节,“使用 GTIDs 设置复制”了解如何配置使用基于 GTID 的复制的源。查看第 19.1.2.1 节,“设置复制源配置”了解如何配置使用基于文件位置的复制的源。
多源复制拓扑中的副本需要TABLE存储库用于副本的连接元数据存储库和应用程序元数据存储库,这在 MySQL 8.0 中是默认的。多源复制与已弃用的替代文件存储库不兼容。
在所有副本上创建一个适当的用户帐户,副本可以使用该帐户进行连接。您可以在所有源上使用相同的帐户,或者在每个源上使用不同的帐户。如果您仅为复制目的创建一个帐户,则该帐户只需要REPLICATION SLAVE权限。例如,要设置一个名为ted的新用户,该用户可以从副本replicahost连接,请使用mysql客户端在每个源上发出以下语句:
mysql> CREATE USER 'ted'@'replicahost' IDENTIFIED BY '*password*';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'ted'@'replicahost';
有关更多详细信息,以及关于 MySQL 8.0 新用户默认身份验证插件的重要信息,请参阅第 19.1.2.3 节,“为复制创建用户”。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-provision-replica.html
19.1.5.2 为基于 GTID 的复制提供多源副本
如果多源复制拓扑中的源具有现有数据,可以在开始复制之前使用相关数据为副本提供数据以节省时间。在多源复制拓扑中,无法使用克隆或复制数据目录来为副本提供来自所有源的数据,您可能还想要仅从每个源复制特定数据库。因此,为此类副本提供数据的最佳策略是使用mysqldump在每个源上创建适当的转储文件,然后使用mysql客户端在副本上导入转储文件。
如果您正在使用基于 GTID 的复制,请注意SET @@GLOBAL.gtid_purged语句,该语句由mysqldump放置在转储输出中。此语句将源上执行的事务的 GTID 传输到副本,副本需要这些信息。然而,对于比从一个源为一个新的空副本提供更复杂的情况,您需要检查该语句在副本使用的 MySQL 版本中的影响,并相应处理该语句。以下指导总结了适当的操作,但更多详情请参阅mysqldump文档。
由mysqldump编写的SET @@GLOBAL.gtid_purged语句在 MySQL 8.0 的版本中与 MySQL 5.6 和 5.7 中的行为不同。在 MySQL 5.6 和 5.7 中,该语句替换了副本上的gtid_purged的值,并且在这些版本中,只有在副本的具有 GTID 的事务记录(gtid_executed集)为空时才能更改该值。在多源复制拓扑中,因此在重放转储文件之前必须从转储输出中删除SET @@GLOBAL.gtid_purged语句,因为不能应用包含此语句的第二个或后续转储文件。还要注意,在 MySQL 5.6 和 5.7 中,这个限制意味着必须在具有空的gtid_executed集的副本上以单个操作应用所有源的转储文件。您可以通过在副本上发出RESET MASTER来清除副本的 GTID 执行历史,但如果在副本上有其他需要的带有 GTID 的事务,请选择从 Section 19.1.3.5, “Using GTIDs for Failover and Scaleout”中描述的方法中选择一种替代方法进行配置。
从 MySQL 8.0 开始,SET @@GLOBAL.gtid_purged语句将从转储文件中的 GTID 集添加到副本上现有的gtid_purged集中。因此,在副本上重放转储文件时,该语句可能会留在转储输出中,并且可以在不同时间重放转储文件。然而,重要的是要注意,mysqldump为SET @@GLOBAL.gtid_purged语句包含的值包括源上gtid_executed集中所有事务的 GTID,即使这些事务更改了数据库的被抑制部分,或者服务器上未包含在部分转储中的其他数据库。如果在副本上重放包含任何相同 GTID 的第二个或后续转储文件(例如,来自相同源的另一个部分转储,或者来自具有重叠事务的另一个源的转储),第二个转储文件中的任何SET @@GLOBAL.gtid_purged语句将失败,因此必须从转储输出中删除。
对于来自 MySQL 8.0.17 的源,作为删除SET @@GLOBAL.gtid_purged语句的替代方案,您可以将mysqldump的--set-gtid-purged选项设置为COMMENTED,以包含该语句但注释掉,这样在加载转储文件时不会执行该语句。如果您正在使用来自同一源的两个部分转储文件为副本提供数据,并且第二个转储文件中的 GTID 集合与第一个相同(因此在转储之间源上没有执行新事务),则可以在输出第二个转储文件时将mysqldump的--set-gtid-purged选项设置为OFF,以省略该语句。
在以下配置示例中,我们假设SET @@GLOBAL.gtid_purged语句不能保留在转储输出中,并且必须从���件中删除并手动处理。我们还假设在开始配置之前,在副本上没有带有 GTID 的想要的事务。
-
要为名为
source1上的名为db1的数据库和名为source2上的名为db2的数据库创建转储文件,请按以下方式为source1运行mysqldump:mysqldump -u<*user*> -p<*password*> --single-transaction --triggers --routines --set-gtid-purged=ON --databases db1 > dumpM1.sql然后按以下方式为
source2运行mysqldump:mysqldump -u<*user*> -p<*password*> --single-transaction --triggers --routines --set-gtid-purged=ON --databases db2 > dumpM2.sql -
记录
gtid_purged值,该值是mysqldump添加到每个转储文件中的。例如,对于在 MySQL 5.6 或 5.7 上创建的转储文件,可以像这样提取该值:cat dumpM1.sql | grep GTID_PURGED | cut -f2 -d'=' | cut -f2 -d$'\'' cat dumpM2.sql | grep GTID_PURGED | cut -f2 -d'=' | cut -f2 -d$'\''从 MySQL 8.0 开始,格式已更改,您可以像这样提取该值:
cat dumpM1.sql | grep GTID_PURGED | perl -p0 -e 's#/\*.*?\*/##sg' | cut -f2 -d'=' | cut -f2 -d$'\'' cat dumpM2.sql | grep GTID_PURGED | perl -p0 -e 's#/\*.*?\*/##sg' | cut -f2 -d'=' | cut -f2 -d$'\''每种情况下的结果应该是一个 GTID 集合,例如:
source1: 2174B383-5441-11E8-B90A-C80AA9429562:1-1029 source2: 224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695 -
从每个转储文件中删除包含
SET @@GLOBAL.gtid_purged语句的行。例如:sed '/GTID_PURGED/d' dumpM1.sql > dumpM1_nopurge.sql sed '/GTID_PURGED/d' dumpM2.sql > dumpM2_nopurge.sql -
使用mysql客户端将每个编辑过的转储文件导入到副本中。例如:
mysql -u<*user*> -p<*password*> < dumpM1_nopurge.sql mysql -u<*user*> -p<*password*> < dumpM2_nopurge.sql -
在副本上,发出
RESET MASTER以清除 GTID 执行历史记录(假设,如上所述,所有转储文件都已导入,并且在副本上没有带有 GTID 的想要的事务)。然后发出SET @@GLOBAL.gtid_purged语句,将gtid_purged值设置为所有转储文件中所有 GTID 集合的并集,就像在第 2 步中记录的那样。例如:mysql> RESET MASTER; mysql> SET @@GLOBAL.gtid_purged = "2174B383-5441-11E8-B90A-C80AA9429562:1-1029, 224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695";如果在转储文件中的 GTID 集合之间存在或可能存在重叠的事务,则可以使用 Section 19.1.3.8, “操作 GTID 的存储函数示例”中描述的存储函数事先检查这一点,并计算所有 GTID 集合的并集。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-adding-gtid-master.html
19.1.5.3 向多源副本添加基于 GTID 的源
这些步骤假定您已经在源上使用gtid_mode=ON启用了事务的 GTIDs,创建了一个复制用户,确保副本正在使用基于TABLE的复制应用程序元数据存储库,并根据需要为副本提供了来自源的数据。
使用CHANGE REPLICATION SOURCE TO语句(从 MySQL 8.0.23 开始)或CHANGE MASTER TO语句(MySQL 8.0.23 之前)在副本上为每个源配置一个复制通道(参见 Section 19.2.2, “Replication Channels”)。FOR CHANNEL子句用于指定通道。对于基于 GTID 的复制,使用 GTID 自动定位来与源进行同步(参见 Section 19.1.3.3, “GTID Auto-Positioning”)。设置SOURCE_AUTO_POSITION | MASTER_AUTO_POSITION选项以指定使用自动定位。
例如,要将source1和source2添加为副本的源,请使用mysql客户端在副本上发出两次语句,如下所示:
mysql> CHANGE MASTER TO MASTER_HOST="source1", MASTER_USER="ted", \
MASTER_PASSWORD="*password*", MASTER_AUTO_POSITION=1 FOR CHANNEL "source_1";
mysql> CHANGE MASTER TO MASTER_HOST="source2", MASTER_USER="ted", \
MASTER_PASSWORD="*password*", MASTER_AUTO_POSITION=1 FOR CHANNEL "source_2";
Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST="source1", SOURCE_USER="ted", \
SOURCE_PASSWORD="*password*", SOURCE_AUTO_POSITION=1 FOR CHANNEL "source_1";
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST="source2", SOURCE_USER="ted", \
SOURCE_PASSWORD="*password*", SOURCE_AUTO_POSITION=1 FOR CHANNEL "source_2";
要使副本仅从source1复制数据库db1,并且仅从source2复制数据库db2,请使用mysql客户端为每个通道发出CHANGE REPLICATION FILTER语句,如下所示:
mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db1.%') FOR CHANNEL "source_1";
mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db2.%') FOR CHANNEL "source_2";
有关CHANGE REPLICATION FILTER语句的完整语法和其他可用选项,请参见 Section 15.4.2.2, “CHANGE REPLICATION FILTER Statement”。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-adding-binlog-master.html
19.1.5.4 将基于二进制日志的复制源添加到多源复制副本
这些步骤假定源上已启用二进制日志记录(这是默认设置),副本正在使用基于TABLE的复制应用程序元数据存储库(这是 MySQL 8.0 中的默认设置),并且您已启用了一个复制用户并记录了当前的二进制日志文件名和位置。
使用CHANGE REPLICATION SOURCE TO语句(从 MySQL 8.0.23 开始)或CHANGE MASTER TO语句(在 MySQL 8.0.23 之前)为副本上的每个源配置一个复制通道(请参见 Section 19.2.2, “Replication Channels”)。FOR CHANNEL子句用于指定通道。例如,要将source1和source2添加为副本的源,请使用mysql客户端在副本上两次发出该语句,如下所示:
mysql> CHANGE MASTER TO MASTER_HOST="source1", MASTER_USER="ted", MASTER_PASSWORD="*password*", \
MASTER_LOG_FILE='source1-bin.000006', MASTER_LOG_POS=628 FOR CHANNEL "source_1";
mysql> CHANGE MASTER TO MASTER_HOST="source2", MASTER_USER="ted", MASTER_PASSWORD="*password*", \
MASTER_LOG_FILE='source2-bin.000018', MASTER_LOG_POS=104 FOR CHANNEL "source_2";
Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST="source1", SOURCE_USER="ted", SOURCE_PASSWORD="*password*", \
SOURCE_LOG_FILE='source1-bin.000006', SOURCE_LOG_POS=628 FOR CHANNEL "source_1";
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST="source2", SOURCE_USER="ted", SOURCE_PASSWORD="*password*", \
SOURCE_LOG_FILE='source2-bin.000018', SOURCE_LOG_POS=104 FOR CHANNEL "source_2";
要使副本仅从source1复制数据库db1,并且仅从source2复制数据库db2,请使用mysql客户端为每个通道发出CHANGE REPLICATION FILTER语句,如下所示:
mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db1.%') FOR CHANNEL "source_1";
mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db2.%') FOR CHANNEL "source_2";
对于CHANGE REPLICATION FILTER语句的完整语法和其他可用选项,请参见 Section 15.4.2.2, “CHANGE REPLICATION FILTER Statement”。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-start-replica.html
19.1.5.5 启动多源复制副本
一旦为所有复制源添加了通道,请发出START REPLICA(或在 MySQL 8.0.22 之前,START SLAVE)语句以开始复制。当您在副本上启用了多个通道时,您可以选择启动所有通道,或选择特定通道启动。例如,要分别启动两个通道,请使用mysql客户端发出以下语句:
mysql> START SLAVE FOR CHANNEL "source_1";
mysql> START SLAVE FOR CHANNEL "source_2";
Or from MySQL 8.0.22:
mysql> START REPLICA FOR CHANNEL "source_1";
mysql> START REPLICA FOR CHANNEL "source_2";
要查看START REPLICA命令的完整语法和其他可用选项,请参见 Section 15.4.2.6, “START REPLICA Statement”。
要验证两个通道是否已启动并正常运行,您可以在副本上发出SHOW REPLICA STATUS语句,例如:
mysql> SHOW SLAVE STATUS FOR CHANNEL "source_1"\G
mysql> SHOW SLAVE STATUS FOR CHANNEL "source_2"\G
Or from MySQL 8.0.22:
mysql> SHOW REPLICA STATUS FOR CHANNEL "source_1"\G
mysql> SHOW REPLICA STATUS FOR CHANNEL "source_2"\G
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-stop-replica.html
19.1.5.6 停止多源复制
STOP REPLICA语句可用于停止多源复制。默认情况下,如果在多源复制上使用STOP REPLICA语句,则所有通道都会停止。可选择使用FOR CHANNEL *channel*子句仅停止特定通道。
-
停止所有当前配置的复制通道:
mysql> STOP SLAVE; Or from MySQL 8.0.22: mysql> STOP REPLICA; -
若要仅停止命名通道,请使用
FOR CHANNEL *channel*子句:mysql> STOP SLAVE FOR CHANNEL "source_1"; Or from MySQL 8.0.22: mysql> STOP REPLICA FOR CHANNEL "source_1";
有关STOP REPLICA命令的完整语法和其他可用选项,请参见 Section 15.4.2.8, “STOP REPLICA Statement”。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-reset-replica.html
19.1.5.7 重置多源复制
RESET REPLICA语句可用于重置多源复制。默认情况下,如果在多源复制上使用RESET REPLICA语句,则会重置所有通道。可选择使用FOR CHANNEL *channel*子句仅重置特定通道。
-
要重置当前配置的所有复制通道:
mysql> RESET SLAVE; Or from MySQL 8.0.22: mysql> RESET REPLICA; -
要仅重置命名通道,请使用
FOR CHANNEL *channel*子句:mysql> RESET SLAVE FOR CHANNEL "source_1"; Or from MySQL 8.0.22: mysql> RESET REPLICA FOR CHANNEL "source_1";
对于基于 GTID 的复制,请注意RESET REPLICA对复制的 GTID 执行历史没有影响。如果要清除此内容,请在复制上发出RESET MASTER。
RESET REPLICA使复制忘记其复制位置,并清除中继日志,但不会更改任何复制连接参数(如源主机名)或复制过滤器。如果要删除某个通道的这些内容,请发出RESET REPLICA ALL。
有关RESET REPLICA命令的完整语法和其他可用选项,请参见 Section 15.4.2.4, “RESET REPLICA Statement”。
译文:
dev.mysql.com/doc/refman/8.0/en/replication-multi-source-monitoring.html
19.1.5.8 监控多源复制
要监视复制通道的状态,存在以下选项:
-
使用复制性能模式表。这些表的第一列是
Channel_Name。这使您可以基于Channel_Name编写复杂查询。请参见第 29.12.11 节,“性能模式复制表”。 -
使用
SHOW REPLICA STATUS FOR CHANNEL *channel*。默认情况下,如果未使用FOR CHANNEL *channel*子句,则此语句将显示所有通道的复制状态,每个通道一行。标识符Channel_name将作为结果集中的一列添加。如果提供了FOR CHANNEL *channel*子句,则结果仅显示命名复制通道的状态。
注意
SHOW VARIABLES语句不适用于多个复制通道。通过这些变量可用的信息已迁移到复制性能表。在具有多个通道的拓扑中使用SHOW VARIABLES语句仅显示默认通道的状态。
启用多源复制时发出的错误代码和消息指定生成错误的通道。
19.1.5.8.1 使用性能模式表监视通道
本节解释了如何使用复制性能模式表监视通道。您可以选择监视所有通道或现有通道的子集。
要监视所有通道的连接状态:
mysql> SELECT * FROM replication_connection_status\G;
*************************** 1\. row ***************************
CHANNEL_NAME: source_1
GROUP_NAME:
SOURCE_UUID: 046e41f8-a223-11e4-a975-0811960cc264
THREAD_ID: 24
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 046e41f8-a223-11e4-a975-0811960cc264:4-37
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
*************************** 2\. row ***************************
CHANNEL_NAME: source_2
GROUP_NAME:
SOURCE_UUID: 7475e474-a223-11e4-a978-0811960cc264
THREAD_ID: 26
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 7475e474-a223-11e4-a978-0811960cc264:4-6
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00 2 rows in set (0.00 sec)
在上述输出中,有两个启用的通道,如CHANNEL_NAME字段所示,它们分别称为source_1和source_2。
添加CHANNEL_NAME字段使您能够查询特定通道的性能模式表。要监视命名通道的连接状态,请使用WHERE CHANNEL_NAME=*channel*子句:
mysql> SELECT * FROM replication_connection_status WHERE CHANNEL_NAME='source_1'\G
*************************** 1\. row ***************************
CHANNEL_NAME: source_1
GROUP_NAME:
SOURCE_UUID: 046e41f8-a223-11e4-a975-0811960cc264
THREAD_ID: 24
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 046e41f8-a223-11e4-a975-0811960cc264:4-37
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00 1 row in set (0.00 sec)
同样,WHERE CHANNEL_NAME=*channel*子句可用于监视其他复制性能模式表以获取特定通道的信息。有关更多信息,请参见第 29.12.11 节,“性能模式复制表”。
19.1.6 复制和二进制日志选项和变量
19.1.6.1 复制和二进制日志选项和变量参考
19.1.6.2 复制源选项和变量
19.1.6.3 副本服务器选项和变量
19.1.6.4 二进制日志选项和变量
19.1.6.5 全局事务 ID 系统变量
以下各节包含有关用于复制和控制二进制日志的mysqld选项和服务器变量的信息。用于源和副本的选项和变量分别进行了介绍,与二进制日志记录和全局事务标识符(GTID)相关的选项和变量也是如此。还包括一组快速参考表,提供有关这些选项和变量的基本信息。
特别重要的是server_id 系统变量。
| 命令行格式 | --server-id=# |
|---|---|
| 系统变量 | server_id |
| 范围 | 全局 |
| 动态 | 是 |
SET_VAR 提示适用 | 否 |
| 类型 | 整数 |
| 默认值 | 1 |
| 最小值 | 0 |
| 最大值 | 4294967295 |
此变量指定服务器 ID。server_id 默认设置为 1。服务器可以使用此默认 ID 启动,但是当启用二进制日志记录时,如果您没有显式设置server_id 来指定服务器 ID,则会发出信息消息。
对于用于复制拓扑的服务器,您必须为每个复制服务器指定一个唯一的服务器 ID,范围从 1 到 2³² − 1。“唯一”意味着每个 ID 必须与复制拓扑中任何其他源或副本正在使用的任何其他 ID 不同。有关更多信息,请参见第 19.1.6.2 节,“复制源选项和变量”,以及第 19.1.6.3 节,“副本服务器选项和变量”。
如果服务器 ID 设置为 0,则会进行二进制日志记录,但具有服务器 ID 0 的源会拒绝来自副本的任何连接,具有服务器 ID 0 的副本会拒绝连接到源。请注意,尽管您可以将服务器 ID 动态更改为非零值,但这样做并不会立即启用复制。您必须更改服务器 ID,然后重新启动服务器以初始化副本。
有关更多信息,请参见第 19.1.2.2 节,“设置复制配置”。
server_uuid
MySQL 服务器生成一个真正的 UUID,除了默认或用户提供的server_id系统变量设置之外。这作为全局只读变量server_uuid可用。
注意
server_uuid系统变量的存在不会改变为每个 MySQL 服务器设置唯一server_id值的要求,如本节前面描述的。
| 系统变量 | server_uuid |
|---|---|
| 范围 | 全局 |
| 动态 | 否 |
SET_VAR提示适用 | 否 |
| 类型 | 字符串 |
启动时,MySQL 服务器会自动获取 UUID,如���所示:
-
尝试读取并使用写入文件
*data_dir*/auto.cnf中的 UUID(其中*data_dir*是服务器的数据目录)。 -
如果未找到
*data_dir*/auto.cnf,则生成一个新的 UUID 并将其保存到此文件中,必要时创建该文件。
auto.cnf文件的格式类似于my.cnf或my.ini文件的格式。auto.cnf只有一个包含单个server_uuid设置和值的[auto]部分;文件的内容类似于这里显示的内容:
[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562
重要
auto.cnf文件是自动生成的;不要尝试编写或修改此文件。
在使用 MySQL 复制时,源和副本知道彼此的 UUID。副本的 UUID 值可以在SHOW REPLICAS的输出中看到(或在 MySQL 8.0.22 之前,在SHOW SLAVE HOSTS中)。一旦执行了START REPLICA,源的 UUID 值就可以在副本的SHOW REPLICA STATUS的输出中找到(在 MySQL 8.0.22 中,SLAVE关键字被REPLICA替换)。
注意
发出STOP REPLICA或RESET REPLICA语句不会重置在副本上使用的源 UUID。
服务器的server_uuid也用于 GTID 中在该服务器上发起的事务。有关更多信息,请参见第 19.1.3 节,“使用全局事务标识符进行复制”。
在启动时,如果复制 I/O(接收器)线程的源 UUID 等于自身 UUID,则会生成错误并中止,除非已设置--replicate-same-server-id选项。此外,如果以下任一情况为真,则复制接收器线程会生成警告:
-
没有符合预期
server_uuid的源存在。 -
源的
server_uuid已更改,尽管从未执行过CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO语句。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-options-reference.html
19.1.6.1 复制和二进制日志选项和变量参考
下面的两个部分提供了关于适用于复制和二进制日志的 MySQL 命令行选项和系统变量的基本信息。
复制选项和变量
下面列表中的命令行选项和系统变量与复制源服务器和副本相关。第 19.1.6.2 节,“复制源选项和变量” 提供了有关与复制源服务器相关的选项和变量的更详细信息。有关与副本相关的选项和变量的更多信息,请参见第 19.1.6.3 节,“副本服务器选项和变量”。
-
abort-slave-event-count: 用于 MySQL 测试的调试和复制测试的选项。 -
auto_increment_increment: AUTO_INCREMENT 列按此值递增。 -
auto_increment_offset: 添加到 AUTO_INCREMENT 列的偏移量。 -
Com_change_master: CHANGE REPLICATION SOURCE TO 和 CHANGE MASTER TO 语句的计数。 -
Com_change_replication_source: CHANGE REPLICATION SOURCE TO 和 CHANGE MASTER TO 语句的计数。 -
Com_replica_start: START REPLICA 和 START SLAVE 语句的计数。 -
Com_replica_stop: STOP REPLICA 和 STOP SLAVE 语句的计数。 -
Com_show_master_status: SHOW MASTER STATUS 语句的计数。 -
Com_show_replica_status: SHOW REPLICA STATUS 和 SHOW SLAVE STATUS 语句的计数。 -
Com_show_replicas: SHOW REPLICAS 和 SHOW SLAVE HOSTS 语句的计数。 -
Com_show_slave_hosts: SHOW REPLICAS 和 SHOW SLAVE HOSTS 语句的计数。 -
Com_show_slave_status: SHOW REPLICA STATUS 和 SHOW SLAVE STATUS 语句的计数。 -
Com_slave_start: START REPLICA 和 START SLAVE 语句的计数。 -
Com_slave_stop: STOP REPLICA 和 STOP SLAVE 语句的计数。 -
disconnect-slave-event-count: mysql-test 用于调试和测试复制的选项。 -
enforce_gtid_consistency: 防止无法以事务安全方式记录的语句执行。 -
expire_logs_days: 在多少天后清除二进制日志。 -
gtid_executed: 全局:二进制日志中的所有 GTID(全局)或当前事务(会话)中的所有 GTID。只读。 -
gtid_executed_compression_period: 每发生这么多次事务时压缩 gtid_executed 表。0 表示永远不压缩此表。仅在禁用二进制日志记录时适用。 -
gtid_mode: 控制是否启用基于 GTID 的日志记录以及事务日志可以包含的类型。 -
gtid_next: 指定后续事务或事务的 GTID;详细信息请参阅文档。 -
gtid_owned: 由此客户端(会话)或所有客户端拥有的 GTID 集合,以及所有者的线程 ID(全局)。只读。 -
gtid_purged: 已从二进制日志中清除的所有 GTID 集合。 -
immediate_server_version: 作为即时复制源的服务器的 MySQL 服务器发布号码。 -
init_replica: 当复制品连接到源时执行的语句。 -
init_slave: 当复制品连接到源时执行的语句。 -
log_bin_trust_function_creators: 如果等于 0(默认值),则在使用--log-bin 时,只允许具有 SUPER 特权的用户创建存储函数,并且只有创建的函数不会破坏二进制日志记录时才允许。 -
log_statements_unsafe_for_binlog: 禁用写入错误日志中的错误 1592 警告。 -
master-info-file: 记住源和 I/O 复制线程在源二进制日志中的位置的文件的位置和名称。 -
master-retry-count: 在放弃之前,复制品尝试连接到源的次数。 -
master_info_repository: 是否将包含源信息和复制 I/O 线程位置在源二进制日志中的连接元数据存储库写入文件或表。 -
max_relay_log_size: 如果非零,则中继日志在其大小超过此值时会自动旋转。如果为零,则旋转发生的大小由 max_binlog_size 的值确定。 -
original_commit_timestamp: 事务在原始源上提交时的时间。 -
original_server_version: 事务最初提交的服务器的 MySQL 服务器发布号。 -
relay_log: 用于中继日志的位置和基本名称。 -
relay_log_basename: 中继日志的完整路径,包括文件名。 -
relay_log_index: 用于保存最后中继日志列表的文件的位置和名称。 -
relay_log_info_file: 用于复制记录有关中继日志信息的应用程序元数据存储库的文件名。 -
relay_log_info_repository: 是否将复制 SQL 线程在中继日志中的位置写入文件或表。 -
relay_log_purge: 确定是否清除中继日志。 -
relay_log_recovery: 是否启用在启动时从源自动恢复中继日志文件;必须为崩溃安全的复制启用。 -
relay_log_space_limit: 用于所有中继日志的最大空间。 -
replica_checkpoint_group: 多线程复制在调用检查点操作更新进度状态之前处理的最大事务数。不支持 NDB 集群。 -
replica_checkpoint_period: 在此毫秒数后更新多线程复制的进度状态并将中继日志信息刷新到磁盘。不支持 NDB 集群。 -
replica_compressed_protocol: 使用源/复制协议��压缩。 -
replica_exec_mode: 允许在幂等模式(键和一些其他错误被抑制)和严格模式之间切换复制线程;严格模式是默认的,除了 NDB 集群,那里始终使用幂等模式。 -
replica_load_tmpdir: 复制 LOAD DATA 语句时,复制品应将其临时文件放置的位置。 -
replica_max_allowed_packet: 从���制源服务器发送到复制品的数据包的最大大小(以字节为单位);覆盖 max_allowed_packet。 -
replica_net_timeout: 从源/复制连接中等待更多数据的秒数,然后中止读取。 -
Replica_open_temp_tables: 复制 SQL 线程当前打开的临时表数。 -
replica_parallel_type: 告诉复制品使用时间戳信息(LOGICAL_CLOCK)或数据库分区(DATABASE)来并行化事务。 -
replica_parallel_workers: 用于执行复制事务的应用程序线程数;当此值为 0 或 1 时,只有一个应用程序线程。NDB 集群:请参阅文档。 -
replica_pending_jobs_size_max: 持有尚未应用的事件的复制工作者队列的最大大小。 -
replica_preserve_commit_order: 确保复制工作者的所有提交按照源上的顺序发生,以在使用并行应用程序线程时保持一致性。 -
Replica_rows_last_search_algorithm_used: 此复制品最近用于定位行以进行基于行的复制(索引、表或哈希扫描)的搜索算法。 -
replica_skip_errors: 告诉复制线程在查询从提供的列表返回错误时继续复制。 -
replica_transaction_retries: 在事务由于死锁或经过的锁等待超时而失败时,复制 SQL 线程重试事务的次数,然后放弃并停止。 -
replica_type_conversions: 控制复制品上的类型转换模式。值是此列表中零个或多个元素的列表:ALL_LOSSY、ALL_NON_LOSSY。设置为空字符串以禁止源和复制品之间的类型转换。 -
replicate-do-db: 告诉复制 SQL 线程将复制限制在指定数据库中。 -
replicate-do-table: 告诉复制 SQL 线程将复制限制在指定表中。 -
replicate-ignore-db: 告诉复制 SQL 线程不要复制到指定数据库。 -
replicate-ignore-table: 告诉复制 SQL 线程不要复制到指定表。 -
replicate-rewrite-db: 更新具有与原始名称不同的数据库。 -
replicate-same-server-id: 在复制中,如果启用,则不跳过具有我们服务器 ID 的事件。 -
replicate-wild-do-table: 告诉复制 SQL 线程将复制限制在与指定通配符模式匹配的表中。 -
replicate-wild-ignore-table: 告诉复制 SQL 线程不要复制与给定通配符模式匹配的表。 -
replication_optimize_for_static_plugin_config: 针对静态插件配置的共享锁。 -
replication_sender_observe_commit_only: 半同步复制的有限回调。 -
report_host: 副本的主机名或 IP 地址,在副本注册期间报告给源。 -
report_password: 副本服务器应向源报告的任意密码;与用于复制用户帐户的密码不同。 -
report_port: 连接到副本并在副本注册期间向源报告的端口。 -
report_user: 副本服务器应向源报告的任意用户名;与用于复制用户帐户的名称不同。 -
rpl_read_size: 设置从二进制日志文件和中继日志文件中读取的最小数据量(以字节为单位)。 -
Rpl_semi_sync_master_clients: 半同步副本的数量。 -
rpl_semi_sync_master_enabled: 源上是否启用了半同步复制。 -
Rpl_semi_sync_master_net_avg_wait_time: 源等待来自副本回复的平均时间。 -
Rpl_semi_sync_master_net_wait_time: 源等待来自副本回复的总时间。 -
Rpl_semi_sync_master_net_waits: 源端等待来自副本的回复的总次数。 -
Rpl_semi_sync_master_no_times: 源端关闭半同步复制的次数。 -
Rpl_semi_sync_master_no_tx: 未成功确认的提交次数。 -
Rpl_semi_sync_master_status: 源端是否正在运行半同步复制。 -
Rpl_semi_sync_master_timefunc_failures: 调用时间函数时源端失败的次数。 -
rpl_semi_sync_master_timeout: 等待副本确认的毫秒数。 -
rpl_semi_sync_master_trace_level: 源端上的半同步复制调试跟踪级别。 -
Rpl_semi_sync_master_tx_avg_wait_time: 源端等待每个事务的平均时间。 -
Rpl_semi_sync_master_tx_wait_time: 源端等待事务的总时间。 -
Rpl_semi_sync_master_tx_waits: 源端等待事务的总次数。 -
rpl_semi_sync_master_wait_for_slave_count: 源端在继续之前必须收到每个事务的副本确认数。 -
rpl_semi_sync_master_wait_no_slave: 即使没有副本,源端是否等待超时。 -
rpl_semi_sync_master_wait_point: 副本事务接收确认的等待点。 -
Rpl_semi_sync_master_wait_pos_backtraverse: 源端等待具有比先前等待的事件更低的二进制坐标的事件的总次数。 -
Rpl_semi_sync_master_wait_sessions: 当前正在等待副本回复的会话数。 -
Rpl_semi_sync_master_yes_tx: 成功确认的提交次数。 -
rpl_semi_sync_replica_enabled: 副本上是否启用了半同步复制。 -
Rpl_semi_sync_replica_status: 复制端是否正在运行半同步复制。 -
rpl_semi_sync_replica_trace_level: 复制端半同步复制的调试跟踪级别。 -
rpl_semi_sync_slave_enabled: 复制端是否启用半同步复制。 -
Rpl_semi_sync_slave_status: 复制端是否正在运行半同步复制。 -
rpl_semi_sync_slave_trace_level: 复制端半同步复制的调试跟踪级别。 -
Rpl_semi_sync_source_clients: 半同步复制的复制端数量。 -
rpl_semi_sync_source_enabled: 源端是否启用半同步复制。 -
Rpl_semi_sync_source_net_avg_wait_time: 源端等待来自复制端回复的平均时间。 -
Rpl_semi_sync_source_net_wait_time: 源端等待复制端回复的总时间。 -
Rpl_semi_sync_source_net_waits: 源端等待复制端回复的总次数。 -
Rpl_semi_sync_source_no_times: 源端关闭半同步复制的次数。 -
Rpl_semi_sync_source_no_tx: 未成功确认的提交次数。 -
Rpl_semi_sync_source_status: 源端是否正在运行半同步复制。 -
Rpl_semi_sync_source_timefunc_failures: 调用时间函数时源端失败的次数。 -
rpl_semi_sync_source_timeout: 等待复制端确认的毫秒数。 -
rpl_semi_sync_source_trace_level: 源端半同步复制的调试跟踪级别。 -
Rpl_semi_sync_source_tx_avg_wait_time: 源端等待每个事务的平均时间。 -
Rpl_semi_sync_source_tx_wait_time: 源端等待事务的总时间。 -
Rpl_semi_sync_source_tx_waits: 源等待事务的总次数。 -
rpl_semi_sync_source_wait_for_replica_count: 在继续之前,源必须在每个事务中收到的副本确认数。 -
rpl_semi_sync_source_wait_no_replica: 源是否在没有副本的情况下等待超时。 -
rpl_semi_sync_source_wait_point: 等待副本事务接收确认的等待点��� -
Rpl_semi_sync_source_wait_pos_backtraverse: 源等待具有比先前等待的事件更低的二进制坐标的事件的总次数。 -
Rpl_semi_sync_source_wait_sessions: 当前正在等待副本回复的会话数。 -
Rpl_semi_sync_source_yes_tx: 成功确认的提交次数。 -
rpl_stop_replica_timeout: STOP REPLICA 等待超时的秒数。 -
rpl_stop_slave_timeout: STOP REPLICA 或 STOP SLAVE 等待超时的秒数。 -
server_uuid: 服务器的全局唯一 ID,在服务器启动时自动生成。 -
show-replica-auth-info: 在此源上的 SHOW REPLICAS 中显示用户名和密码。 -
show-slave-auth-info: 在此源上的 SHOW REPLICAS 和 SHOW SLAVE HOSTS 中显示用户名和密码。 -
skip-replica-start: 如果设置,当副本服务器启动时不会自动启动复制。 -
skip-slave-start: 如果设置,当副本服务器启动时不会自动启动复制。 -
slave-skip-errors: 当查询从提供的列表返回错误时,告诉复制线程继续复制。 -
slave_checkpoint_group: 多线程副本处理的最大事务数,在调用检查点操作以更新进度状态之前。不受 NDB Cluster 支持。 -
slave_checkpoint_period: 在此毫秒数后更新多线程副本的进度状态并将中继日志信息刷新到磁盘。NDB Cluster 不支持。 -
slave_compressed_protocol: 使用源/副本协议的压缩。 -
slave_exec_mode: 允许在IDEMPOTENT模式(键和一些其他错误被抑制)和STRICT模式之间切换复制线程;STRICT模式是默认的,除了 NDB Cluster,始终使用IDEMPOTENT。 -
slave_load_tmpdir: 当复制LOAD DATA语句时,副本应将临时文件放置的位置。 -
slave_max_allowed_packet: 从复制源服务器发送到副本的数据包的最大大小(以字节为单位);覆盖max_allowed_packet。 -
slave_net_timeout: 等待源/副本连接中更多数据的秒数,超时前中止读取。 -
Slave_open_temp_tables: 复制 SQL 线程当前打开的临时表数。 -
slave_parallel_type: 告诉副本使用时间戳信息(LOGICAL_CLOCK)或数据库分区(DATABASE)来并行化事务。 -
slave_parallel_workers: 用于并行执行复制事务的应用程序线程数;0 或 1 禁用副本多线程。NDB Cluster:请参阅文档。 -
slave_pending_jobs_size_max: 持有尚未应用的事件的副本工作线程队列的最大大小。 -
slave_preserve_commit_order: 确保副本工作线程的所有提交按照源上的顺序发生,以保持一致性,当使用并行应用程序线程时。 -
Slave_rows_last_search_algorithm_used: 此副本最近用于定位行以进行基于行的复制(索引、表或哈希扫描)的搜索算法。 -
slave_rows_search_algorithms: 确定用于副本更新批处理的搜索算法。从此列表中选择任意 2 或 3 个:INDEX_SEARCH、TABLE_SCAN、HASH_SCAN。 -
slave_transaction_retries: 在复制 SQL 线程在死锁或经过的锁等待超时失败的情况下,重试事务的次数,然后放弃并停止。 -
slave_type_conversions: 控制副本上的类型转换模式。 值是以下列表中的零个或多个元素:ALL_LOSSY,ALL_NON_LOSSY。 将其设置为空字符串以禁止源和副本之间的类型转换。 -
sql_log_bin: 控制当前会话的二进制日志记录。 -
sql_replica_skip_counter: 副本应跳过的源事件数。 与 GTID 复制不兼容。 -
sql_slave_skip_counter: 副本应跳过的源事件数。 与 GTID 复制不兼容。 -
sync_master_info: 每第#个事件后同步源信息。 -
sync_relay_log: 每第#个事件后将 relay 日志同步到磁盘。 -
sync_relay_log_info: 每第#个事件后将 relay.info 文件同步到磁盘。 -
sync_source_info: 每第#个事件后同步源信息。 -
terminology_use_previous: 在不兼容更改的版本之前使用术语。 -
transaction_write_set_extraction: 定义在事务期间提取的写入哈希的算法。
对于所有与mysqld一起使用的命令行选项、系统变量和状态变量的列表,请参阅 Section 7.1.4, “Server Option, System Variable, and Status Variable Reference”。
二进制日志选项和变量
以下列表中的命令行选项和系统变量与二进制日志相关。 Section 19.1.6.4, “Binary Logging Options and Variables”提供了有关与二进制日志相关的选项和变量的更详细信息。 有关二进制日志的其他一般信息,请参阅 Section 7.4.4, “The Binary Log”。
-
binlog-checksum: 启用或禁用二进制日志校验和。 -
binlog-do-db: 限制二进制日志记录到特定数据库。 -
binlog-ignore-db: 告诉源不要将对给定数据库的更新写入二进制日志。 -
binlog-row-event-max-size: 二进制日志最大事件大小。 -
Binlog_cache_disk_use: 使用临时文件而不是二进制日志缓存的事务数。 -
binlog_cache_size: 在事务期间保存 SQL 语句以用于二进制日志的缓存大小。 -
Binlog_cache_use: 使用临时二进制日志缓存的事务数。 -
binlog_checksum: 启用或禁用二进制日志校验和。 -
binlog_direct_non_transactional_updates: 导致使用语句格式对非事务引擎进行的更新直接写入二进制日志。在使用之前请查看文档。 -
binlog_encryption: 在此服务器上为二进制日志文件和中继日志文件启用加密。 -
binlog_error_action: 控制服务器无法写入二进制日志时会发生什么。 -
binlog_expire_logs_auto_purge: 控制二进制日志文件的自动清理;当启用时,可以通过将 binlog_expire_logs_seconds 和 expire_logs_days 都设置为 0 来覆盖。 -
binlog_expire_logs_seconds: 在这么多秒后清理二进制日志。 -
binlog_format: 指定二进制日志的格式。 -
binlog_group_commit_sync_delay: 设置在将事务同步到磁盘之前等待的微秒数。 -
binlog_group_commit_sync_no_delay_count: 设置在中止由 binlog_group_commit_sync_delay 指定的当前延迟之前等待的最大事务数。 -
binlog_gtid_simple_recovery: 控制在 GTID 恢复期间如何迭代二进制日志。 -
binlog_max_flush_queue_time: 在刷新到二进制日志之前读取事务的时间。 -
binlog_order_commits: 是否按照写入二进制日志的顺序提交。 -
binlog_rotate_encryption_master_key_at_startup: 在服务器启动时旋转二进制日志主密钥。 -
binlog_row_image: 记录行更改时使用完整或最小图像。 -
binlog_row_metadata: 在使用基于行的日志记录时,记录所有或仅最小的与表相关的元数据到二进制日志中。 -
binlog_row_value_options: 启用基于行复制的部分 JSON 更新的二进制日志记录。 -
binlog_rows_query_log_events: 启用时,在使用基于行的日志记录时启用行查询日志事件的记录。默认情况下禁用。在为早于 5.6 版本的副本/读取器生成日志时不要启用。 -
Binlog_stmt_cache_disk_use: 使用临时文件而不是二进制日志语句缓存的非事务语句数量。 -
binlog_stmt_cache_size: 在事务期间为二进制日志保留非事务语句的缓存大小。 -
Binlog_stmt_cache_use: 使用临时二进制日志语句缓存的语句数量。 -
binlog_transaction_compression: 启用二进制日志文件中事务负载的压缩。 -
binlog_transaction_compression_level_zstd: 二进制日志文件中事务负载的压缩级别。 -
binlog_transaction_dependency_history_size: 用于查找最后更新某行的事务的行哈希数量。 -
binlog_transaction_dependency_tracking: 用于评估哪些事务可以由副本的多线程应用程序并行执行的依赖信息来源(提交时间戳或事务写入集)。 -
Com_show_binlog_events: SHOW BINLOG EVENTS 语句的计数。 -
Com_show_binlogs: SHOW BINLOGS 语句的计数。 -
log-bin: 二进制日志文件的基本名称。 -
log-bin-index: 二进制日志索引文件的名称。 -
log_bin: 是否启用二进制日志。 -
log_bin_basename: 二进制日志文件的路径和基本名称。 -
log_bin_use_v1_row_events: 服务器是否使用版本 1 的二进制日志行事件。 -
log_replica_updates: 副本是否应将其复制 SQL 线程执行的更新记录到自己的二进制日志中。 -
log_slave_updates: 副本是否应将其复制 SQL 线程执行的更新记录到自己的二进制日志中。 -
master_verify_checksum: 使源在从二进制日志读取时检查校验和。 -
max-binlog-dump-events: mysql-test 用于调试和测试复制的选项。 -
max_binlog_cache_size: 可用于限制用于缓存多语句事务的总字节大小。 -
max_binlog_size: 当大小超过此值时,二进制日志会自动轮换。 -
max_binlog_stmt_cache_size: 可用于限制在事务期间缓存所有非事务语句的总大小。 -
replica_sql_verify_checksum: 使副本在从中继日志读取时检查校验和。 -
slave-sql-verify-checksum: 使副本在从中继日志读取时检查校验和。 -
slave_sql_verify_checksum: 使副本在从中继日志读取时检查校验和。 -
source_verify_checksum: 使源在从二进制日志读取时检查校验和。 -
sporadic-binlog-dump-fail: mysql-test 用于调试和测试复制的选项。 -
sync_binlog: 每第#个事件后将二进制日志同步刷新到磁盘。
对于所有与mysqld一起使用的命令行选项、系统和状态变量的列表,请参见第 7.1.4 节,“服务器选项、系统变量和状态变量参考”。
原文:
dev.mysql.com/doc/refman/8.0/en/replication-options-source.html
19.1.6.2 复制源选项和变量
本节描述了您可以在复制源服务器上使用的服务器选项和系统变量。您可以在命令行或选项文件中指定选项。您可以使用 SET 指定系统变量值。
在源和每个副本上,您必须设置 server_id 系统变量以建立唯一的复制 ID。对于每个服务器,您应该选择一个在 1 到 2³² − 1 范围内的唯一正整数,并且每个 ID 必须与复制拓扑中任何其他源或副本使用的任何其他 ID 不同。例如:server-id=3。
用于控制二进制日志记录的源上使用的选项,请参阅第 19.1.6.4 节,“二进制日志选项和变量”。
复制源服务器的启动选项
以下列表描述了用于控制复制源服务器的启动选项。复制相关的系统变量将在本节后面讨论。
-
--show-replica-auth-info命令行格式 --show-replica-auth-info[={OFF|ON}]引入版本 8.0.26 类型 布尔 默认值 OFF从 MySQL 8.0.26 开始,请使用
--show-replica-auth-info,在 MySQL 8.0.26 之前,请使用--show-slave-auth-info。这两个选项具有相同的效果。这些选项在源上显示复制用户名和密码在SHOW REPLICAS(或在 MySQL 8.0.22 之前,SHOW SLAVE HOSTS)的输出中,用于使用--report-user和--report-password选项启动的副本。 -
--show-slave-auth-info命令行格式 --show-slave-auth-info[={OFF|ON}]已弃用 8.0.26 类型 布尔 默认值 OFF在 MySQL 8.0.26 之前,请使用此选项,而不是
--show-replica-auth-info。这两个选项具有相同的效果。
复制源服务器上使用的系统变量
以下系统变量用于或由复制源服务器使用:
-
auto_increment_increment命令行格式 --auto-increment-increment=#系统变量 auto_increment_increment范围 全局,会话 动态 是 SET_VAR提示适用是 类型 整数 默认值 1最小值 1最大值 65535auto_increment_increment和auto_increment_offset用于循环(源到源)复制,并可用于控制AUTO_INCREMENT列的操作。这两个变量都有全局和会话值,每个变量的值都可以是介于 1 到 65,535 之间的整数。将这两个变量中的任何一个的值设置为 0 会使其值改为 1。尝试将这两个变量中的任何一个的值设置为大于 65,535 或小于 0 的整数会使其值改为 65,535。尝试将auto_increment_increment或auto_increment_offset的值设置为非整数值会产生错误,并且变量的实际值保持不变。注意
auto_increment_increment也支持用于NDB表。截至 MySQL 8.0.18,设置此系统变量的会话值不再是受限制的操作。
当在服务器上启动组复制时,
auto_increment_increment的值会更改为group_replication_auto_increment_increment的值,默认为 7,并且auto_increment_offset的值会更改为服务器 ID。当停止组复制时,这些更改会被还原。只有当auto_increment_increment和auto_increment_offset的默认值都为 1 时,才会进行这些更改和还原。如果它们的值已经从默认值修改过,则组复制不会更改它们。从 MySQL 8.0 开始,当组复制处于单主模式时,即只有一个服务器写入时,系统变量也不会被修改。auto_increment_increment和auto_increment_offset影响AUTO_INCREMENT列的行为如下:-
auto_increment_increment控制连续列值之间的间隔。例如:mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 1 | | auto_increment_offset | 1 | +--------------------------+-------+ 2 rows in set (0.00 sec) mysql> CREATE TABLE autoinc1 -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY); Query OK, 0 rows affected (0.04 sec) mysql> SET @@auto_increment_increment=10; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 1 | +--------------------------+-------+ 2 rows in set (0.01 sec) mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT col FROM autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | +-----+ 4 rows in set (0.00 sec) -
auto_increment_offset确定AUTO_INCREMENT列值的起始点。考虑以下情况,假设这些语句在与auto_increment_increment描述中给出的示例相同的会话中执行:mysql> SET @@auto_increment_offset=5; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 5 | +--------------------------+-------+ 2 rows in set (0.00 sec) mysql> CREATE TABLE autoinc2 -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY); Query OK, 0 rows affected (0.06 sec) mysql> INSERT INTO autoinc2 VALUES (NULL), (NULL), (NULL), (NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT col FROM autoinc2; +-----+ | col | +-----+ | 5 | | 15 | | 25 | | 35 | +-----+ 4 rows in set (0.02 sec)当
auto_increment_offset的值大于auto_increment_increment的值时,将忽略auto_increment_offset的值。
如果这两个变量中的任何一个被更改,然后新行被插入到包含
AUTO_INCREMENT列的表中,结果可能看起来令人费解,因为AUTO_INCREMENT值的系列是在不考虑列中已经存在的任何值的情况下计算的,并且插入的下一个值是系列中大于AUTO_INCREMENT列中最大现有值的最小值。该系列的计算方式如下:auto_increment_offset+N×auto_increment_increment其中*
N*是系列[1, 2, 3, ...]中的正整数值。例如:mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 5 | +--------------------------+-------+ 2 rows in set (0.00 sec) mysql> SELECT col FROM autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | +-----+ 4 rows in set (0.00 sec) mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT col FROM autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | | 35 | | 45 | | 55 | | 65 | +-----+ 8 rows in set (0.00 sec)所示的
auto_increment_increment和auto_increment_offset的值生成系列 5 +N× 10,即[5, 15, 25, 35, 45, ...]。在INSERT之前col列中存在的最高值为 31,AUTO_INCREMENT系列中的下一个可用值为 35,因此col的插入值从该点开始,并且查询的结果如SELECT中所示。不可能将这两个变量的影响限制在单个表中;这些变量控制 MySQL 服务器上所有表中的所有
AUTO_INCREMENT列的行为。如果设置了任一变量的全局值,则其影响将持续,直到更改全局值或通过设置会话值覆盖,或者直到mysqld被重新启动。如果设置了本地值,则新值会影响当前用户在会话期间插入新行的所有表的AUTO_INCREMENT列,除非在该会话期间更改了这些值。auto_increment_increment的默认值为 1。请参阅第 19.5.1.1 节,“复制和 AUTO_INCREMENT”。 -
-
auto_increment_offset命令行格式 --auto-increment-offset=#系统变量 auto_increment_offset作用范围 全局,会话 动态 是 SET_VAR提示适用是 类型 整数 默认值 1最小值 1最大值 65535此变量的默认值为 1。如果将其保留为默认值,并且在多主模式下在服务器上启动组复制,则将其更改为服务器 ID。有关更多信息,请参阅
auto_increment_increment的描述。注意
auto_increment_offset也支持用于与NDB表。截至 MySQL 8.0.18,设置此系统变量的会话值不再是受限制的操作。
-
immediate_server_version引入版本 8.0.14 系统变量 immediate_server_version作用范围 会话 动态 是 SET_VAR提示适用否 类型 整数 默认值 999999最小值 0最大值 999999用于复制的内部使用。此会话系统变量保存了复制拓扑中作为直接源的 MySQL 服务器发布号(例如,MySQL 8.0.14 服务器实例的
80014)。如果此直接服务器处于不支持会话系统变量的发布中,则变量的值设置为 0(UNKNOWN_SERVER_VERSION)。此变量的值从源复制到副本。有了这些信息,副本可以正确处理源自较旧发布的源的数据,通过识别在涉及的发布之间发生的语法更改或语义更改,并适当处理这些更改。此信息还可用于组复制环境,其中一个或多个复制组成员的发布版本比其他成员新。变量的值可以在每个事务的二进制日志中查看(作为
Gtid_log_event的一部分,或者如果服务器上未使用 GTID,则作为Anonymous_gtid_log_event),并且在调试跨版本复制问题时可能会有所帮助。设置此系统变量的会话值是受限制的操作。会话用户必须具有
REPLICATION_APPLIER权限(请参阅第 19.3.3 节,“复制权限检查”),或具有足够权限设置受限制会话变量的权限(请参阅第 7.1.9.1 节,“系统变量权限”)。但是,请注意,该变量不是供用户设置的;它是由复制基础设施自动设置的。 -
original_server_version引入版本 8.0.14 系统变量 original_server_version范围 会话 动态 是 SET_VAR提示适用否 类型 整数 默认值 999999最小值 0最大值 999999用于复制的内部使用。此会话系统变量保存了事务最初提交的 MySQL Server 版本号(例如,对于 MySQL 8.0.14 服务器实例,为
80014)。如果此原始服务器的版本不支持会话系统变量,则变量的值将设置为 0(UNKNOWN_SERVER_VERSION)。请注意,当原始服务器设置了版本号时,如果立即服务器或复制拓扑中的任何其他中介服务器不支持会话系统变量,则变量的值将重置为 0,并且不会复制其值。该变量的值设置和使用方式与
immediate_server_version系统变量相同。如果变量的值与immediate_server_version系统变量的值相同,则只记录后者在二进制日志中,并指示原始服务器版本相同。在 Group Replication 环境中,查看更改日志事件,这些事件是每个组成员在新成员加入组时排队的特殊事务,都带有排队事务的组成员的服务器版本标记。这确保了加入成员知道原始捐赠者的服务器版本。因为特定视图更改的排队事件在所有成员上具有相同的 GTID,所以在这种情况下,相同的 GTID 实例可能具有不同的原始服务器版本。
设置此系统变量的会话值是受限制的操作。会话用户必须具有
REPLICATION_APPLIER权限(参见第 19.3.3 节,“复制权限检查”),或具有足够权限设置受限制会话变量的权限(参见第 7.1.9.1 节,“系统变量权限”)。但是,请注意,该变量不是供用户设置的;它是由复制基础设施自动设置的。 -
rpl_semi_sync_master_enabled命令行格式 --rpl-semi-sync-master-enabled[={OFF|ON}]系统变量 rpl_semi_sync_master_enabled作用域 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF控制源服务器上是否启用半同步复制。要启用或禁用插件,请将此变量设置为
ON或OFF(或分别为 1 或 0)。默认值为OFF。仅当源端半同步复制插件已安装��才可用。
-
rpl_semi_sync_master_timeout命令行格式 --rpl-semi-sync-master-timeout=#系统变量 rpl_semi_sync_master_timeout作用域 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 10000最小值 0最大值 4294967295单位 毫秒 以毫秒为单位的值,控制源在提交等待来自副本的确认之前超时并回滚到异步复制的时间。默认值为 10000(10 秒)。
仅当源端半同步复制插件已安装时才可用。
-
rpl_semi_sync_master_trace_level命令行格式 --rpl-semi-sync-master-trace-level=#系统变量 rpl_semi_sync_master_trace_level作用域 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 32最小值 0最大值 4294967295源服务器上的半同步复制调试跟踪级别。定义了四个级别:
-
1 = 一般级别(例如,时间函数失败)
-
16 = 详细级别(更详细的信息)
-
32 = 网络等待级别(有关网络等待的更多信息)
-
64 = 函数级别(有关函数进入和退出的信息)
仅当源端半同步复制插件已安装时才可用此变量。
-
-
rpl_semi_sync_master_wait_for_slave_count命令行格式 --rpl-semi-sync-master-wait-for-slave-count=#系统变量 rpl_semi_sync_master_wait_for_slave_count范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 1最小值 1最大值 65535源必须在继续之前每个事务收到的副本确认数。默认情况下,
rpl_semi_sync_master_wait_for_slave_count为1,这意味着在收到单个副本确认后,半同步复制会继续进行。对于此变量的小值性能最佳。例如,如果
rpl_semi_sync_master_wait_for_slave_count为2,则在超时期限配置为rpl_semi_sync_master_timeout之前,必须有 2 个副本确认接收事务,半同步复制才能继续。如果在超时期间较少的副本确认接收事务,则源会恢复到正常复制。注意
此行为还取决于
rpl_semi_sync_master_wait_no_slave仅当源端半同步复制插件已安装时才可用此变量。
-
rpl_semi_sync_master_wait_no_slave命令行格式 --rpl-semi-sync-master-wait-no-slave[={OFF|ON}]系统变量 rpl_semi_sync_master_wait_no_slave范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 ON控制源是否等待由
rpl_semi_sync_master_timeout配置的超时期限到期,即使在超时期间副本计数降至少于rpl_semi_sync_master_wait_for_slave_count配置的副本数。当
rpl_semi_sync_master_wait_no_slave的值为ON(默认)时,在超时期间允许副本计数降至少于rpl_semi_sync_master_wait_for_slave_count。只要足够多的副本在超时期限到期之前确认事务,半同步复制就会继续。当
rpl_semi_sync_master_wait_no_slave的值为OFF时,如果在任何时候副本计数降至少于rpl_semi_sync_master_wait_for_slave_count中配置的数量,在由rpl_semi_sync_master_timeout配置的超时期间内,源将恢复到正常复制。此变量仅在安装了源端半同步复制插件时才可用。
-
rpl_semi_sync_master_wait_point命令行格式 --rpl-semi-sync-master-wait-point=value系统变量 rpl_semi_sync_master_wait_point范围 全局 动态 是 SET_VAR提示适用否 类型 枚举 默认数值 AFTER_SYNC有效数值 AFTER_SYNC``AFTER_COMMIT此变量控制半同步复制源服务器在向提交事务的客户端返回状态之前等待副本确认接收事务的点。这些值是允许的:
-
AFTER_SYNC(默认):源将每个事务写入其二进制日志和副本,并将二进制日志同步到磁盘。源在同步后等待副本确认接收事务。在收到确认后,源将事务提交给存储引擎并向客户端返回结果,然后客户端可以继续。 -
AFTER_COMMIT:源将每个事务写入其二进制日志和副本,同步二进制日志,并提交事务给存储引擎。源在提交后等待副本确认接收事务。在收到确认后,源向客户端返回结果,然后客户端可以继续。
这些设置的复制特性有以下不同:
-
使用
AFTER_SYNC,所有客户端同时看到已提交的事务:在副本确认并在源上提交给存储引擎之后。因此,所有客户端在源上看到相同的数据。在源故障的情况下,所有在源上提交的事务都已复制到副本(保存到其中继日志)。源服务器意外退出并故障转移至副本是无损的,因为副本是最新的。但请注意,在这种情况下源服务器不能重新启动,必须被丢弃,因为其二进制日志可能包含未提交的事务,在二进制日志恢复后在外部化后会与副本发生冲突。
-
使用
AFTER_COMMIT,发出事务的客户端只有在服务器提交给存储引擎并接收到副本确认后才会收到返回状态。在提交之后和副本确认之前,其他客户端可能会在提交客户端之前看到已提交的事务。如果出现问题导致副本未能处理事务,则在源服务器意外退出并故障转移至副本时,这些客户端可能会看到相对于在源服务器上看到的数据有所丢失。
仅当源端半同步复制插件已安装时才可用此变量。
在 MySQL 5.7 中添加了
rpl_semi_sync_master_wait_point后,由于它增加了半同步接口版本,创建了一个版本兼容性约束:MySQL 5.7 及更高版本的服务器不与旧版本的半同步复制插件一起工作,反之亦然。 -
-
rpl_semi_sync_source_enabled命令行格式 --rpl-semi-sync-source-enabled[={OFF|ON}]引入版本 8.0.26 系统变量 rpl_semi_sync_source_enabled作用域 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF当在副本上安装了
rpl_semi_sync_source(semisync_source.so库)插件以设置半同步复制时,rpl_semi_sync_source_enabled可用。如果安装了rpl_semi_sync_master插件(semisync_master.so库),则可用rpl_semi_sync_master_enabled。rpl_semi_sync_source_enabled控制源服务器上是否启用半同步复制。要启用或禁用插件,请将此变量设置为ON或OFF(或分别设置为 1 或 0)。默认值为OFF。 -
rpl_semi_sync_source_timeout命令行格式 --rpl-semi-sync-source-timeout=#引入版本 8.0.26 系统变量 rpl_semi_sync_source_timeout作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 10000最小值 0最大值 4294967295单位 毫秒 rpl_semi_sync_source_timeout在安装了rpl_semi_sync_source(semisync_source.so库)插件的复制品上设置半同步复制时可用。如果安装了rpl_semi_sync_master插件(semisync_master.so库),则可用rpl_semi_sync_master_timeout。rpl_semi_sync_source_timeout控制源在提交等待来自复制品的确认之前等待的时间,超时后将回滚到异步复制。该值以毫秒为单位指定,默认值为 10000(10 秒)。 -
rpl_semi_sync_source_trace_level命令行格式 --rpl-semi-sync-source-trace-level=#引入版本 8.0.26 系统变量 rpl_semi_sync_source_trace_level作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 32最小值 0最大值 4294967295rpl_semi_sync_source_trace_level在安装了rpl_semi_sync_source(semisync_source.so库)插件的复制品上设置半同步复制时可用。如果安装了rpl_semi_sync_master插件(semisync_master.so库),则可用rpl_semi_sync_master_trace_level。rpl_semi_sync_source_trace_level指定源服务器上半同步复制的调试跟踪级别。定义了四个级别:-
1 = 一般级别(例如,时间函数失败)
-
16 = 详细级别(更详细的信息)
-
32 = 网络等待级别(有关网络等待的更多信息)
-
64 = 函数级别(有关函数进入和退出的信息)
-
-
rpl_semi_sync_source_wait_for_replica_count命令行格式 --rpl-semi-sync-source-wait-for-replica-count=#引入版本 8.0.26 系统变量 rpl_semi_sync_source_wait_for_replica_count作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 1最小值 1最大值 65535当在副本上安装了
rpl_semi_sync_source(semisync_source.so库) 插件以设置半同步复制时,rpl_semi_sync_source_wait_for_replica_count就可用。如果安装了rpl_semi_sync_master插件 (semisync_master.so库),则可以使用rpl_semi_sync_master_wait_for_slave_count。rpl_semi_sync_source_wait_for_replica_count指定源在继续之前必须收到每个事务的副本确认数。默认情况下,rpl_semi_sync_source_wait_for_replica_count是1,意味着在收到单个副本确认后,半同步复制会继续进行。对于此变量的小值,性能最佳。例如,如果
rpl_semi_sync_source_wait_for_replica_count是2,那么在半同步复制的超时期间内,必须有 2 个副本确认接收事务,才能继续进行半同步复制。如果在超时期间内有更少的副本确认接收事务,则源将恢复为正常复制。注意
这种行为还取决于
rpl_semi_sync_source_wait_no_replica。 -
rpl_semi_sync_source_wait_no_replica命令行格式 --rpl-semi-sync-source-wait-no-replica[={OFF|ON}]引入版本 8.0.26 系统变量 rpl_semi_sync_source_wait_no_replica作用范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 ON当在复制品上安装了
rpl_semi_sync_source(semisync_source.so库)插件以设置半同步复制时,可以使用rpl_semi_sync_source_wait_no_replica。如果安装了rpl_semi_sync_master插件(semisync_master.so库),则可以使用rpl_semi_sync_source_wait_no_replica控制源端是否等待由rpl_semi_sync_source_timeout配置的超时期限到期,即使在超时期间复制品数量少于rpl_semi_sync_source_wait_for_replica_count配置的数量。当
rpl_semi_sync_source_wait_no_replica的值为ON(默认值)时,允许在超时期间复制品数量少于rpl_semi_sync_source_wait_for_replica_count。只要足够多的复制品在超时期限到期前确认事务,半同步复制就会继续。当
rpl_semi_sync_source_wait_no_replica的值为OFF时,如果在由rpl_semi_sync_source_timeout配置的超时期间内任何时候复制品数量少于rpl_semi_sync_source_wait_for_replica_count配置的数量,源端将恢复为正常复制。 -
rpl_semi_sync_source_wait_point命令行格式 --rpl-semi-sync-source-wait-point=value引入版本 8.0.26 系统变量 rpl_semi_sync_source_wait_point作用范围 全局 动态 是 SET_VAR提示适用否 类型 枚举 默认数值 AFTER_SYNC有效数值 AFTER_SYNC``AFTER_COMMIT当在复制品上安装了
rpl_semi_sync_source(semisync_source.so库)插件以设置半同步复制时,可以使用rpl_semi_sync_source_wait_point。如果安装了rpl_semi_sync_master插件(semisync_master.so库),则可以使用rpl_semi_sync_master_wait_point。rpl_semi_sync_source_wait_point控制半同步复制源服务器在返回提交事务的客户端状态之前等待副本确认事务接收的点。允许这些值:-
AFTER_SYNC(默认):源将每个事务写入其二进制日志和副本,并将二进制日志同步到磁盘。源在同步后等待副本确认事务接收。在收到确认后,源将事务提交到存储引擎并向客户端返回结果,然后客户端可以继续。 -
AFTER_COMMIT:源将每个事务写入其二进制日志和副本,同步二进制日志,并提交事务到存储引擎。源在提交后等待副本确认事务接收。在收到确认后,源向客户端返回结果,然后客户端可以继续。
这些设置的复制特性有以下不同:
-
使用
AFTER_SYNC,所有客户端同时看到已提交的事务:在副本确认并在源上提交到存储引擎之后。因此,所有客户端在源上看到相同的数据。在源故障的情况下,所有在源上提交的事务已经被复制到副本(保存在其中继日志中)。源服务器意外退出并故障转移到副本是无损失的,因为副本是最新的。但请注意,在这种情况下源不能重新启动,必须被丢弃,因为其二进制日志可能包含未提交的事务,在二进制日志恢复后会与副本在外部化时发生冲突。
-
使用
AFTER_COMMIT,发出事务的客户端只有在服务器提交到存储引擎并接收副本确认后才会收到返回状态。在提交后和副本确认前,其他客户端可以在提交客户端之前看到已提交的事务。如果副本未处理事务导致出现问题,那么在源服务器意外退出并故障转移到副本的情况下,这些客户端可能会看到相对于在源上看到的数据有所丢失。
-
原文:
dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html
19.1.6.3 副本服务器选项和变量
本节介绍了适用于副本服务器的服务器选项和系统变量,包括以下内容:
-
副本服务器的启动选项
-
副本服务器上使用的系统变量
在命令行上或在选项文件中指定选项。许多选项可以在服务器运行时通过使用CHANGE REPLICATION SOURCE TO语句(从 MySQL 8.0.23 开始)或CHANGE MASTER TO语句(在 MySQL 8.0.23 之前)进行设置。使用SET语法指定系统变量值。
服务器 ID。 在源和每个副本上,您必须设置server_id系统变量以建立范围从 1 到 2³² − 1 的唯一复制 ID。 “唯一”意味着每个 ID 必须与复制拓扑中任何其他源或副本正在使用的任何其他 ID 不同。示例my.cnf文件:
[mysqld]
server-id=3
副本服务器的启动选项
本节介绍了控制副本服务器启动选项的内容。其中许多选项可以在服务器运行时通过使用CHANGE REPLICATION SOURCE TO语句(从 MySQL 8.0.23 开始)或CHANGE MASTER TO语句(在 MySQL 8.0.23 之前)进行设置。其他选项,如--replicate-*选项,只能在副本服务器启动时设置。有关复制相关的系统变量将在本节后面讨论。
-
--master-info-file=*file_name*命令行格式 --master-info-file=file_name已弃用 8.0.18 类型 文件名 默认值 master.info此选项的使用现已不推荐。如果设置了
master_info_repository=FILE,则用于设置复制品连接元数据存储库的文件名。--master-info-file和master_info_repository系统变量的使用已不推荐,因为使用文件作为连接元数据存储库已被崩溃安全表取代。有关连接元数据存储库的信息,请参阅 Section 19.2.4.2, “Replication Metadata Repositories”。 -
--master-retry-count=*count*命令行格式 --master-retry-count=#已弃用 是 类型 整数 默认值 86400最小值 0最大值(64 位平台) 18446744073709551615最大值(32 位平台) 4294967295复制品在放弃之前尝试重新连接到源的次数。默认值为 86400 次。值为 0 表示“无限”,复制品会永远尝试连接。当复制品在未从源接收数据或心跳信号的情况下达到连接超时(由
replica_net_timeout或slave_net_timeout系统变量指定)时,会触发重新连接尝试。重新连接尝试的间隔由CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO语句的SOURCE_CONNECT_RETRY|MASTER_CONNECT_RETRY选项设置(默认为每 60 秒一次)。此选项已弃用;预计将在未来的 MySQL 版本中删除。请改用
CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO语句的SOURCE_RETRY_COUNT|MASTER_RETRY_COUNT选项。 -
--max-relay-log-size=*size*命令行格式 --max-relay-log-size=#系统变量 max_relay_log_size范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 0最小值 0最大值 1073741824单位 字节 块大小 4096服务器自动轮换中继日志文件的大小。如果此值非零,则当中继日志大小超过此值时,中继日志会自动轮换。如果此值为零(默认值),则中继日志轮换发生的大小由
max_binlog_size的值确定。更多信息,请参阅 Section 19.2.4.1, “The Relay Log”。 -
--relay-log-purge={0|1}命令行格式 --relay-log-purge[={OFF|ON}]系统变量 relay_log_purge作用范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 ON禁用或启用中继日志在不再需要时自动清除。默认值为 1(启用)。这是一个可以通过
SET GLOBAL relay_log_purge = *N*动态更改的全局变量。在启用--relay-log-recovery选项时禁用中继日志清除会存在数据一致性风险,因此不具有崩溃安全性。 -
--relay-log-space-limit=*size*命令行格式 --relay-log-space-limit=#系统变量 relay_log_space_limit作用范围 全局 动态 否 SET_VAR提示适用否 类型 整数 默认值 0最小值 0最大值 18446744073709551615单位 字节 此选项将在副本上的所有中继日志的总大小上设置一个上限,以字节为单位。值为 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*命令行格式 --replicate-do-db=name类型 字符串 使用数据库名称创建一个复制过滤器。也可以使用
CHANGE REPLICATION FILTER REPLICATE_DO_DB来创建这样的过滤器。此选项支持通道特定的复制过滤器,使多源副本可以为不同来源使用特定的过滤器。要在名为*
channel_1*的通道上配置特定于通道的复制过滤器,请使用--replicate-do-db:*channel_1*:*db_name*。在这种情况下,第一个冒号被解释为分隔符,后续冒号为字面冒号。有关更多信息,请参见第 19.2.5.4 节,“基于通道的复制过滤器”。注意
全局复制过滤器不能用于配置为组复制的 MySQL 服务器实例,因为在某些服务器上过滤事务会使组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,其中一个组成员同时充当到组外源的副本。它们不能用于
group_replication_applier或group_replication_recovery通道。这个复制过滤器的精确效果取决于是使用基于语句还是基于行的复制。
基于语句的复制。 告诉复制 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 节,“服务器如何评估复制过滤规则”。注意
此选项对复制的影响与
--binlog-do-db对二进制日志记录的影响方式相同,并且复制格式对--replicate-do-db对复制行为的影响与日志格式对--binlog-do-db行为的影响相同。此选项对
BEGIN、COMMIT或ROLLBACK语句无效。 -
--replicate-ignore-db=*db_name*命令行格式 --replicate-ignore-db=name类型 字符串 使用数据库名称创建一个复制过滤器。也可以使用
CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB来创建这样的过滤器。此选项支持通道特定的复制过滤器,使多源复制副本可以为不同源使用特定过滤器。要在名为*
channel_1*的通道上配置通道特定的复制过滤器,请使用--replicate-ignore-db:*channel_1*:*db_name*。在这种情况下,第一个冒号被解释为分隔符,后续冒号为字面冒号。有关更多信息,请参见 Section 19.2.5.4, “Replication Channel Based Filters”。注意
全局复制过滤器不能在配置为组复制的 MySQL 服务器实例上使用,因为在某些服务器上过滤事务会导致组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,其中一个组成员同时充当了组外源的副本。它们不能用于
group_replication_applier或group_replication_recovery通道。要忽略多个数据库,请多次使用此选项,每个数据库一次。因为数据库名称可以包含逗号,如果提供逗号分隔的列表,则将其视为单个数据库的名称。
与
--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数据库中的所有表的更改都被副本忽略。如果您正在使用跨数据库更新并且不希望这些更新被复制,请不要使用此选项。请参阅 Section 19.2.5, “How Servers Evaluate Replication Filtering Rules”。
如果需要跨数据库更新正常工作,请改用
--replicate-wild-ignore-table=*db_name*.%。请参阅 Section 19.2.5, “How Servers Evaluate Replication Filtering Rules”。注意
此选项对复制的影响方式与
--binlog-ignore-db对二进制日志的影响方式相同,并且复制格式对--replicate-ignore-db对复制行为的影响与日志格式对--binlog-ignore-db行为的影响相同。此选项对
BEGIN、COMMIT或ROLLBACK语句没有影响。 -
--replicate-do-table=*db_name.tbl_name*命令行格式 --replicate-do-table=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 节,“基于复制通道的过滤器”。注意
全局复制过滤器不能用于配置为组复制的 MySQL 服务器实例,因为在某些服务器上过滤事务会导致组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,其中一个组成员同时充当一个在组外的源的复制。它们不能用于
group_replication_applier或group_replication_recovery通道。此选项仅影响适用于表的语句。它不影响仅适用于其他数据库对象(如存储过程)的语句。要过滤操作存储过程的语句,请使用一个或多个
--replicate-*-db选项。 -
--replicate-ignore-table=*db_name.tbl_name*命令行格式 --replicate-ignore-table=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 节,“基于通道的复制过滤器”。注意
全局复制过滤器不能用于配置为组复制的 MySQL 服务器实例,因为在某些服务器上过滤事务会导致组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,其中一个组成员同时充当组外源的副本。它们不能用于
group_replication_applier或group_replication_recovery通道。此选项仅影响适用于表的语句。它不影响仅适用于其他数据库对象的语句,如存储过程。要过滤操作存储过程的语句,请使用一个或多个
--replicate-*-db选项。 -
--replicate-rewrite-db=*from_name*->*to_name*命令行格式 --replicate-rewrite-db=old_name->new_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选项时遵循以下建议:-
在源和副本上手动创建*
from_name和to_name*数据库,名称不同。 -
如果您使用基于语句或混合二进制日志格式,请不要使用跨数据库查询,并且不要在查询中指定数据库名称。对于 DDL 和 DML 语句,依赖
USE语句来指定当前数据库,并且在查询中只使用表名。 -
如果您仅使用基于行的二进制日志格式,对于 DDL 语句,依赖
USE语句来指定当前数据库,并且在查询中只使用表名。对于 DML 语句,如果需要,可以使用完全限定的表名(db.table)。
如果遵循这些建议,结合表级复制过滤选项(如
--replicate-do-table),使用--replicate-rewrite-db选项是安全的。此选项支持通道特定的复制过滤器,使多源副本能够为不同源使用特定的过滤器。指定通道名称,后跟冒号,再跟过滤器规范。第一个冒号被解释为分隔符,任何后续的冒号都被解释为字面冒号。例如,要在名为*
channel_1*的通道上配置通道特定的复制过滤器,请使用:$> mysqld --replicate-rewrite-db=*channel_1*:*db_name1*->*db_name2*如果使用冒号但未指定通道名称,则该选项会为默认复制通道配置复制过滤器。有关更多信息,请参见第 19.2.5.4 节,“基于复制通道的过滤器”。
注意
全局复制过滤器不能在配置为组复制的 MySQL 服务器实例上使用,因为在某些服务器上过滤事务会导致组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,其中一个组成员同时充当了组外源的副本。它们不能用于
group_replication_applier或group_replication_recovery通道。 -
-
--replicate-same-server-id命令行格式 --replicate-same-server-id[={OFF|ON}]类型 布尔值 默认值 OFF此选项用于副本。默认值为 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(applier)线程执行的自己事件之前,使用此选项启动副本。 -
--replicate-wild-do-table=*db_name.tbl_name*命令行格式 --replicate-wild-do-table=name类型 字符串 通过告知复制 SQL(applier)线程,创建一个复制过滤器,限制复制到更新表匹配指定数据库和表名模式的语句。模式可以包含
%和_通配符,其含义与LIKE模式匹配运算符相同。要指定多个表,需要多次使用此选项,每个表使用一次。这适用于跨数据库更新。参见 Section 19.2.5, “服务器如何评估复制过滤规则”。您也可以通过发出CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE语句来创建这样的过滤器。此选项支持通道特定的复制过滤器,使多源副本能够为不同源使用特定过滤器。要在名为*
channel_1*的通道上配置通道特定的复制过滤器,请使用--replicate-wild-do-table:*channel_1*:*db_name.tbl_name*。在这种情况下,第一个冒号被解释为分隔符,后续冒号为字面冒号。有关更多信息,请参见 Section 19.2.5.4, “基于复制通道的过滤器”。重要
全局复制过滤器不能在配置为组复制的 MySQL 服务器实例上使用,因为在某些服务器上过滤事务会导致组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,组成员同时充当源站外组的副本。它们不能用于
group_replication_applier或group_replication_recovery通道。由
--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%匹配,则数据库级语句将被复制。重要
表级复制过滤器仅应用于在查询中明确提及并操作的表。它们不适用于查询隐式更新的表。例如,一个
GRANT语句,更新mysql.user系统表但未提及该表,不受指定mysql.%作为通配符模式的过滤器的影响。要在数据库或表名模式中包含字面通配符字符,请使用反斜杠进行转义。例如,要复制名为
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*命令行格式 --replicate-wild-ignore-table=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 节,“基于复制通道的过滤器”。重要
全局复制过滤器不能用于配置了组复制的 MySQL 服务器实例,因为在某些服务器上过滤事务会导致组无法达成一致状态。通道特定的复制过滤器可以用于与组复制无直接关系的复制通道,例如,其中一个组成员同时充当源站外组的副本。它们不能用于
group_replication_applier或group_replication_recovery通道。例如,
--replicate-wild-ignore-table=foo%.bar%不会复制使用以foo开头的数据库和以bar开头的表的更新。有关匹配原理的信息,请参阅--replicate-wild-do-table选项的描述。在选项值中包含字面通配符的规则与--replicate-wild-ignore-table相同。重要
表级复制过滤器仅适用于在查询中明确提及和操作的表。它们不适用于查询隐式更新的表。例如,一个
GRANT语句,更新mysql.user系统表但未提及该表,不受指定mysql.%作为通配符模式的过滤器影响。如果需要过滤掉
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[={OFF|ON}]引入版本 8.0.26 系统变量 skip_replica_start范围 全局 动态 否 SET_VAR提示适用否 类型 布尔 默认值 OFF从 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 服务器的权限结构访问此功能,从而数据库管理员无需任何操作系统的特权访问。 -
--skip-slave-start命令行格式 --skip-slave-start[={OFF|ON}]已弃用 8.0.26 系统变量 skip_slave_start范围 全局 动态 否 SET_VAR提示适用否 类型 布尔 默认值 OFF从 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 服务器的权限结构访问此功能,这样数据库管理员就不需要对操作系统拥有任何特权访问。 -
--slave-skip-errors=[*err_code1*,*err_code2*,...|all|ddl_exist_errors]命令行格式 --slave-skip-errors=name已弃用 8.0.26 系统变量 slave_skip_errors范围 全局 动态 否 SET_VAR提示适用否 类型 字符串 默认值 OFF有效值 OFF``[错误代码列表]``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和--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}命令行格式 --slave-sql-verify-checksum[={OFF|ON}]类型 布尔值 默认值 ON启用此选项时,副本会检查从中继日志中读取的校验和。如果不匹配,则副本会出现错误。
以下选项仅在 MySQL 测试套件内部用于复制测试和调试。不适用于生产环境。
-
--abort-slave-event-count命令行格式 --abort-slave-event-count=#已弃用 8.0.29 类型 整数 默认值 0最小值 0当将此选项设置为除 0(默认值)之外的某个正整数*
value时,它会影响复制行为如下:在复制 SQL 线程启动后,允许执行value*个日志事件;之后,复制 SQL 线程不再接收任何事件,就好像源端的网络连接被切断一样。复制 SQL 线程继续运行,并且SHOW REPLICA STATUS的输出在Replica_IO_Running和Replica_SQL_Running列中都显示Yes,但不再从中继日志中读取更多事件。此选项仅在 MySQL 测试套件内部用于复制测试和调试。不适用于生产环境。从 MySQL 8.0.29 开始,已弃用,并可能在将来的 MySQL 版本中移除。
-
--disconnect-slave-event-count命令行格式 --disconnect-slave-event-count=#已弃用 8.0.29 类型 整数 默认值 0此选项仅在 MySQL 测试套件内部用于复制测试和调试。不适用于生产环境。从 MySQL 8.0.29 开始,已弃用,并可能在将来的 MySQL 版本中移除。
用于副本服务器的系统变量
以下列表描述了用于控制复制服务器的系统变量。它们可以在服务器启动时设置,其中一些可以在运行时使用 SET 进行更改。用于复制的服务器选项在本节的前面列出。
-
init_replica命令行格式 --init-replica=name引入 8.0.26 系统变量 init_replica范围 全局 动态 是 SET_VAR提示适用否 类型 字符串 从 MySQL 8.0.26 开始,请使用
init_replica代替已在该版本中弃用的init_slave。在 MySQL 8.0.26 之前的版本中,请使用init_slave。init_replica类似于init_connect,但是是每次复制 SQL 线程启动时由复制服务器执行的字符串。该字符串的格式与init_connect变量相同。此变量的设置将对后续的START REPLICA生效。注意
复制 SQL 线程在执行
init_replica之前向客户端发送确认。因此,在START REPLICA返回之前,不能保证已执行init_replica。有关更多信息,请参见 Section 15.4.2.6, “START REPLICA 语句”。 -
init_slave命令行格式 --init-slave=name已弃用 8.0.26 系统变量 init_slave范围 全局 动态 是 SET_VAR提示适用否 类型 字符串 从 MySQL 8.0.26 开始,
init_slave已被弃用,应改用别名init_replica。在 MySQL 8.0.26 之前的版本中,请使用init_slave。init_slave类似于init_connect,但是是一个字符串,每次复制 SQL 线程启动时由副本服务器执行。字符串的格式与init_connect变量相同。此变量的设置将对后续的START REPLICA语句生效。注意
复制 SQL 线程在执行
init_slave之前向客户端发送确认。因此,在START REPLICA返回之前,不能保证init_slave已执行。有关更多信息,请参见 Section 15.4.2.6, “START REPLICA Statement”。 -
log_slow_replica_statements命令行格式 --log-slow-replica-statements[={OFF|ON}]引入版本 8.0.26 系统变量 log_slow_replica_statements范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF从 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或设置binlog_format=MIXED且语句以语句格式记录时,才将查询添加到副本的慢查询日志中。即使启用了log_slow_replica_statements,当以行格式记录慢查询时,当设置binlog_format=MIXED时,或者当设置binlog_format=ROW时记录时,这些慢查询不会添加到副本的慢查询日志中。设置
log_slow_replica_statements没有立即效果。该变量的状态适用于所有后续的START REPLICA语句。还要注意,全局设置的long_query_time适用于 SQL 线程的生命周期。如果更改了该设置,必须停止并重新启动复制 SQL 线程以实施更改(例如,通过使用带有SQL_THREAD选项的STOP REPLICA和START REPLICA语句)。 -
log_slow_slave_statements命令行格式 --log-slow-slave-statements[={OFF|ON}]已弃用 8.0.26 系统变量 log_slow_slave_statements作用域 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF从 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,或者当设置binlog_format=MIXED并且语句以语句格式记录时,查询才会被添加到副本的慢查询日志中。即使启用了log_slow_slave_statements,当以行格式记录慢查询时,当设置binlog_format=MIXED时,或者当设置binlog_format=ROW时记录时,这些慢查询也不会被添加到副本的慢查询日志中。设置
log_slow_slave_statements没有立即生效。该变量的状态适用于所有后续的START REPLICA语句。还要注意,全局设置的long_query_time适用于 SQL 线程的生命周期。如果更改了该设置,必须停止并重新启动复制 SQL 线程以在那里实施更改(例如,通过使用带有SQL_THREAD选项的STOP REPLICA和START REPLICA语句)。 -
master_info_repository命令行格式 --master-info-repository={FILE|TABLE}已弃用 8.0.23 系统变量 master_info_repository范围 全局 动态 是 SET_VAR提示适用否 类型 字符串 默认值 TABLE有效值 FILE``TABLE现在已弃用此系统变量的使用。设置
TABLE是默认值,并且在配置多个复制通道时是必需的。曾经弃用的替代设置FILE。默认设置下,副本将关于源的元数据(包括状态和连接信息)记录到
mysql系统数据库中的mysql.slave_master_info表中的InnoDB表中。有关连接元数据存储库的更多信息,请参见 第 19.2.4 节,“中继日志和复制元数据存储库”。FILE设置将副本的连接元数据存储库写入一个文件,默认情况下命名为master.info。可以使用--master-info-file选项更改名称。 -
max_relay_log_size命令行格式 --max-relay-log-size=#系统变量 max_relay_log_size范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 0最小值 0最大值 1073741824单位 字节 块大小 4096如果副本对其中继日志的写入导致当前日志文件大小超过此变量的值,则副本会旋转中继日志(关闭当前文件并打开下一个文件)。如果
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命令行格式 --relay-log=file_name系统变量 relay_log范围 全局 动态 否 SET_VAR提示适用否 类型 文件名 中继日志文件的基本名称。对于默认复制通道,中继日志的默认基本名称为
*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系统变量在执行以下任务时很有用:-
创建与主机名无关的中继日志的名称。
-
如果您需要将中继日志放在数据目录之外的某个区域,因为您的中继日志往往非常大,并且您不想减少
max_relay_log_size。 -
通过在磁盘之间使用负载平衡来提高速度。
您可以从
relay_log_basename系统变量中获取中继日志文件名(和路径)。 -
-
relay_log_basename系统变量 relay_log_basename作用域 全局 动态 否 SET_VAR提示适用否 类型 文件名 默认值 datadir + '/' + hostname + '-relay-bin'保存中继日志文件的基本名称和完整路径。最大变量长度为 256。此变量由服务器设置,只读。
-
relay_log_index命令行格式 --relay-log-index=file_name系统变量 relay_log_index范围 全局 动态 否 SET_VAR提示适用否 类型 文件名 默认值 *host_name*-relay-bin.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_info_file命令行格式 --relay-log-info-file=file_name弃用 8.0.18 系统变量 relay_log_info_file范围 全局 动态 否 SET_VAR提示适用否 类型 文件名 默认值 relay-log.info此系统变量的使用现已弃用。 如果设置了
relay_log_info_repository=FILE,则用于设置复制品的应用程序元数据存储库的文件名。relay_log_info_file和relay_log_info_repository系统变量的使用已被弃用,因为使用文件作为应用程序元数据存储库已被崩溃安全表取代。 有关应用程序元数据存储库的信息,请参见 第 19.2.4.2 节,“复制元数据存储库”。 -
relay_log_info_repository命令行格式 --relay-log-info-repository=value弃用 8.0.23 系统变量 relay_log_info_repository范围 全局 动态 是 SET_VAR提示适用否 类型 字符串 默认值 TABLE有效值 FILE``TABLE此系统变量的使用现已不推荐。
TABLE是默认设置,当配置多个复制通道时,必须使用TABLE设置。副本的应用程序元数据存储库也需要TABLE设置,以使复制对意外停止具有弹性。有关更多信息,请参见 Section 19.4.2, “Handling an Unexpected Halt of a Replica”。曾经不推荐使用替代设置FILE。默认设置下,副本将其应用程序元数据存储库存储为
InnoDB表,存储在名为mysql.slave_relay_log_info的mysql系统数据库中。有关应用程序元数据存储库的更多信息,请参见 Section 19.2.4, “Relay Log and Replication Metadata Repositories”。默认情况下,
FILE设置将副本的应用程序元数据存储库写入文件,默认情况下命名为relay-log.info。可以使用relay_log_info_file系统变量更改名称。 -
relay_log_purge命令行格式 --relay-log-purge[={OFF|ON}]系统变量 relay_log_purge作用范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 ON禁用或启用中继日志文件在不再需要时立即清除。默认值为 1(
ON)。 -
relay_log_recovery命令行格式 --relay-log-recovery[={OFF|ON}]系统变量 relay_log_recovery作用范围 全局 动态 否 SET_VAR提示适用否 类型 布尔值 默认值 OFF如果启用此变量,它将在服务器启动后立即启用自动中继日志恢复。恢复过程将创建一个新的中继日志文件,将 SQL(应用程序)线程位置初始化为此新中继日志,并将 I/O(接收器)线程初始化为应用程序线程位置。然后继续从源读取中继日志。如果为使用
CHANGE REPLICATION SOURCE TO选项为复制通道设置了SOURCE_AUTO_POSITION=1,则用于启动复制的源位置可能是在连接中接收到的位置,而不是在此过程中分配的位置。此全局变量在运行时是只读的。可以在复制服务器启动时使用
--relay-log-recovery选项设置其值,该选项应在复制品意外停止后使用,以确保不处理可能损坏的中继日志,并且必须使用以确保崩溃安全的复制品。默认值为 0(禁用)。有关在复制品上设置的组合设置,以使其对意外停止最具弹性,请参见第 19.4.2 节,“处理复制品意外停止”。对于多线程复制品(其中
replica_parallel_workers或slave_parallel_workers大于 0),在启动时设置--relay-log-recovery会自动处理已从中继日志执行的事务序列中的任何不一致和间隙。当使用基于文件位置的复制时,这些间隙可能会发生。(有关更多详细信息,请参见第 19.5.1.34 节,“复制和事务不一致性”。)中继日志恢复过程使用与START REPLICA UNTIL SQL_AFTER_MTS_GAPS语句相同的方法处理间隙。当复制品达到一致的无间隙状态时,中继日志恢复过程继续从源处获取进一步的事务,从 SQL(应用程序)线程位置开始。当使用基于 GTID 的复制时,从 MySQL 8.0.18 开始,多线程复制品首先检查MASTER_AUTO_POSITION是否设置为ON,如果是,则省略计算应跳过或不跳过的事务的步骤,因此不需要旧的中继日志进行恢复过程。注意
此变量不会影响以下 Group Replication 通道:
-
group_replication_applier -
group_replication_recovery
任何其他在组上运行的通道都会受到影响,例如从外部来源或另一个组复制的通道。
-
-
relay_log_space_limit命令行格式 --relay-log-space-limit=#系统变量 relay_log_space_limit范围 全局 动态 否 SET_VAR提示适用否 类型 整数 默认值 0最小值 0最大值 18446744073709551615单位 字节 用于所有中继日志的最大空间量。
-
replica_checkpoint_group命令行格式 --replica-checkpoint-group=#引入版本 8.0.26 系统变量 replica_checkpoint_group范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 512最小值 32最大值 524280块大小 8从 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语句。以前,NDB Cluster 不支持多线程副本,对于此变量的设置会被静默忽略。这个限制在 MySQL 8.0.33 中被取消。
此变量与
replica_checkpoint_period系统变量结合使用,当超过任一限制时,将执行检查点并重置跟踪事务数量和自上次检查点以来经过的时间的计数器。此变量的最小允许值为 32,除非服务器是使用
-DWITH_DEBUG构建的,在这种情况下,最小值为 1。有效值始终是 8 的倍数;您可以将其设置为不是这种倍数的值,但服务器会在存储值之前将其向下舍入到下一个较低的 8 的倍数。(例外: 调试服务器不执行此舍入。)无论服务器是如何构建的,默认值都是 512,最大允许值为 524280。 -
replica_checkpoint_period命令行格式 --replica-checkpoint-period=#引入版本 8.0.26 系统变量 replica_checkpoint_period作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 300最小值 1最大值 4294967295单位 毫秒 在 MySQL 8.0.26 及更高版本中,使用
replica_checkpoint_period代替slave_checkpoint_period,后者从该版本开始被弃用;在 MySQL 8.0.26 之前,请使用slave_checkpoint_period。replica_checkpoint_period设置了允许经过的最长时间(以毫秒为单位),在调用检查点操作以更新多线程副本状态之前。设置此变量对于未启用多线程的副本没有影响。设置此变量立即对所有复制通道生效,包括正在运行的通道。以前,NDB Cluster 不支持多线程副本,对于这个变量的设置被静默忽略。这个限制在 MySQL 8.0.33 中被取消。
此变量与
replica_checkpoint_group系统变量结合使用,当超过任一限制时,将执行检查点并重置跟踪事务数量和自上次检查点以来经过的时间的计数器。除非服务器是使用
-DWITH_DEBUG构建的,否则此变量的最小允许值为 1,此时最小值为 0。无论服务器是如何构建的,默认值为 300 毫秒,最大可能值为 4294967295 毫秒(约 49.7 天)。 -
replica_compressed_protocol命令行格式 --replica-compressed-protocol[={OFF|ON}]引入版本 8.0.26 系统变量 replica_compressed_protocol作用范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF从 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系统变量激活,也可用于节省带宽。如果将二进制日志事务压缩与协议压缩结合使用,则协议压缩的作用数据减少,但仍可压缩标头以及未压缩的事件和事务有效载荷。有关二进制日志事务压缩的更多信息,请参见第 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=mode引入版本 8.0.26 系统变量 replica_exec_mode范围 全局 动态 是 SET_VAR提示适用否 类型 枚举 默认值 幂等(NDB)严格(其他)有效值 严格``幂等从 MySQL 8.0.26 开始,使用
replica_exec_mode替代slave_exec_mode,后者从该版本开始已被弃用。在 MySQL 8.0.26 之前的版本中,请使用slave_exec_mode。replica_exec_mode控制复制线程在复制过程中如何解决冲突和错误。IDEMPOTENT模式会导致重复键和未找到键的错误被抑制;STRICT表示不会发生此类抑制。IDEMPOTENT模式旨在用于多源复制、循环复制以及一些其他特殊的 NDB 集群复制场景。(详见 第 25.7.10 节,“NDB 集群复制:双向和循环复制”,以及 第 25.7.12 节,“NDB 集群复制冲突解决”,获取更多信息。)NDB 集群会忽略为replica_exec_mode明确设置的任何值,并始终将其视为IDEMPOTENT。在 MySQL Server 8.0 中,
STRICT模式是默认值。设置此变量会立即对所有复制通道生效,包括正在运行的通道。
对于除了
NDB外的存储引擎,只有在您绝对确定重复键错误和未找到键错误可以安全忽略时才应使用IDEMPOTENT模式。它旨在用于 NDB 集群的故障转移场景,其中使用了多源复制或循环复制,并不建议在其他情况下使用。 -
replica_load_tmpdir命令行格式 --replica-load-tmpdir=dir_name引入版本 8.0.26 系统变量 replica_load_tmpdir作用域 全局 动态 否 SET_VAR提示适用否 类型 目录名称 默认值 --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命令行格式 --replica-max-allowed-packet=#引入版本 8.0.26 系统变量 replica_max_allowed_packet范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 1073741824最小值 1024最大值 1073741824单位 字节 块大小 1024从 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 的值,则该值将向上舍入为下一个最高的 1024 的倍数以进行存储或使用;将
replica_max_allowed_packet设置为 0 会导致使用 1024。(在所有这些情况下都会发出截断警告。)默认值和最大值为 1073741824(1 GB);最小值�� 1024。 -
replica_net_timeout命令行格式 --replica-net-timeout=#引入版本 8.0.26 系统变量 replica_net_timeout范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 60最小值 1最大值 31536000单位 秒 从 MySQL 8.0.26 开始,使用
replica_net_timeout代替从该版本开始已弃用的slave_net_timeout。在 MySQL 8.0.26 之前的版本中,请使用slave_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性能模式表中。请注意,对于replica_net_timeout的值或默认设置的更改不会自动更改心跳间隔,无论是显式设置还是使用先前计算的默认值。如果更改连接超时时间,您还必须发出CHANGE REPLICATION SOURCE TO来调整心跳间隔到一个适当的值,以便在连接超时之前发生。 -
replica_parallel_type命令行格式 --replica-parallel-type=value引入版本 8.0.26 已弃用 8.0.29 系统变量 replica_parallel_type范围 全局 动态 是 SET_VAR提示适用否 类型 枚举 默认值(≥ 8.0.27) LOGICAL_CLOCK默认值(8.0.26) DATABASE有效值 DATABASE``LOGICAL_CLOCK从 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指定了在副本上决定哪些事务可以并行执行的策略。该变量对于未启用多线程的副本没有影响。可能的值包括:-
LOGICAL_CLOCK: 事务在副本上并行应用,基于复制源写入二进制日志的时间戳。根据时间戳跟踪事务之间的依赖关系,以在可能的情况下提供额外的并行化。 -
DATABASE: 更新不同数据库的事务并行应用。只有在数据被分区到多个独立并且同时在源上更新的数据库时才适用此值。不能有跨数据库约束,因为这样的约束可能在副本上被违反。
当启用
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设置为WRITESET或WRITESET_SESSION,以指定在可能的情况下使用写入集而不是时间戳进行并行化。当使用
binlog_transaction_compression系统变量启用二进制日志事务压缩时,如果将replica_parallel_type设置为DATABASE,则在调度事务之前会映射受事务影响的所有数据库。使用DATABASE策略的二进制日志事务压缩可能会减少与未压缩事务相比的并行性,后者会为每个事件映射并调度。replica_parallel_type从 MySQL 8.0.29 开始已弃用,使用数据库分区的事务并行化也已弃用。预计在未来的版本中将删除对这些的支持,并且之后将专门使用LOGICAL_CLOCK。 -
-
replica_parallel_workers命令行格式 --replica-parallel-workers=#引入版本 8.0.26 系统变量 replica_parallel_workers作用域 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值(≥ 8.0.27) 4默认值(8.0.26) 0最小值 0最大值 1024从 MySQL 8.0.26 开始,
slave_parallel_workers已不推荐使用,应改为使用replica_parallel_workers。 (在 MySQL 8.0.26 之前,必须使用slave_parallel_workers来设置应用程序线程的数量。)replica_parallel_workers启用副本的多线程,并设置用于并行执行复制事务的应用程序线程数。当值大于或等于 1 时,副本使用指定数量的工作线程来执行事务,还有一个协调器线程从中继日志中读取事务并将其调度给工作线程。当值为 0 时,只有一个线程按顺序读取和应用事务。如果使用多个复制通道,则此变量的值适用于每个通道使用的线程。在 MySQL 8.0.27 之前,此系统变量的默认值为 0,因此副本默认使用单个工作线程。从 MySQL 8.0.27 开始,默认值为 4,这意味着副本默认为多线程。
截至 MySQL 8.0.30,将此变量设置为 0 已不推荐使用,会引发警告,并可能在将来的 MySQL 版本中删除。对于单个工作线程,请将
replica_parallel_workers设置为 1。当
replica_preserve_commit_order(或slave_preserve_commit_order)设置为ON(MySQL 8.0.27 及更高版本的默认设置),副本上的事务按照在副本的中继日志中出现的顺序在副本上外部化。事务在应用程序线程之间的分配方式由replica_parallel_type(MySQL 8.0.26 及更高版本)或slave_parallel_type(MySQL 8.0.26 之前)确定。从 MySQL 8.0.27 开始,这些系统变量也具有适当的多线程默认值。要禁用并行执行,请将
replica_parallel_workers设置为 1,这样副本将使用一个协调线程读取事务,一个工作线程应用事务,这意味着事务按顺序应用。当replica_parallel_workers等于 1 时,replica_parallel_type(slave_parallel_type)和replica_preserve_commit_order(slave_preserve_commit_order)系统变量不起作用,会被忽略。如果replica_parallel_workers等于 0,同时启用CHANGE REPLICATION SOURCE TO选项GTID_ONLY,副本将有一个协调线程和一个工作线程,就像replica_parallel_workers被设置为 1 一样。(GTID_ONLY在 MySQL 8.0.27 及更高版本中可用。)有一个并行工作者时,replica_preserve_commit_order(slave_preserve_commit_order)系统变量也不起作用。设置
replica_parallel_workers没有立即效果,而是适用于所有后续的START REPLICA语句。多线程副本从 NDB Cluster 8.0.33 版本开始受支持。(之前,
NDB会默默忽略replica_parallel_workers的任何设置。)更多信息请参见第 25.7.11 节,“使用多线程应用程序的 NDB Cluster 复制”。增加工作者数量可以提高并行性的潜力。通常情况下,这会提高性能,直到某个点,之后增加工作者数量会由于并发效应(如锁争用)而降低性能。理想数量取决于硬件和工作负载;很难预测,通常需要通过测试找到。没有主键的表总是会损害性能,在
replica_parallel_workers> 1 的副本上可能会产生更大的负面性能影响;因此,在启用此选项之前,请确保所有表都有主键。 -
replica_pending_jobs_size_max命令行格式 --replica-pending-jobs-size-max=#引入版本 8.0.26 系统变量 `replica_pending_jobs_size_max`` 范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 128M最小值 1024最大值 16EiB单位 字节 块大小 1024从 MySQL 8.0.26 开始,使用
replica_pending_jobs_size_max代替从该版本开始已弃用的slave_pending_jobs_size_max。在 MySQL 8.0.26 之前的版本中,使用slave_pending_jobs_size_max。对于多线程复制品,此变量设置了可用于尚未应用的事件的 applier 队列的最大内存量(以字节为单位)。设置此变量对未启用多线程的复制品没有影响。设置此变量没有立即效果。变量的状态适用于所有后续的
START REPLICA语句。此变量的最小可能值为 1024 字节;默认值为 128MB。最大可能值为 18446744073709551615(16 exbibytes)。不是 1024 字节的精确倍数的值在存储之前会被舍入为下一个较低的 1024 字节的倍数。
此变量的值是一个软限制,可以设置为匹配正常工作负载。如果异常大的事件超过此大小,事务将被暂停,直到所有工作线程的队列为空,然后再处理。所有后续事务将被暂停,直到大事务完成。
-
replica_preserve_commit_order命令行格式 --replica-preserve-commit-order[={OFF|ON}]引入 8.0.26 系统变量 replica_preserve_commit_order范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 (≥ 8.0.27) ON默认值 (8.0.26) OFF从 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),因此replica_preserve_commit_order=ON是默认值,并且设置replica_parallel_type=LOGICAL_CLOCK也是默认值。同样从 MySQL 8.0.27 开始,如果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.0.27 之前 不 是默认设置。在更改replica_preserve_commit_order和replica_parallel_type的值之前,必须停止复制 SQL 线程(如果使用多个复制通道,则对所有复制通道都要停止)。当
replica_preserve_commit_order=OFF被设置时,多线程复制并行应用的事务可能会无序提交。因此,检查最近执行的事务并不能保证源数据库上的所有先前事务已在复制中执行。在复制中继日志中执行的事务序列可能存在间隙的可能性。这对于使用多线程复制时的日志记录和恢复有影响。有关更多信息,请参见第 19.5.1.34 节,“复制和事务不一致性”。当
replica_preserve_commit_order=ON被设置时,执行的工作线程会等待所有先前的事务提交后再进行提交。当一个线程在等待其他工作线程提交它们的事务时,它会报告其状态为等待前一个事务提交。在这种模式下,多线程复制永远不会进入源数据库不在的状态。这支持将复制用于读取扩展。参见第 19.4.5 节,“使用复制进行扩展”。注意
-
replica_preserve_commit_order=ON不能防止源数据库二进制日志位置滞后,其中Exec_master_log_pos落后于已执行事务的位置。请参见第 19.5.1.34 节,“复制和事务不一致性”。 -
replica_preserve_commit_order=ON不保留如果复制使用二进制日志过滤器,如--binlog-do-db,则不保留提交顺序和事务历史。 -
replica_preserve_commit_order=ON不保留非事务性 DML 更新的顺序。这些更新可能在在中继日志中先于它们之前的事务提交,这可能导致在复制中继日志中执行的事务序列中存在间隙。 -
如果使用基于语句的复制,并且事务性和非事务性存储引擎参与在源上回滚的非 XA 事务,可能会出现在副本上保留提交顺序的限制。通常,在源上回滚的非 XA 事务不会被复制到副本,但在这种特殊情况下,该事务可能会被复制到副本。如果发生这种情况,没有二进制日志记录的多线程副本无法处理事务回滚,因此在这种情况下,副本上的提交顺序会与中继日志中事务的顺序不同。
-
-
replica_sql_verify_checksum命令行格式 --replica-sql-verify-checksum[={OFF|ON}]引入版本 8.0.26 系统变量 replica_sql_verify_checksum范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 ON从 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(应用程序)线程使用从中继日志读取的校验和来验证数据。如果出现不匹配,副本将停止并显示错误。设置此变量立即对所有复制通道生效,包括正在运行的通道。注意
复制 I/O(接收器)线程在从网络接收事件时,始终尽可能读取校验和。
-
replica_transaction_retries命令行格式 --replica-transaction-retries=#引入版本 8.0.26 系统变量 replica_transaction_retries范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 10最小值 0最大值 18446744073709551615从 MySQL 8.0.26 开始,使用
replica_transaction_retries代替从该版本开始已弃用的slave_transaction_retries。在 MySQL 8.0.26 之前的版本中,请使用slave_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=set引入版本 8.0.26 系统变量 replica_type_conversions作用域 全局 动态 是 SET_VAR提示适用否 类型 设置 默认值 有效值 ALL_LOSSY``ALL_NON_LOSSY``ALL_SIGNED``ALL_UNSIGNED从 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-optimize-for-static-plugin-config[={OFF|ON}]引入版本 8.0.23 系统变量 replication_optimize_for_static_plugin_config范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF使用共享锁,并避免不必要的锁获取,以提高半同步复制的性能。这个设置和
replication_sender_observe_commit_only在副本数量增加时有帮助,因为锁争用会降低性能。在启用此系统变量时,半同步复制插件无法卸载,因此必须在卸载完成之前禁用该系统变量。可以在安装半同步复制插件之前或之后启用此系统变量,并且可以在复制运行时启用。半同步复制源服务器也可以通过启用此系统变量获得性能优势,因为它们使用与副本相同的锁定机制。
当服务器上使用组复制时,可以启用
replication_optimize_for_static_plugin_config。在这种情况下,当由于高工作负载而导致锁争用时,可能会提高性能。 -
replication_sender_observe_commit_only命令行格式 --replication-sender-observe-commit-only[={OFF|ON}]引入版本 8.0.23 系统变量 replication_sender_observe_commit_only范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF限制回调以提高半同步复制的性能。这个设置和
replication_optimize_for_static_plugin_config在副本数量增加时有帮助,因为锁争用可能会降低性能。这个系统变量可以在安装半同步复制插件之前或之后启用,并且可以在复制运行时启用。半同步复制源服务器也可以通过启用这个系统变量获得性能优势,因为它们使用与副本相同的锁定机制。
-
report_host命令行格式 --report-host=host_name系统变量 report_host范围 全局 动态 否 SET_VAR提示适用否 类型 字符串 在副本注册期间向源报告的副本的主机名或 IP 地址。此值将出现在源服务器的
SHOW REPLICAS输出中。如果不希望副本向源注册自己,请将值保持未设置。注意
仅仅从副本连接后的 TCP/IP 套接字中读取副本服务器的 IP 地址是不够的。由于 NAT 和其他路由问题,该 IP 可能无法用于从源或其他主机连接到副本。
-
report_password命令行格式 --report-password=name系统变量 report_password范围 全局 动态 否 SET_VAR提示适用否 类型 字符串 在复制品注册期间向源报告的复制品的帐户密码。如果源使用
--show-replica-auth-info或--show-slave-auth-info启动,则此值将出现在源服务器上SHOW REPLICAS的输出中。尽管此变量的名称可能暗示相反,
report_password与 MySQL 用户权限系统无关,因此不一��(甚至可能不是)与 MySQL 复制用户帐户的密码相同。 -
report_port命令行格式 --report-port=port_num系统变量 report_port范围 全局 动态 否 SET_VAR提示适用否 类型 整数 默认值 [slave_port]最小值 0最大值 65535用于连接到复制品的 TCP/IP 端口号,在复制品注册期间向源报告。仅在复制品侦听非默认端口或源或其他客户端到复制品有特殊隧道时设置此选项。如果不确定,请不要使用此选项。
此选项的默认值是实际使用的复制品端口号。这也是
SHOW REPLICAS显示的默认值。 -
report_user命令行格式 --report-user=name系统变量 report_user范围 全局 动态 否 SET_VAR提示适用否 类型 字符串 在复制品注册期间向源报告的复制品的帐户用户名。如果源使用
--show-replica-auth-info或--show-slave-auth-info启动,则此值将出现在源服务器上SHOW REPLICAS的输出中。尽管此变量的名称可能暗示相反,
report_user与 MySQL 用户权限系统无关,因此不一定(甚至可能不是)与 MySQL 复制用户帐户的名称相同。 -
rpl_read_size命令行格式 --rpl-read-size=#系统变量 rpl_read_size范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 8192最小值 8192最大值 4294959104单位 字节 块大小 8192rpl_read_size系统变量控制从二进制日志文件和中继日志文件中读取的最小数据量(以字节为单位)。如果这些文件的大量磁盘 I/O 活动影响了数据库的性能,增加读取大小可能会减少文件读取和 I/O 停顿,尤其是当文件数据当前未被操作系统缓存时。rpl_read_size的最小和默认值为 8192 字节。该值必须是 4KB 的倍数。请注意,为从二进制日志和中继日志文件读取的每个线程分配了此值大小的缓冲区,包括源上的转储线程和副本上的协调器线程。因此,设置一个较大的值可能会影响服务器的内存消耗。 -
rpl_semi_sync_replica_enabled命令行格式 --rpl-semi-sync-replica-enabled[={OFF|ON}]引入版本 8.0.26 系统变量 rpl_semi_sync_replica_enabled范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFF当在副本上安装了
rpl_semi_sync_replica(semisync_replica.so库)插件以设置半同步复制时,rpl_semi_sync_replica_enabled可用。如果安装了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-level=#引入版本 8.0.26 系统变量 rpl_semi_sync_replica_trace_level作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 32最小值 0最大值 4294967295当安装了
rpl_semi_sync_replica(semisync_replica.so库)插件以设置半同步复制时,rpl_semi_sync_replica_trace_level可用。如果安装了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-enabled[={OFF|ON}]系统变量 rpl_semi_sync_slave_enabled作用范围 全局 动态 是 SET_VAR提示适用否 类型 布尔 默认值 OFF当安装了
rpl_semi_sync_slave(semisync_slave.so库)插件以设置半同步复制时,rpl_semi_sync_slave_enabled可用。如果安装了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-level=#系统变量 rpl_semi_sync_slave_trace_level作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 32最小值 0最大值 4294967295rpl_semi_sync_slave_trace_level在安装了rpl_semi_sync_slave(semisync_slave.so库)插件的复制品上可用,用于设置半同步复制。如果安装了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命令行格式 --rpl-stop-replica-timeout=#引入版本 8.0.26 系统变量 rpl_stop_replica_timeout作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 31536000最小值 2最大值 31536000单位 秒 从 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_timeout的最大值和默认值为 31536000 秒(1 年)。最小值为 2 秒。对此变量的更改将对后续的STOP REPLICA语句生效。此变量仅影响发出
STOP REPLICA命令的客户端。当超时时,发出命令的客户端将返回一条错误消息,指示命令执行不完整。客户端停止等待复制 I/O(接收器)和 SQL(应用程序)线程停止,但复制线程继续尝试停止,并且STOP REPLICA命令仍然有效。一旦复制线程不再忙碌,STOP REPLICA命令将被执行,副本将停止。 -
rpl_stop_slave_timeout命令行格式 --rpl-stop-slave-timeout=#已弃用 8.0.26 系统变量 rpl_stop_slave_timeout作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 31536000最小值 2最大值 31536000单位 秒 从 MySQL 8.0.26 开始,
rpl_stop_slave_timeout已被弃用,应改用别名rpl_stop_replica_timeout。在 MySQL 8.0.26 之前的版本中,请使用rpl_stop_slave_timeout。通过设置此变量,您可以控制
STOP REPLICA在超时前等待的时间长度(以秒为单位)。这可用于避免在使用不同客户端连接到副本的其他 SQL 语句和STOP REPLICA之间发生死锁。rpl_stop_slave_timeout的最大和默认值为 31536000 秒(1 年)。最小值为 2 秒。对此变量的更改将对后续的STOP REPLICA命令生效。此变量仅影响发出
STOP REPLICA命令的客户端。当超时时,发出命令的客户端将返回一条错误消息,指示命令执行不完整。客户端停止等待复制 I/O(接收器)和 SQL(应用程序)线程停止,但复制线程继续尝试停止,并且STOP REPLICA指令仍然有效。一旦复制线程不再忙碌,STOP REPLICA命令将被执行,副本将停止。 -
skip_replica_start命令行格式 --skip-replica-start[={OFF|ON}]引入 8.0.26 系统变量 skip_replica_start作用范围 全局 动态 否 SET_VAR提示适用否 类型 布尔值 默认值 OFF从 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命令行格式 --skip-slave-start[={OFF|ON}]已弃用 8.0.26 系统变量 skip_slave_start作用范围 全局 动态 否 SET_VAR提示适用否 类型 布尔值 默认值 OFF从 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关键字或在SET语句中使用@@persist_only限定符来设置。--skip-slave-start命令行选项也会设置此系统变量。您可以使用系统变量代替命令行选项,以允许通过 MySQL 服务器的权限结构访问此功能,这样数据库管理员就不需要对操作系统具有任何特权访问。 -
slave_checkpoint_group命令行格式 --slave-checkpoint-group=#弃用 8.0.26 系统变量 slave_checkpoint_group作用域 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 512最小值 32最大值 524280块大小 8从 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语句。以前,NDB Cluster 不支持多线程副本,对于此变量的设置被静默忽略。此限制在 MySQL 8.0.33 中解除。
此变量与
slave_checkpoint_period系统变量结合使用,当超过任一限制时,将执行检查点,并重置跟踪事务数量和自上次检查点以来经过的时间的计数器。该变量的最小允许值为 32,除非服务器是使用
-DWITH_DEBUG构建的,此时最小值为 1。有效值始终是 8 的倍数;您可以将其设置为非 8 的倍数,但服务器在存储值之前会将其向下舍入到下一个较低的 8 的倍数。(例外: 调试服务器不执行此舍入操作。) 无论服务器是如何构建的,默认值为 512,最大允许值为 524280。 -
slave_checkpoint_period命令行格式 --slave-checkpoint-period=#已弃用 8.0.26 系统变量 slave_checkpoint_period作用域 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 300最小值 1最大值 4294967295单位 毫秒 截至 MySQL 8.0.26,
slave_checkpoint_period已弃用,应改用replica_checkpoint_period;在 MySQL 8.0.26 之前,请使用slave_checkpoint_period。slave_checkpoint_period设置了允许经过的最长时间(以毫秒为单位),在此时间内将调用检查点操作来更新多线程副本的状态,如SHOW REPLICA STATUS所示。设置此变量对未启用多线程的副本没有影响。设置此变量立即对所有复制通道生效,包括正在运行的通道。以前,NDB Cluster 不支持多线程副本,对于这个变量的设置被静默忽略。这个限制在 MySQL 8.0.33 中被取消。
此变量与
slave_checkpoint_group系统变量结合使用,当超过任一限制时,将执行检查点并重置跟踪事务数量和自上次检查点以来经过的时间的计数器。该变量的最小允许值为 1,除非服务器是使用
-DWITH_DEBUG构建的,此时最小值为 0。无论服务器是如何构建的,默认值为 300 毫秒,最大可能值为 4294967295 毫秒(约 49.7 天)。 -
slave_compressed_protocol命令行格式 --slave-compressed-protocol[={OFF|ON}]已弃用 8.0.18 系统变量 slave_compressed_protocol范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值 OFFslave_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系统变量激活,也可用于节省带宽。如果将二进制日志事务压缩与协议压缩结合使用,协议压缩的作用机会较少,但仍可压缩标头以及未压缩的事件和事务有效载荷。有关二进制日志事务压缩的更多信息,请参见 Section 7.4.4.5, “Binary Log Transaction Compression”。自 MySQL 8.0.18 起,如果启用了
slave_compressed_protocol,它将优先于为CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO语句指定的任何SOURCE_COMPRESSION_ALGORITHMS|MASTER_COMPRESSION_ALGORITHMS选项。在这种情况下,如果源和副本都支持该算法,则连接到源使用zlib压缩。如果禁用了slave_compressed_protocol,则SOURCE_COMPRESSION_ALGORITHMS|MASTER_COMPRESSION_ALGORITHMS的值适用。有关更多信息,请参见 Section 6.2.8, “Connection Compression Control”。从 MySQL 8.0.18 开始,此系统变量已被弃用。您应该期望它在将来的 MySQL 版本中被移除。请参阅配置传统连接压缩。
-
slave_exec_mode命令行格式 --slave-exec-mode=mode系统变量 slave_exec_mode范围 全局 动态 是 SET_VAR提示适用否 类型 枚举 默认值 IDEMPOTENT(NDB)STRICT(其他)有效值 STRICT``IDEMPOTENT从 MySQL 8.0.26 开始,
slave_exec_mode已被弃用,应改用别名replica_exec_mode。在 MySQL 8.0.26 之前的版本中,请使用slave_exec_mode。slave_exec_mode控制复制线程在复制过程中如何解决冲突和错误。IDEMPOTENT模式导致重复键和找不到键错误的抑制;STRICT表示不会发生这种抑制。IDEMPOTENT模式适用于多源复制、循环复制和 NDB Cluster 复制的一些其他特殊复制场景。(有关更多信息,请参阅第 25.7.10 节,“NDB Cluster 复制:双向和循环复制”,以及第 25.7.12 节,“NDB Cluster 复制冲突解决”。)NDB Cluster 忽略为slave_exec_mode明确设置的任何值,并始终将其视为IDEMPOTENT。在 MySQL Server 8.0 中,
STRICT模式是默认值。设置此变量立即对所有复制通道生效,包括正在运行的通道。
对于除了
NDB之外的存储引擎,只有在您绝对确定可以安全忽略重复键错误和找不到键错误时,才应使用IDEMPOTENT模式。它旨在用于 NDB Cluster 的故障转移场景,其中使用了多源复制或循环复制,并不建议在其他情况下使用。 -
slave_load_tmpdir命令行格式 --slave-load-tmpdir=dir_name已弃用 8.0.26 系统变量 slave_load_tmpdir范围 ��局 动态 否 SET_VAR提示适用否 类型 目录名称 默认值 --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命令行格式 --slave-max-allowed-packet=#已弃用 8.0.26 系统变量 slave_max_allowed_packet范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 1073741824最小值 1024最大值 1073741824单位 字节 块大小 1024从 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 的值,则将其舍入到下一个最高的 1024 的倍数以进行存储或使用;将
slave_max_allowed_packet设置为 0 会���致使用 1024。(在所有这些情况下都会发出截断警告。)默认值和最大值为 1073741824(1 GB);最小值为 1024。 -
slave_net_timeout命令行格式 --slave-net-timeout=#已弃用 8.0.26 系统变量 slave_net_timeout范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 60最小值 1最大值 31536000单位 秒 从 MySQL 8.0.26 开始,
slave_net_timeout已被弃用,应改用别名replica_net_timeout。在 MySQL 8.0.26 之前的版本中,请使用slave_net_timeout。slave_net_timeout指定等待来自源的更多数据或心跳信号的秒数,然后副本认为连接已中断,中止读取,并尝试重新连接。设置此变量没有立即效果。变量的状态适用于所有后续的START REPLICA命令。默认值为 60 秒(一分钟)。超时后立即进行第一次重试。重试间隔由
CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO语句的SOURCE_CONNECT_RETRY|MASTER_CONNECT_RETRY选项控制,重连尝试次数由SOURCE_RETRY_COUNT|MASTER_RETRY_COUNT选项限制。心跳间隔,用于防止在没有数据的情况下发生连接超时,由
CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO语句的SOURCE_HEARTBEAT_PERIOD|MASTER_HEARTBEAT_PERIOD选项控制。心跳间隔默认为slave_net_timeout值的一半,并记录在副本的连接元数据存储库中,并显示在replication_connection_configuration性能模式表中。请注意,对于slave_net_timeout的值或默认设置的更改不会自动更改心跳间隔,无论是显式设置还是使用先前计算的默认值。如果更改了连接超时时间,您还必须发出CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO来调整心跳间隔至适当值,以确保它在连接超时之前发生。 -
slave_parallel_type命令行格式 --slave-parallel-type=value已弃用 8.0.26 系统变量 slave_parallel_type作用范围 全局 动态 是 SET_VAR提示适用否 类型 枚举 默认值(≥ 8.0.27) LOGICAL_CLOCK默认值(≤ 8.0.26) DATABASE有效值 DATABASE``LOGICAL_CLOCK从 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指定了用于决定在副本上哪些事务允许并行执行的策略。该变量对于未启用多线程的副本没有影响。可能的值包括:-
LOGICAL_CLOCK:在源头上属于同一二进制日志组提交的事务在副本上并行应用。事务之间的依赖关系基于它们的时间戳进行跟踪,以在可能的情况下提供额外的并行化。当设置了这个值时,可以在源头上使用binlog_transaction_dependency_tracking系统变量来指定在写入集可用的情况下,使用写入集代替时间戳进行并行化,如果写入集对事务提供了改进的结果。 -
DATABASE:更新不同数据库的事务并行应用。只有在数据被分区到多个独立并同时在源头上更新的数据库时,此值才合适。在副本上不得存在跨数据库约束,因为这样的约束可能会在副本上被违反。
当
replica_preserve_commit_order=ON或slave_preserve_commit_order=ON被设置时,只能使用LOGICAL_CLOCK。在 MySQL 8.0.27 之前,默认为DATABASE。从 MySQL 8.0.27 开始,默认情况下为副本服务器启用了多线程(默认为replica_parallel_workers=4),因此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命令行格式 --slave-parallel-workers=#弃用 8.0.26 系统变量 slave_parallel_workers范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值(≥ 8.0.27) 4默认值(≤ 8.0.26) 0最小值 0最大值 1024从 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_type或slave_parallel_type以及replica_preserve_commit_order或slave_preserve_commit_order系统变量没有效果,并且被忽略。从 MySQL 8.0.27 开始,如果在副本上启用GTID_ONLY选项时禁用并行执行,副本实际上会使用一个并行工作者来利用无需访问文件位置即可重试事务的方法。使用一个并行工作者,replica_preserve_commit_order(slave_preserve_commit_order)系统变量也没有效果。设置
replica_parallel_workers没有立即效果。变量的状态适用于所有后续的START REPLICA语句。以前,NDB Cluster 不支持多线程副本,静默地忽略了此变量的设置。这个限制在 MySQL 8.0.33 中解除。
-
slave_pending_jobs_size_max命令行格式 --slave-pending-jobs-size-max=#已弃用 8.0.26 系统变量 slave_pending_jobs_size_max范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值(≥ 8.0.12) 128M默认值(8.0.11) 16M最小值 1024最大值 16EiB单位 字节 块大小 1024从 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命令行格式 --slave-preserve-commit-order[={OFF|ON}]弃用 8.0.26 系统变量 slave_preserve_commit_order范围 全局 动态 是 SET_VAR提示适用否 类型 布尔值 默认值(≥ 8.0.27) ON默认值(≤ 8.0.26) OFF从 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),因此slave_preserve_commit_order=ON是默认设置,设置slave_parallel_type=LOGICAL_CLOCK也是默认设置。同样从 MySQL 8.0.27 开始,如果将slave_parallel_workers设置为 1,则slave_preserve_commit_order的设置将被忽略,因为在这种情况下,事务的顺序仍然会被保留。截至 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 线程(如果使用多个复制通道,则对所有复制通道的复制 SQL 线程都要停止)。当
slave_preserve_commit_order=OFF被设置时,这是默认设置,多线程复制的副本并行应用的事务可能会无序提交。因此,检查最近执行的事务并不能保证源端的所有先前事务在副本上已执行。副本的中继日志中执行的事务序列可能存在间隙的可能性。这对于使用多线程复制时的日志记录和恢复有影响。更多信息请参见 Section 19.5.1.34, “复制和事务不一致性”。当
slave_preserve_commit_order=ON被设置时,执行的工作线程会等待所有先前的事务提交后再进行提交。当一个线程在等待其他工作线程提交事务时,它会报告其状态为等待前面的事务提交。使用这种模式,多线程复制永远不会进入源端不在的状态。这支持将复制用于读取扩展。更多信息请参见 Section 19.4.5, “使用复制进行扩展”。注意
-
slave_preserve_commit_order=ON不会阻止源二进制日志位置滞后,其中Exec_master_log_pos落后于已执行事务的位置。请参阅 Section 19.5.1.34, “Replication and Transaction Inconsistencies”。 -
slave_preserve_commit_order=ON不会保留副本在其二进制日志上使用过滤器时的提交顺序和事务历史,例如--binlog-do-db。 -
slave_preserve_commit_order=ON不会保留非事务性 DML 更新的顺序。这些更新可能会在中继日志中的先前事务之前提交,这可能导致从副本的中继日志中执行的事务序列中出现间隙。 -
在 MySQL 8.0.19 之前的版本中,
slave_preserve_commit_order=ON在对象不存在时不会保留带有IF EXISTS子句的语句的顺序。这些语句可能会在中继日志中的先前事务之前提交,这可能导致从副本的中继日志中执行的事务序列中出现间隙。 -
如果使用基于语句的复制,并且事务性和非事务性存储引擎参与在源上回滚的非 XA 事务,可能会出现保留副本上提交顺序的限制。通常,在源上回滚的非 XA 事务不会被复制到副本,但在这种特殊情况下,该事务可能会被复制到副本。如果发生这种情况,没有二进制日志记录的多线程副本无法处理事务回滚,因此在这种情况下,副本上的提交顺序会与事务的中继日志顺序发生分歧。
-
-
slave_rows_search_algorithms命令行格式 --slave-rows-search-algorithms=value弃用 8.0.18 系统变量 slave_rows_search_algorithms范围 全局 动态 是 SET_VAR提示适用否 类型 设置 默认值 INDEX_SCAN,HASH_SCAN有效取值 TABLE_SCAN,INDEX_SCAN``INDEX_SCAN,HASH_SCAN``TABLE_SCAN,HASH_SCAN``TABLE_SCAN,INDEX_SCAN,HASH_SCAN(等同于 INDEX_SCAN,HASH_SCAN)在为基于行的日志记录和复制准备行批次时,此系统变量控制如何搜索匹配的行,特别是是否使用哈希扫描。现在已弃用此系统变量。默认设置
INDEX_SCAN,HASH_SCAN对性能最佳,并在所有情况下都能正常工作。请参阅 Section 19.5.1.27, “Replication and Row Searches”。 -
slave_skip_errors命令行格式 --slave-skip-errors=name已弃用 8.0.26 系统变量 slave_skip_errors作用范围 全局 动态 否 SET_VAR提示适用否 类型 字符串 默认值 OFF有效值 OFF``[错误代码列表]``all``ddl_exist_errors从 MySQL 8.0.26 开始,
slave_skip_errors已弃用,应使用别名replica_skip_errors。在 MySQL 8.0.26 之前的版本中,请使用slave_skip_errors。通常情况下,当副本出现错误时,复制过程会停止,这给了你机会手动解决数据不一致性。此变量使得复制 SQL 线程在语句返回变量值中列出的任何错误时继续复制。
-
replica_skip_errors命令行格式 --replica-skip-errors=name引入版本 8.0.26 系统变量 replica_skip_errors作用范围 全局 动态 否 SET_VAR提示适用否 类型 字符串 默认值 OFF有效值 OFF``[错误代码列表]``all``ddl_exist_errors从 MySQL 8.0.26 开始,应使用
replica_skip_errors替代slave_skip_errors,后者从该版本开始已被弃用。在 MySQL 8.0.26 之前的版本中,请使用slave_skip_errors。通常情况下,当副本���现错误时,复制过程会停止,这给了你机会手动解决数据不一致性。此变量使得复制 SQL 线程在语句返回变量值中列出的任何错误时继续复制。
-
slave_sql_verify_checksum命令行格式 --slave-sql-verify-checksum[={OFF|ON}]已弃用 8.0.26 系统变量 slave_sql_verify_checksum范围 全局 动态 是 SET_VARHint Applies否 类型 布尔值 默认值 ON从 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 线程使用从中继日志读取的校验和来验证数据。在出现不匹配时,副本将停止并显示错误。设置此变量立即对所有复制通道生效,包括正在运行的通道。注意
复制 I/O(接收器)线程在从网络接收事件时始终尽可能读取校验和。
-
slave_transaction_retries命令行格式 --slave-transaction-retries=#已弃用 8.0.26 系统变量 slave_transaction_retries范围 全局 动态 是 SET_VARHint Applies否 类型 整数 默认值 10最小值 0最大值(64 位平台) 18446744073709551615最大值(32 位平台) 4294967295从 MySQL 8.0.26 开始,
slave_transaction_retries已弃用,应改用别名replica_transaction_retries。在 MySQL 8.0.26 之前的版本中,请使用slave_transaction_retries。slave_transaction_retries设置单线程或多线程副本上的复制 SQL 线程在停止之前自动重试失败事务的最大次数。设置此变量立即对所有复制通道生效,包括正在运行的通道。默认值为 10。将变量设置为 0 会禁用事务的自动重试。如果复制 SQL 线程由于
InnoDB死锁或因事务执行时间超过InnoDB的innodb_lock_wait_timeout或NDB的TransactionDeadlockDetectionTimeout或TransactionInactiveTimeout而无法执行事务时,它会在停止并报错之前自动重试slave_transaction_retries次。具有非临时错误的事务不会被重试。Performance Schema 表
replication_applier_status显示了每个复制通道上发生的重试次数,在COUNT_TRANSACTIONS_RETRIES列中。Performance Schema 表replication_applier_status_by_worker显示了单线程或多线程副本上各个应用程序线程对事务重试的详细信息,并标识导致最后一个事务和当前正在进行的事务重新尝试的错误。 -
slave_type_conversions命令行格式 --slave-type-conversions=set弃用 8.0.26 系统变量 slave_type_conversions范围 全局 动态 是 SET_VAR提示适用否 类型 集合 默认值 有效值 ALL_LOSSY``ALL_NON_LOSSY``ALL_SIGNED``ALL_UNSIGNED从 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引入版本 8.0.26 系统变量 sql_replica_skip_counter作用域 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 0最小值 0最大值 4294967295从 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时不能将其设置为非零值。如果在使用 GTIDs 时需要跳过事务,请改用源端的gtid_executed。如果已经在复制通道上启用了 GTID 分配,使用CHANGE REPLICATION SOURCE TO语句的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS选项,sql_replica_skip_counter可用。请参见第 19.1.7.3 节,“跳过事务”。重要
如果跳过设置该变量指定的事件数量会导致复制品从事件组中间开始,那么复制品将继续跳过,直到找到下一个事件组的开头并从那一点开始。更多信息,请参见第 19.1.7.3 节,“跳过事务”。
-
sql_slave_skip_counter已弃用 8.0.26 系统变量 sql_slave_skip_counter作用范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 0最小值 0最大值 4294967295从 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时不能设置为非零值。如果在使用 GTIDs 时需要跳过事务,请改用源端的gtid_executed。如果已经在复制通道上启用了 GTID 分配,使用CHANGE REPLICATION SOURCE TO语句的ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS选项,可以使用sql_slave_skip_counter。参见第 19.1.7.3 节,“跳过事务”。重要提示
如果通过设置此变量跳过指定数量的事件会导致副本在事件组中间开始,副本将继续跳过,直到找到下一个事件组的开头并从那里开始。有关更多信息,请参见第 19.1.7.3 节,“跳过事务”。
-
sync_master_info命令行格式 --sync-master-info=#已弃用 8.0.26 系统变量 sync_master_info范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 10000最小值 0最大值 4294967295从 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命令行格式 --sync-relay-log=#系统变量 sync_relay_log范围 全局 动态 是 SET_VARHint Applies否 类型 整数 默认值 10000最小值 0最大值 4294967295如果此变量的值大于 0,则 MySQL 服务器在每写入
sync_relay_log事件到中继日志后将其中继日志同步到磁盘(使用fdatasync())。设置此变量立即对所有复制通道生效,包括正在运行的通道。将
sync_relay_log设置为 0 会导致不对磁盘进行同步;在这种情况下,服务器依赖操作系统定期刷新中继日志的内容,就像对任何其他文件一样。选择值为 1 是最安全的选择,因为在意外停机时,您最多只会丢失一个中继日志事件。然而,这也是最慢的选择(除非磁盘具有带电池备份缓存,这样同步会非常快)。有关在复制品上设置的组合对于意外停机最具弹性的信息,请参阅第 19.4.2 节,“处理复制品的意外停机”。
-
sync_relay_log_info命令行格式 --sync-relay-log-info=#已弃用 8.0.34 系统变量 sync_relay_log_info范围 全局 动态 是 SET_VARHint Applies否 类型 整数 默认值 10000最小值 0最大值 4294967295复制品更新应用程序元数据存储库之后的事务数。当应用程序元数据存储库存储为一个
InnoDB表(MySQL 8.0 及以后版本的默认值),它在每个事务之后更新,此系统变量将被忽略。如果应用程序元数据存储库存储为一个文件(MySQL 8.0 中已弃用),则复制品在此数量的事务之后将其relay-log.info文件同步到磁盘(使用fdatasync())。0(零)表示文件内容仅由操作系统刷新。设置此变量立即对所有复制通道生效,包括正在运行的通道。由于存储应用程序元数据为文件已被弃用,此变量也已被弃用;从 MySQL 8.0.34 开始,服务器在设置或读取其值时会发出警告。您应该期望
sync_relay_log_info在将来的 MySQL 版本中被移除,并立即迁移可能依赖它的应用程序。 -
sync_source_info命令行格式 --sync-source-info=#引入版本 8.0.26 系统变量 sync_source_info范围 全局 动态 是 SET_VAR提示适用否 类型 整数 默认值 10000最小值 0最大值 4294967295从 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命令行格式 --terminology-use-previous=#引入版本 8.0.26 系统变量 terminology_use_previous范围 全局,会话 动态 是 SET_VAR提示适用否 类型 枚举 默认值 NONE有效值 NONE``BEFORE_8_0_26在 MySQL 8.0.26 中,对包含术语
master、slave和mts(代表“多线程从属”)的仪表命名进行了不兼容的更改,分别更改为source、replica和mta(代表“多线程应用程序”)。如果这些不兼容的更改影响到您的应用程序,请将terminology_use_previous系统变量设置为BEFORE_8_0_26,以便 MySQL Server 使用前述列表中指定对象的旧版本名称。这样一来,依赖于旧名称的监控工具将继续工作,直到它们可以更新为使用新名称。将
terminology_use_previous系统变量设置为会话范围以支持个别用户,或者设置为全局范围以成为所有新会话的默认值。当使用全局范围时,慢查询日志包含旧版本的名称。受影响的仪表化名称列在以下列表中。
terminology_use_previous系统变量仅影响这些项目。它不影响在 MySQL 8.0.26 中引入的系统变量、状态变量和命令行选项的新别名,当设置时仍然可以使用这些别名。-
仪表化锁(互斥锁),在具有前缀
wait/synch/mutex/的mutex_instances和events_waits_*性能模式表中可见 -
读/写锁,在具有前缀
wait/synch/rwlock/的rwlock_instances和events_waits_*性能模式表中可见 -
仪表化条件变量,在具有前缀
wait/synch/cond/的cond_instances和events_waits_*性能模式表中可见 -
仪表化内存分配,在具有前缀
memory/sql/的memory_summary_*性能模式表中可见 -
线程名称,在具有前缀
thread/sql/的threads性能模式表中可见 -
线程阶段,在具有前缀
stage/sql/的events_stages_*性能模式表中可见,在threads和processlist性能模式表中没有前缀,在SHOW PROCESSLIST语句的输出中,在信息模式processlist表中,在慢查询日志中 -
线程命令,在具有前缀
statement/com/的events_statements_history*和events_statements_summary_*_by_event_name性能模式表中可见,在threads和processlist性能模式表中没有前缀,在SHOW PROCESSLIST语句的输出中,在信息模式processlist表中,在SHOW REPLICA STATUS语句的输出中
-