# 18.3.1 组复制要求
您要用于组复制的服务器实例必须满足以下要求。
# 基础设施
**InnoDB 存储引擎。**数据必须存储在
InnoDB
事务存储引擎。事务以乐观的方式执行,然后在提交时检查是否存在冲突。如果存在冲突,为了保持整个组的一致性,会回滚一些事务。这意味着需要事务存储引擎。而且,InnoDB
提供一些附加功能,以便在与 Group Replication 一起操作时更好地管理和处理冲突。使用其他存储引擎,包括临时记忆
存储引擎,可能会导致组复制错误。您可以通过设置disabled_storage_engines
组成员的系统变量,例如:disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
**主键。**组要复制的每个表都必须具有定义的主键,或等效的主键,其中等效键是非空唯一键。此类键需要作为表中每一行的唯一标识符,使系统能够通过准确识别每个事务修改了哪些行来确定哪些事务冲突。Group Replication 对主键或主键等效项有自己的内置检查集,并且不使用由
sql_require_primary_key
系统变量。你可以设置sql_require_primary_key=开启
对于正在运行组复制的服务器实例,您可以设置REQUIRE_TABLE_PRIMARY_KEY_CHECK
的选项将复制源更改为
|将主更改为
声明在
对于组复制通道。但是,请注意,您可能会发现某些在 Group Replication 的内置检查下允许的事务在您设置时执行的检查下是不允许的sql_require_primary_key=ON
或需要_TABLE_PRIMARY_KEY_CHECK=ON
.**网络性能。**MySQL组复制旨在部署在服务器实例彼此非常接近的集群环境中。网络延迟和网络带宽都会影响组的性能和稳定性。所有团队成员之间必须始终保持双向沟通。如果服务器实例的入站或出站通信被阻止(例如,防火墙或连接问题),则该成员无法在组中运行,并且组成员(包括有问题的成员)可能无法报告受影响服务器实例的正确成员状态。
在MySQL 8.0.14中,您可以使用IPv4或IPv6网络基础设施,或两者的混合,在远程组复制服务器之间进行TCP通信。也没有什么可以阻止组复制在虚拟专用网络(VPN)上运行。
在MySQL 8.0.14中,组复制服务器实例位于同一位置,并共享一个本地组通信引擎(XCom)实例。在可能的情况下,使用一个开销较低的专用输入通道来进行通信,而不是使用TCP套接字。对于某些需要在远程XCom实例之间进行通信的组复制任务,例如加入组,仍然使用TCP网络,因此网络性能会影响组的性能。
# 服务器实例配置
必须按照作为组成员的服务器实例所示配置以下选项。
**唯一的服务器标识符。**使用
服务器id
系统变量,用于根据复制拓扑中所有服务器的要求,使用唯一的服务器ID配置服务器。服务器ID必须是介于1和(2)之间的正整数32)−1,并且它必须不同于复制拓扑中任何其他服务器使用的所有其他服务器ID。**二进制日志处于活动状态。**设置
--日志箱[=日志文件名]
.在MySQL 8.0中,默认情况下会启用二进制日志记录,除非您想更改二进制日志文件的名称,否则无需指定此选项。组复制复制复制二进制日志的内容,因此需要打开二进制日志才能运行。看见第5.4.4节,“二进制日志”.**已记录副本更新。**设置
log_replica_updates=ON
(来自MySQL 8.0.26)或log_slave_updates=ON
(MySQL 8.0.26之前)。在MySQL 8.0中,此设置是默认设置,因此无需指定。集团成员需要记录加入时从捐赠者处收到并通过复制应用程序应用的交易,并记录他们从集团收到和应用的所有交易。这使组复制能够通过状态转移从现有组成员的二进制日志执行分布式恢复。**二进制日志行格式。**设定
binlog_格式=行
。此设置是默认设置,因此无需指定。组复制依赖于基于行的复制格式在组中的服务器之间一致地传播更改,并提取必要的信息,以检测在组中不同服务器上并发执行的事务之间的冲突。在MySQL 8.0.19中需要行格式
设置会自动添加到组复制的通道中,以在应用事务时强制使用基于行的复制。看见第17.2.1节,“复制格式”和第17.3.3节,“复制权限检查”.**二进制日志校验和关闭(到MySQL 8.0.20)。**MySQL 8.0.20及以下版本,已设置
binlog_校验和=无
。在这些版本中,组复制无法使用校验和,并且不支持它们出现在二进制日志中。在MySQL 8.0.21中,组复制支持校验和,因此组成员可以使用默认设置binlog_校验和=CRC32
,您不需要指定它。**上的全局事务标识符。**设定
gtid_模式=开启
和强制_gtid_consistence=ON
。这些设置不是默认设置。组复制需要基于GTID的复制,它使用全局事务标识符来跟踪组中每个服务器实例上提交的事务。看见第17.1.3节,“使用全局事务标识符的复制”.**复制信息存储库。**设定
master_info_repository=表格
和中继日志信息存储库=表
.在MySQL 8.0中,这些设置是默认设置文件
不推荐使用此设置。在MySQL 8.0.23中,不推荐使用这些系统变量,因此省略系统变量,只允许使用默认值。复制应用程序需要将复制元数据写入mysql。奴隶主信息
和mysql。从属继电器日志信息
系统表,以确保组复制插件对复制元数据具有一致的可恢复性和事务管理。看见第17.2.4.2节,“复制元数据存储库”.**事务写入集提取。**设定
事务_写入_集_提取=XXHASH64
因此,在收集行以将其记录到二进制日志时,服务器也会收集写集。在MySQL 8.0中,此设置是默认设置,在MySQL 8.0.26中,不推荐使用系统变量。写入集基于每一行的主键,是一个标记的简化和紧凑视图,该标记唯一标识已更改的行。组复制使用此信息对所有组成员进行冲突检测和认证。**默认表加密。**设定
默认\u表\u加密
在所有组成员上设置相同的值。可以启用默认模式和表空间加密(在…上
)还是残疾(关
,默认设置),只要所有成员上的设置相同。**小写表格名称。**设定
小写字母表名称
在所有组成员上设置相同的值。设置为1是正确的InnoDB
存储引擎,这是组复制所必需的。请注意,此设置不是所有平台上的默认设置。**二进制日志依赖项跟踪。**背景
binlog_事务_依赖关系_跟踪=WRITESET_会话
可以提高组成员的性能,具体取决于组的工作量。在应用中继日志中的事务时,组复制在认证后执行自己的并行化,而不受为binlog_事务_依赖关系_跟踪
.然而binlog_事务_依赖关系_跟踪
不会影响将事务写入组复制成员的二进制日志的方式。这些日志中的依赖项信息用于协助从捐赠者的二进制日志进行状态转移的过程,以实现分布式恢复,该过程在成员加入或重新加入组时发生。**多线程应用程序。**组复制成员可以配置为多线程副本,从而使事务能够并行应用。在MySQL 8.0.27中,所有副本默认配置为多线程。系统变量的非零值
复制并行工作人员
(来自MySQL 8.0.26)或奴隶工人
(MySQL 8.0.26之前)在成员上启用多线程应用程序。MySQL 8.0.27的默认值是4个并行applier线程,最多可以指定1024个并行applier线程。对于多线程副本,还需要以下设置,这是MySQL 8.0.27中的默认设置:副本保存提交顺序=开启
(来自MySQL 8.0.26)或slave_preserve_commit_order=ON
(MySQL 8.0.26之前)需要此设置以确保并行事务的最终提交顺序与原始事务相同。组复制依赖于围绕保证所有参与成员以相同的顺序接收和应用提交的事务而构建的一致性机制。
副本\并行\类型=逻辑\时钟
(来自MySQL 8.0.26)或从并行时钟类型=逻辑时钟
(MySQL 8.0.26之前)此设置是必需的
副本保存提交顺序=开启
或slave_preserve_commit_order=ON
。它指定用于决定允许在复制副本上并行执行哪些事务的策略。背景
副本\u并行\u工作者=0
或从并行工人=0
禁用并行执行,并为复制副本提供一个应用程序线程,而不提供协调程序线程。在这样的环境下副本\u并行\u类型
或从并行型
和副本保存提交顺序
或奴隶_保存_提交_命令
选项无效,将被忽略。从MySQL 8.0.27开始,如果在副本上使用GTID时禁用并行执行,那么副本实际上使用一个并行工作程序,以利用该方法重试事务,而不访问文件位置。但是,这种行为不会对用户造成任何改变。**分离XA事务。**MySQL 8.0.29及更高版本支持分离的XA事务。分离的事务是一个一旦准备好就不再连接到当前会话的事务。作为执行的一部分,这会自动发生
XA准备
。准备好的XA事务可以由另一个连接提交或回滚,然后当前会话可以启动另一个XA事务或本地事务,而无需等待刚刚准备完成的事务。启用分离XA事务支持时(
xa_detach_on_prepare=on
)可以列出与此服务器的任何连接(使用XA恢复
)、回滚或提交任何准备好的XA事务。此外,不能在分离的XA事务中使用临时表。通过设置
xa_分离_上_准备
到关
,但不建议这样做。特别是,如果将此服务器设置为MySQL组复制中的实例,则应将此变量设置为其默认值(在…上
).看见第13.3.8.2节,“XA事务状态”,以获取更多信息。