20.2.1.2 配置组复制实例

这一节解释配置组复制所需的MySQL Server实例的配置

存储引擎(Storage Engines)

对于组复制而言，数据必须存储在InnoDB事务型存储引擎当中(至于原因可以查看20.3.1，“Group Replication Requirements”)。使用其他的存储引擎，包括临时的memory存储引擎，都可能会导致组复制报错。所以需要按照如下方式设置disabled_storage_engines系统参数：

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

需要注意的是，MyISAM存储引擎被禁用后，当你将MySQL升级到还在使用mysql_upgrade的版本时(也就是MySQL8.0.16之前)，mysql_upgrade可能会失败并返回报错(个人理解升级时有数据库或者表还在使用MyISAM存储引擎，然而配置MGR禁用了该存储引擎，所以会导致报错)。为了解决这个问题，在运行mysql_upgrade的时候需要重新启用MyISAM存储引擎，当重启的时候可以再将其设置为disable

复制框架(Replication Framework)

根据MySQL Group Replication要求配置如下参数：

server_id=1

gtid_mode=ON

enforce_gtid_consistency=ON

如上配置将server唯一标识号设置为1，启用可参考19.1.3节"Replication with Global Trasaction Identifiers",并且仅允许那些可以安全地使用GTID进行日志记录和复制的SQL语句。

在MySQL8.0.20以及之前版本中，需要设置如下参数：

binlog_checksum=NONE

binlog_checksum=NONE

在 MySQL 8.0.20 之前，Group Replication 无法使用校验和，也不支持它们存在于二进制日志中，因此您必须 binlog_checksum=NONE在配置服务器实例时设置为组成员。从 MySQL 8.0.21 开始，Group Replication 支持校验和，因此组成员可以使用默认设置 binlog_checksum=CRC32。组的所有成员的设置binlog_checksum 不必相同。

在MySQL 8.0.20之前的版本中，对于MySQL Group Replication（MGR）来说，设置binlog_checksum=NONE是必要的，原因有以下几点：

二进制日志校验和的支持：在MySQL 8.0.20之前，Group Replication无法使用校验和，也不支持它们存在于二进制日志中。因此，为了确保Group Replication能够正常工作，必须将binlog_checksum设置为NONE1。
复制的限制：早期版本的MySQL在复制过程中可能存在某些限制，特别是在处理二进制日志事件时。通过将binlog_checksum设置为NONE，可以绕过这些与校验和相关的限制，使复制过程更加稳定可靠。

事件验证的考虑：当校验和可用时（即从MySQL 8.0.21开始），Group Replication实际上并不会使用它们来验证group_replication_applier通道上的传入事件，因为事件可能从多个源写入中继日志，并且在它们实际写入原始服务器的二进制日志之前即生成校验和。相反，校验和主要用于验证group_replication_recovery通道和组成员上任何其他复制通道上事件的完整性。

从MySQL 8.0.21开始，由于Group Replication支持了校验和，因此组成员可以使用默认设置binlog_checksum=CRC321。
参考文章链接：https://www.modb.pro/db/584244

这个设置会禁止对写入binlog的事件做校验和(checksum)，默认是启用checksum的。从MySQL8.0.21开始，组复制开始支持在binlog日志中存在checksum，并且使用他们验证一些通道上事件的完整性，所以可以使用默认设置。

binlog_checksum详解
MySQL的binlog_checksum参数原理主要是关于如何确保二进制日志（binlog）中的事件在存储和传输过程中的完整性和一致性。以下是关于binlog_checksum参数原理的详细解释：

CRC32校验和：

当binlog_checksum设置为CRC32时，MySQL会在写入binlog的每个事件时计算一个CRC32校验和，并将这个校验和与该事件一起存储在binlog中1。
这个校验和是用来确认binlog事件在传输和存储过程中是否保持不变的。如果在复制过程中，或者当使用mysqlbinlog工具读取binlog时，事件被修改或损坏，CRC32校验和将会不匹配，从而指示出数据的损坏或修改2。
校验和的计算涉及到对binlog事件数据的特定计算，最终得到一个固定长度的值（CRC32校验和）。这个值可以用于验证数据的完整性3。
校验和验证过程：

在复制过程中，当主服务器（master）写入binlog时，它会为每个事件计算CRC32校验和并存储在binlog中1。
当从服务器（slave）的I/O线程从主服务器读取binlog事件时，它会验证接收到的事件的CRC32校验和是否匹配1。如果不匹配，从服务器会停止复制并报错2。
在从服务器，当SQL线程从relay log中读取事件并准备应用它之前，也会验证事件的CRC32校验和1。
另外，当使用SHOW BINLOG EVENTS命令时，也会触发对binlog事件的CRC32校验和验证1。
NONE选项：

如果binlog_checksum设置为NONE，则MySQL不会在binlog事件中添加任何校验和1。在这种情况下，MySQL通过检查每个事件的长度来验证binlog事件的完整性2。但这种方式相比于CRC32校验和来说，对于数据完整性的保障要弱一些。
总之，binlog_checksum参数允许你控制MySQL是否在binlog事件中添加CRC32校验和，从而帮助你检测和防止在binlog传输和存储过程中可能发生的数据损坏或修改。在大多数情况下，推荐使用CRC32校验和来提高数据的完整性和一致性保障。
参考文章链接如下：
https://blog.51cto.com/u_16099336/8303602
https://www.jianshu.com/p/0957a89d4fb4
https://wenku.baidu.com/view/ce50330e02f69e3143323968011ca300a6c3f686?bfetype=new&_wkts_=1719813565910

如果使用的MySQL版本早于8.0.3，复制还没有得到改进，所以需要在复制成员的配置文件中添加如下参数。如果你在之后的版本中已经存在这些系统变量，那么确保和如下示例进行配置：

log_bin=binlog

log_slave_updates=ON

binlog_format=ROW

master_info_repository=TABLE

relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64

组复制设置

按照如下参数进行配置参数文件，确保按照如下参数对复制结构进行实例化：

plugin_load_add='group_replication.so'

group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=off group_replication_local_address= "s1:33061" group_replication_group_seeds= "s1:33061,s2:33061,s3:33061" group_replication_bootstrap_group=off

 plugin-load-add参数：将Group Replication插件加入到Server启动时加载的插件列表当中。在部署生产环境时，这种方式比手动部署更加可取。

配置group_replication_group_name会告诉插件，正在加入组，或者创建的组的名字为"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"(简单理解就是复制组的名称)。

        group_replication_group_name参数值必须是一个有效的UUID。你可以使用select UUID()生成一个。这个 UUID 是 GTID（全局事务标识符）的一部分，当组成员从客户端接收事务，以及由组成员内部生成的视图更改事件被写入二进制日志时，这些 GTID 会被使用。

配置group_replication_start_on_boot参数为off，当Server(MySQL实例)启动时组复制插件不会自动启动。这个在配置组复制的时候是非常重要的，可以在手动启动插件之前确保你可以进行配置server。一旦配置组成员group_replication_start_on_boot=ON,那么server启动的时候组复制会自动启动。

配置group_replication_local_address参数设置组复制成员内部交流使用的网络地址和端口。组复制使用此地址进行涉及组通信引擎（XCom，Paxos的一个变种）的远程实例的内部成员到成员的连接。

个人理解：这里的“远程实例”指的是在组通信引擎（XCom）中的不同服务器或节点。由于组复制可能涉及多个服务器，因此每个服务器上的XCom实例都可以视为一个“远程实例”

重要：

组复制本地地址必须与用于SQL客户端连接的主机名和端口不同，这些连接由MySQL服务器的hostname和port系统变量定义。这个地址不应该被客户端应用程序使用。它仅应在运行组复制时用于组成员之间的内部通信。

比如hostname=test port=3306这个就是外部使用的

group_replication_local_address= "s1:33061"这个定义的地址就是内部通信使用

 通过group_replication_local_address配置的地址必须可以被组内成员解析。比如说如果在不同机器上的每一个server实例都有固定的网络地址，你可以使用机器的IP地址，比如10.0.0.1.如果你使用的主机名，那么你就必须使用全名，并且需要确保可以被DNS解析。通过正确的配置/etc/hosts文件，或者其他的的名称解决程序等。从MySQL8.0.13开始，IPV6(或者可以解析IPV6的主机名)也可以和IPV4一样进行使用。一个组也可以既包含IPV6又可以包含IPV4.

group_replication_local_address端口号建议配置为33061.group_replication_local_address是在组成员内部可以被用来做唯一标识。你可以使用对所有的组成员相同的端口只要主机名或者IP地址不同就行，你也可以使用主机名或者IP想通但是需要端口号不同 。例如在第20.2.2节“本地部署组复制”中所示。

现有成员为加入的成员提供的用于组复制分布式恢复过程的连接并不是通过group_replication_local_address配置的网络地址。在MySQL 8.0.20及之前版本中，组成员为加入的成员提供的分布式恢复连接是标准的SQL客户端连接，这些连接由MySQL服务器的hostname和port系统变量指定。从MySQL 8.0.21开始，组成员可以发布一个替代的分布式恢复端点列表，作为专门用于加入成员的客户端连接。更多详情，请参见第20.5.4.1节，“分布式恢复的连接”。

重要：

如果加入组复制的成员没有正确的通过hostname变量定义的主机名识别到其他成员，那么分布式恢复会失败。强烈建议运行MySQL的操作系统都配置了合适且唯一的主机名，要么使用DNS或者本地配置。用于SQL客户端连接的server的主机名可以在performance_schema中的replication_group_members中的member_host列中验证。如果多个组成员使用操作系统设置的默认主机名进行外部化，那么加入的成员可能无法将其解析为正确的成员地址，从而无法进行分布式恢复。在这种情况下，您可以使用MySQL服务器的report_host系统变量为每个服务器配置一个唯一的主机名以进行外部化。

理解：

在MySQL组复制环境中，成员之间的正确识别至关重要，这涉及到分布式恢复等功能的正常工作。默认情况下，MySQL服务器会使用hostname系统变量中定义的主机名来标识自己。然而，如果操作系统没有为MySQL服务器分配一个独特且正确解析的主机名，那么在加入新的组成员时，它可能无法正确地找到并连接到其他组成员，从而导致分布式恢复失败。

为了避免这种情况，建议确保运行MySQL的操作系统具有正确配置的唯一主机名，可以通过DNS服务或本地配置（如/etc/hosts文件）来实现。此外，MySQL提供了一个report_host系统变量，允许管理员为每个服务器配置一个用于外部化的唯一主机名。这样，即使操作系统的默认主机名设置相同，MySQL服务器也可以通过report_host提供的独特名称进行识别和连接，从而确保分布式恢复的顺利进行。

个人理解report_host类似于给主机名做rename的操作已达到集群环境中主机名不同的作用,这个暂时还未验证，如果理解有误，请各位帮忙指正(谢谢)

group_replication_group_seeds为新成员连接到组中设置组成员的主机名和端口，这些成员成为种子成员。一旦连接建立，那么组成员服务(group membership)信息就会被更新在performance_schema中的replication_group_members中。通常group_replication_group_seeds列表包含了每一个组成员的hostname:port(也就是每一个成员的group_replication_local_address)，但这个不是必须的也可以包含种子成员的一部分作为种子。

在MySQL组复制（Group Replication）中，新成员加入组时需要一个或多个现有成员来作为它建立连接的起点，这些成员被称为种子成员（seed members）。group_replication_group_seeds系统变量用于配置这些种子成员的信息，这些信息通常包括种子成员的主机名和端口。

种子成员的作用：种子成员是组复制中用于新成员加入组的起始点。当新成员尝试加入组时，它会尝试与group_replication_group_seeds中列出的一个或多个种子成员建立连接。一旦连接成功，新成员就可以从种子成员那里获取关于组的更多信息，并最终加入组。

**配置group_replication_group_seeds**：通常，这个变量会包含组中每个成员的group_replication_local_address所指定的主机名和端口。但是，这并不是必须的。你可以只选择组中的一部分成员作为种子，只要这些种子成员能够确保新成员能够成功加入组即可。

**性能模式表replication_group_members**：一旦新成员成功加入组，组的成员信息就会被列在性能模式表replication_group_members中。这个表包含了关于组成员的详细信息，如主机名、端口、角色、状态等。通过查询这个表，你可以获取关于组的实时成员信息。

重要：

在group_replication_group_seeds中列出的hostname:port是种子成员的内部网络地址，这个地址是由group_replication_local_address配置的，而不是用于SQL客户端连接的hostname:port。例如，用于SQL客户端连接的hostname:port可以在性能模式表replication_group_members中看到。

启动组的服务器不使用这个选项，因为它是初始服务器，因此负责引导（启动）该组。换句话说，任何已经存在于引导组的服务器上的数据都将用作下一个加入成员的数据。第二个加入的服务器会请求组中的唯一成员加入，第二个服务器上缺少的任何数据都会从引导成员的捐赠数据中复制过来，然后组会扩大。第三个加入的服务器可以向这两个成员中的任何一个请求加入，数据会同步到新的成员，然后组再次扩大。后续服务器在加入时会重复这个过程。

注意：

在同时加入多个服务器时，请确保它们指向的是已经在组中的种子成员。不要使用也正在加入组的成员作为种子，因为当尝试联系它们时，它们可能还没有在组中。

好的做法是先启动引导成员，并让它创建组。然后将其作为剩余要加入的成员的种子成员。这样可以确保在加入剩余成员时已经形成了一个组。

同时创建组和加入多个成员是不被支持的。虽然它可能会成功，但很有可能出现操作竞争，导致加入组的过程出现错误或超时。

在MySQL组复制中，当一个新的成员尝试加入组时，它必须能够使用与种子成员相同的网络协议（IPv4或IPv6）来与种子成员通信。这是因为组复制需要在成员之间保持稳定的网络连接以进行数据同步。

为了确保通信的安全性和可靠性，种子成员会有一个允许列表（allowlist），该列表包含允许与其通信的IP地址或主机名。对于正在加入的成员，其IP地址或主机名（如果解析为与种子成员相同的协议地址）必须被添加到这个允许列表中。

这里特别要注意的是，如果加入成员的group_replication_local_address所使用的协议（IPv4或IPv6）与种子成员在group_replication_group_seeds中公告的协议不匹配，那么除了group_replication_local_address之外，还需要为那个不同的协议额外设置并允许一个IP地址或主机名。

如果加入成员没有为适当的协议设置允许的地址，那么它将无法与种子成员建立连接，从而无法成功加入组。这是为了确保只有经过授权的成员才能加入组，从而增强组的安全性。

配置group_replication_bootstrap_group会指示插件是否要引导（bootstrap）该组。在这种情况下，即使s1是组的第一个成员，我们也在选项文件中将此变量设置为off。相反，我们在实例运行时配置group_replication_bootstrap_group，以确保只有一个成员实际引导该组。

在MySQL组复制中，引导（bootstrap）是指创建一个新的复制组的过程。当第一个服务器启动时，它可以选择引导一个新的组，这意味着它会初始化组的状态和配置。但是，为了确保只有一个服务器执行此操作（因为如果有多个服务器同时尝试引导组，会导致问题），我们通常在选项文件中不设置group_replication_bootstrap_group为on。

相反，我们选择在服务器实例运行时动态地设置这个变量。这样，我们可以确保在组复制插件开始尝试加入或创建组之前，只有一个服务器（即第一个启动的服务器）设置了这个变量为on，从而引导该组。其他服务器在加入时，这个变量应该设置为off，以避免它们也尝试引导组。

group_replication_bootstrap_group变量在任何时候都只能在属于一个组的一个服务器实例上启用，通常是在你第一次引导（bootstrap）该组时（或者在整个组被关闭并重新启动时）。

如果你多次引导组，例如当多个服务器实例都设置了此选项时，它们可能会创建一个人为的分裂脑（split-brain）场景，其中存在两个具有相同名称的不同组。

在第一个服务器实例上线后，务必将group_replication_bootstrap_group设置为off。

本教程中描述的系统变量是启动新成员所需的配置设置，但还有更多系统变量可用于配置组成员。可参考第20.9节

许多系统变量，其中一些是特定于组复制的，而其他则不是，是组范围的配置设置，必须在所有组成员上具有相同的值。如果组成员为其中一个系统变量设置了值，而加入的成员为该变量设置了不同的值，则加入的成员无法加入该组，并会返回一条错误消息。如果组成员为该系统变量设置了值，而加入的成员不支持该系统变量，它也无法加入该组。这些系统变量都在“20.9节，组复制变量”中进行了标识。