本文主要是介绍【MGR】MySQL Group Replication快速开始，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
17.2 Getting Started
17.2.1 Deploying Group Replication in Single-Primary Mode
17.2.1.1 Deploying Instances for Group Replication
17.2.1.2 Configuring an Instance for Group Replication
Storage Engines
Replication Framework
Group Replication Settings
plugin-load-add
group_replication_group_name
group_replication_start_on_boot
group_replication_local_address
group_replication_group_seeds
group_replication_bootstrap_group
17.2.1.3 User Credentials
17.2.1.4 Launching Group Replication
17.2.1.5 Bootstrapping the Group
17.2.1.6 Adding Instances to the Group
17.2.1.6.1 Adding a Second Instance
17.2.1.6.2 Adding Additional Instances
17.2 Getting Started
MySQL Group Replication作为MySQL服务器的插件提供；组中的每个服务器都需要配置和安装该插件。本节提供了一个详细的教程，介绍了创建至少三个成员的复制组所需的步骤。
提示
部署多个MySQL实例的另一种方法是使用InnoDB Cluster，它使用Group Replication并将其封装在一个编程环境中，使您可以在MySQL Shell 8.0中轻松处理MySQL服务器实例组。此外，InnoDB Cluster与MySQL Router无缝交互，并简化了具有高可用性的MySQL部署。请参阅MySQL AdminAPI。
17.2.1 Deploying Group Replication in Single-Primary Mode
在一个组中，每个MySQL服务器实例都可以在独立的物理主机上运行，这是部署Group Replication的推荐方式。本节将介绍如何创建一个由三个MySQL服务器实例组成的复制组，每个实例运行在不同的主机上。有关在同一台主机上部署运行Group Replication的多个MySQL服务器实例的信息，请参阅第17.2.2节，“本地部署Group Replication”。例如，用于测试目的。
Figure 17.4 Group Architecture
这个教程将解释如何获取和部署带有Group Replication插件的MySQL服务器，如何在创建组之前配置每个服务器实例，并如何使用性能模式监视来验证一切是否正常工作。
17.2.1.1 Deploying Instances for Group Replication
第一步是部署至少三个 MySQL Server 实例，该过程演示了在多个主机上使用实例，命名为 s1、s2 和 s3。假定每个主机上都安装了 MySQL Server（请参阅第 2 章，“安装和升级 MySQL”）。Group Replication 插件随 MySQL Server 5.7.17 及更高版本一起提供；不需要额外的软件，但必须在运行的 MySQL 服务器中安装该插件。有关部署 Group Replication 实例的更多信息，请参阅第 17.2.1.1 节，“部署用于 Group Replication 的实例”；有关其他信息，请参阅第 5.5 节，“MySQL Server 插件”。
在本示例中，使用三个实例来组成组，这是创建组的最少实例数。添加更多实例会增加组的容错能力。例如，如果组由三个成员组成，在一个实例失败的情况下，组可以继续运行。但在另一个失败的情况下，组将无法继续处理写事务。通过添加更多实例，组在继续处理事务的同时可以容忍更多服务器的故障。可用于组的最大实例数为九个。有关更多信息，请参阅第 17.1.3.2 节，“故障检测”。
17.2.1.2 Configuring an Instance for Group Replication
这一部分解释了用于 Group Replication 的 MySQL Server 实例所需的配置设置。有关背景信息，请参阅第 17.3 节，“要求和限制”。
- 存储引擎
- 复制框架
- Group Replication 设置
Storage Engines
对于 Group Replication，数据必须存储在 InnoDB 事务存储引擎中（有关原因的详细信息，请参阅第 17.3.1 节，“Group Replication 要求”）。使用其他存储引擎，包括临时的 MEMORY 存储引擎，可能会在 Group Replication 中引发错误。请按照以下方式设置 disabled_storage_engines 系统变量以防止它们的使用：
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"请注意，如果禁用了 MyISAM 存储引擎，则在将 MySQL 实例升级到仍然使用 mysql_upgrade 的版本（MySQL 8.0.16 之前），mysql_upgrade 可能会失败并显示错误。为了处理这个问题，在运行 mysql_upgrade 时，您可以重新启用该存储引擎，然后在重新启动服务器时将其禁用。有关更多信息，请参阅第 4.4.7 节，“mysql_upgrade — 检查和升级 MySQL 表”。
Replication Framework
以下设置根据 MySQL Group Replication 的要求配置复制。
server_id=1 # 配置服务器使用唯一标识号码 1
gtid_mode=ON # 启用GTID
enforce_gtid_consistency=ON
master_info_repository=TABLE # 复制元数据存储在系统表中而不是文件中
relay_log_info_repository=TABLE # 复制元数据存储在系统表中而不是文件中
binlog_checksum=NONE # 禁用二进制日志事件校验
log_slave_updates=ON
log_bin=binlog # 服务器打开二进制日志记录
binlog_format=ROW # 使用基于行的格式
有关更多详细信息，请参阅第 17.3.1 节，“Group Replication 要求”。
Group Replication Settings
此时，选项文件确保服务器已配置，并被指示在给定配置下实例化复制基础设施。以下部分为服务器配置了 Group Replication 设置。
plugin_load_add='group_replication.so'
transaction_write_set_extraction=XXHASH64
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=offplugin-load-add
plugin-load-add命令将Group Replication插件添加到服务器在启动时加载的插件列表中。在生产部署中，这比手动安装插件更可取。
group_replication_group_name
配置group_replication_group_name告知插件，它正在加入或创建的组名为"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"。
group_replication_group_name的值必须是有效的UUID。此UUID在为二进制日志中的Group Replication事件设置GTID时内部使用。您可以使用SELECT UUID()生成UUID。
group_replication_start_on_boot
将group_replication_start_on_boot变量配置为off会指示插件在服务器启动时不自动启动操作。这在设置Group Replication时很重要，因为它确保您可以在手动启动插件之前配置服务器。一旦成员配置好，您可以将group_replication_start_on_boot设置为on，以便在服务器引导时自动启动Group Replication。
意思是先设置为OFF，配置好之后再设置为ON
group_replication_local_address
配置group_replication_local_address设置成员用于与组中其他成员进行内部通信的网络地址和端口。Group Replication使用此地址进行涉及组通信引擎（XCom，一种Paxos变体）的远程实例的内部成员之间的连接。
重要提示
此地址必须与用于SQL的主机名和端口不同，并且不能用于客户端应用程序。它只能用于在运行Group Replication时组内成员之间的内部通信。
由group_replication_local_address配置的网络地址必须由所有组成员解析。例如，如果每个服务器实例位于具有固定网络地址的不同计算机上，您可以使用机器的IP地址，例如10.0.0.1。如果使用主机名，必须使用完全限定名称，并确保通过DNS、正确配置的/etc/hosts文件或其他名称解析进程进行解析。从MySQL 8.0.14开始，还可以使用IPv6地址（或解析为其的主机名），以及IPv4地址。一个组可以包含使用IPv6和使用IPv4的成员的混合。有关IPv6网络的Group Replication支持以及混合IPv4和IPv6组的更多信息，请参阅IPv6和混合IPv6和IPv4组的支持。
group_replication_local_address的推荐端口是33061。group_replication_local_address由Group Replication用作复制组中组成员的唯一标识符。只要主机名或IP地址不同，您就可以为所有复制组成员使用相同的端口，如本教程所示。或者，您可以为所有成员使用相同的主机名或IP地址，只要端口都不同，例如在第17.2.2节“在本地部署Group Replication”中所示。
group_replication_group_seeds
配置group_replication_group_seeds设置用于新成员建立与组的连接的组成员的主机名和端口。这些成员称为种子成员。建立连接后，组成员信息将列在performance_schema.replication_group_members中。通常，group_replication_group_seeds列表包含每个组成员的group_replication_local_address的主机名:端口，但这不是强制性的，可以选择组成员的子集作为种子。
重要提示
group_replication_group_seeds中列出的主机名:端口是种子成员的内部网络地址，由group_replication_local_address配置，而不是用于客户端连接的SQL主机名:端口，并且在performance_schema.replication_group_members表中显示。
启动组的服务器不使用此选项，因为它是初始服务器，因此负责引导组。换句话说，引导组的服务器上存在的任何现有数据都将用作下一个加入成员的数据。加入的第二个服务器询问组中唯一的成员加入，第二个服务器上缺失的任何数据都会从引导组成员的捐赠数据中复制，然后组扩展。加入的第三个服务器可以询问其中任何两个以加入，数据会与新成员同步，然后组再次扩展。加入时，后续服务器重复此过程。
警告
同时加入多个服务器时，请确保它们指向已在组中的种子成员。不要使用也正在加入组的成员作为种子，因为当联系时，它们可能尚未加入组。
最好先启动引导成员，并让它创建组。然后使其成为加入的其他成员的种子成员。这可以确保在加入其他成员时形成了一个组。
不支持同时创建组并加入多个成员。可能会起作用，但很可能会发生操作竞争，然后加入组的行为最终导致错误或超时。
group_replication_bootstrap_group
配置group_replication_bootstrap_group指示插件是否引导组。在这种情况下，即使s1是组的第一个成员，我们也将此变量设置为选项文件中的off。相反，我们在实例运行时配置group_replication_bootstrap_group，以确保只有一个成员实际引导组。
重要提示
group_replication_bootstrap_group变量必须在组中的一个服务器实例上启用，通常是第一次引导组时（或在整个组被关闭并重新启动时）。如果多次引导组，例如，当多个服务器实例具有此选项设置时，则它们可能会创建一个人工分裂脑场景，其中存在具有相同名称的两个不同组。始终在第一个服务器实例上线后设置group_replication_bootstrap_group=off。
组中所有服务器的配置非常相似。您需要更改有关每个服务器的具体信息（例如server_id、datadir、group_replication_local_address）。这在本教程的后续部分中有所说明。
17.2.1.3 User Credentials
Group Replication利用异步复制协议来实现第17.9.5节“分布式恢复”，在将其加入组之前同步组成员。分布式恢复过程依赖于一个名为group_replication_recovery的复制通道，该通道用于将事务从捐赠成员传输到加入组的成员。因此，您需要设置一个具有正确权限的复制用户，以便Group Replication可以建立直接成员之间的恢复复制通道。
启动MySQL服务器实例，然后连接到客户端。使用REPLICATION SLAVE权限创建一个MySQL用户。此过程可以在二进制日志中捕获，然后您可以依靠分布式恢复来复制用于创建用户的语句。或者，您可以使用SET SQL_LOG_BIN=0;禁用二进制日志记录，然后在每个成员上手动创建用户，例如，如果您希望避免更改传播到其他服务器实例。如果决定禁用二进制日志记录，请确保在配置用户后重新启用它。
在以下示例中，显示了用户名为rpl_user，密码为password的用户。在配置服务器时，请使用合适的用户名和密码。
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
mysql> FLUSH PRIVILEGES;如果已禁用二进制日志记录，请在创建用户后再次启用它，使用SET SQL_LOG_BIN=1;。
一旦用户已配置好，使用CHANGE MASTER TO语句配置服务器，在下一次需要从另一个成员恢复其状态时，使用给定的凭据为group_replication_recovery复制通道。执行以下操作，将rpl_user和password替换为创建用户时使用的值。
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\FOR CHANNEL 'group_replication_recovery';分布式恢复是加入组的服务器采取的第一步，该服务器与组成员具有不同的事务集。如果未正确设置这些凭据以用于group_replication_recovery复制通道和如上所示的rpl_user，则服务器无法连接到捐赠成员并运行分布式恢复过程以与其他组成员同步，因此最终无法加入该组。请参阅第17.9.5节“分布式恢复”。
同样，如果服务器无法通过服务器的主机名正确识别其他成员，则恢复过程可能会失败。建议运行MySQL的操作系统具有经过正确配置的唯一主机名，可以使用DNS或本地设置。此主机名可以在performance_schema.replication_group_members表的Member_host列中进行验证。如果多个组成员将由操作系统设置的默认主机名外部化，则有可能会导致成员无法解析为正确的成员地址而无法加入该组。在这种情况下，请使用report_host为每个服务器配置一个唯一的主机名进行外部化。
17.2.1.4 Launching Group Replication
首先必须确保在服务器s1上安装了Group Replication插件。如果您在选项文件中使用了plugin_load_add='group_replication.so'，那么Group Replication插件已经安装了，您可以继续下一步。否则，您必须手动安装插件；要做到这一点，请使用mysql客户端连接到服务器，并执行下面显示的SQL语句：
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';重要提示：
在加载Group Replication之前，必须存在mysql.session用户。mysql.session用户是在MySQL版本5.7.19中添加的。如果您的数据字典是使用早期版本初始化的，则必须执行MySQL升级过程（请参阅第2.10节“升级MySQL”）。如果未运行升级，则Group Replication无法启动，并显示错误消息：尝试使用用户mysql.session@localhost访问服务器时出错。确保用户存在于服务器中，并且在服务器更新后运行了mysql_upgrade。
要检查插件是否成功安装，请执行SHOW PLUGINS; 并检查输出。它应该显示类似于以下内容：
mysql> SHOW PLUGINS;
+----------------------------+----------+--------------------+----------------------+-------------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+-------------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | PROPRIETARY |(...)| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | PROPRIETARY |
+----------------------------+----------+--------------------+----------------------+-------------+17.2.1.5 Bootstrapping the Group
第一次启动组的过程称为引导。您可以使用group_replication_bootstrap_group系统变量引导组。引导应该只由单个服务器完成，即启动组的服务器，并且只执行一次。这就是为什么group_replication_bootstrap_group选项的值没有存储在实例的选项文件中。如果保存在选项文件中，服务器在重新启动时将自动用相同名称引导第二个组。这将导致具有相同名称的两个不同组。同样的推理也适用于将此选项设置为ON停止和重新启动插件。因此，为了安全地引导组，请连接到s1并执行以下操作：
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;一旦START GROUP_REPLICATION语句返回，组就已经启动了。您可以检查组是否已经创建，并且其中有一个成员：
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | s1 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+该表中的信息确认了该组中有一个成员，其唯一标识符为ce9be252-2b71-11e6-b8f4-00212844f856，它处于ONLINE状态，并且在s1上通过端口3306监听客户端连接。
为了证明服务器确实处于一个组中并且能够处理请求，创建一个表并向其中添加一些内容。
mysql> CREATE DATABASE test;
mysql> USE test;
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
mysql> INSERT INTO t1 VALUES (1, 'Luis');mysql> SELECT * FROM t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+mysql> SHOW BINLOG EVENTS;
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 1 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 1 | 150 | |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN |
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724817264259180:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT |
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| binlog.000001 | 831 | Query | 1 | 899 | BEGIN |
| binlog.000001 | 899 | Table_map | 1 | 942 | table_id: 108 (test.t1) |
| binlog.000001 | 942 | Write_rows | 1 | 984 | table_id: 108 flags: STMT_END_F |
| binlog.000001 | 984 | Xid | 1 | 1011 | COMMIT /* xid=38 */ |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+如上所述，已创建数据库和表对象，并编写了它们对应的DDL语句，并将这些操作记录到二进制日志中。此外，数据已插入到表中，并记录到二进制日志中。二进制日志条目的重要性在后续部分得到了说明，当组扩展并执行分布式恢复时，新成员试图追赶并上线时。
17.2.1.6 Adding Instances to the Group
此时，该组中有一个成员，即服务器s1，在其中有一些数据。现在是时候通过添加先前配置的另外两台服务器来扩展该组了。
17.2.1.6.1 Adding a Second Instance
要添加第二个实例，即服务器s2，首先创建其配置文件。配置与用于服务器s1的配置类似，但是像server_id这样的一些项会有所不同。以下清单中突出显示了这些不同的行。
[mysqld]#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s2:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off与设置服务器s1的过程类似，配置文件准备就绪后，启动服务器。然后按如下配置恢复凭据。这些命令与设置服务器s1时使用的命令相同，因为用户在组内是共享的。这个成员需要在第17.2.1.3节“用户凭证”中配置相同的复制用户。如果您依赖分布式恢复来在所有成员上配置用户，则当s2连接到种子s1时，复制用户将被复制到s1。如果在配置了s1的用户凭证时没有启用二进制日志记录，则必须在s2上创建复制用户。在这种情况下，连接到s2并发出以下命令：
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\FOR CHANNEL 'group_replication_recovery';如有必要，安装Group Replication插件，请参阅第17.2.1.4节“启动Group Replication”。
启动Group Replication，并让s2开始加入组的过程。
mysql> START GROUP_REPLICATION;与在s1上执行的先前步骤不同的是，在这里存在一个区别，即您无需引导该组，因为该组已经存在。换句话说，在s2上，group_replication_bootstrap_group设置为off，您在启动Group Replication之前不需要发出SET GLOBAL group_replication_bootstrap_group=ON;命令，因为组已经由服务器s1创建和引导了。此时，服务器s2只需要被添加到已经存在的组中。
提示
当Group Replication成功启动并且服务器加入组时，它会检查super_read_only变量。通过在成员的配置文件中将super_read_only设置为ON，您可以确保在任何原因导致启动Group Replication失败时，服务器不会接受事务。如果服务器应该作为读写实例加入组，例如作为单主组中的主服务器或作为多主组的成员，则当super_read_only变量设置为ON时，加入组后会被设置为OFF。
再次检查performance_schema.replication_group_members表，现在显示该组中有两个ONLINE服务器。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+当s2尝试加入组时，第17.9.5节“分布式恢复”确保s2应用了与s1应用的相同的事务。一旦这个过程完成，s2就可以作为成员加入组，并在这一点上标记为ONLINE。换句话说，它必须已经自动追赶了服务器s1。一旦s2处于ONLINE状态，它就开始与组一起处理事务。验证s2确实已经与服务器s1同步如下。
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 2 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 2 | 150 | |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN |
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724832985483517:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT |
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN |
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id: 108 (test.t1) |
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id: 108 flags: STMT_END_F |
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /* xid=30 */ |
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN |
| binlog.000001 | 1122 | View_change | 1 | 1261 | view_id=14724832985483517:2 |
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+如上所述，第二台服务器已添加到群组中，并且它已经使用分布式恢复自动地从服务器 s1 复制了更改。换句话说，在 s2 加入群组之前应用在 s1 上的交易已被复制到 s2。
17.2.1.6.2 Adding Additional Instances
将其他实例添加到群组本质上与添加第二台服务器的步骤相同，只是配置必须像对服务器 s2 那样进行更改。总结所需的命令如下
1. Create the configuration file
[mysqld]#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW#
# Group Replication configuration
#
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s3:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off2. Start the server and connect to it. Configure the recovery credentials for the group_replication_recovery channel.
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
FOR CHANNEL 'group_replication_recovery';4. Install the Group Replication plugin and start it.
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;此时，服务器 s3 已启动并正在运行，已加入群组，并已与群组中的其他服务器同步。再次查询 performance_schema.replication_group_members 表可以确认这一点。
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | s1 | 3306 | ONLINE |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | s3 | 3306 | ONLINE |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+---------------+在服务器 s2 或服务器 s1 上发出相同的查询会产生相同的结果。此外，您可以验证服务器 s3 已经追赶上来：
mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test |
+-----------------+mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 | 4 | Format_desc | 3 | 123 | Server ver: 5.7.44-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids | 3 | 150 | |
| binlog.000001 | 150 | Gtid | 1 | 211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |
| binlog.000001 | 211 | Query | 1 | 270 | BEGIN |
| binlog.000001 | 270 | View_change | 1 | 369 | view_id=14724832985483517:1 |
| binlog.000001 | 369 | Query | 1 | 434 | COMMIT |
| binlog.000001 | 434 | Gtid | 1 | 495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |
| binlog.000001 | 495 | Query | 1 | 585 | CREATE DATABASE test |
| binlog.000001 | 585 | Gtid | 1 | 646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |
| binlog.000001 | 646 | Query | 1 | 770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid | 1 | 831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |
| binlog.000001 | 831 | Query | 1 | 890 | BEGIN |
| binlog.000001 | 890 | Table_map | 1 | 933 | table_id: 108 (test.t1) |
| binlog.000001 | 933 | Write_rows | 1 | 975 | table_id: 108 flags: STMT_END_F |
| binlog.000001 | 975 | Xid | 1 | 1002 | COMMIT /* xid=29 */ |
| binlog.000001 | 1002 | Gtid | 1 | 1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |
| binlog.000001 | 1063 | Query | 1 | 1122 | BEGIN |
| binlog.000001 | 1122 | View_change | 1 | 1261 | view_id=14724832985483517:2 |
| binlog.000001 | 1261 | Query | 1 | 1326 | COMMIT |
| binlog.000001 | 1326 | Gtid | 1 | 1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6' |
| binlog.000001 | 1387 | Query | 1 | 1446 | BEGIN |
| binlog.000001 | 1446 | View_change | 1 | 1585 | view_id=14724832985483517:3 |
| binlog.000001 | 1585 | Query | 1 | 1650 | COMMIT |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+这篇关于【MGR】MySQL Group Replication快速开始的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
![[MySQL表的增删改查-进阶]](https://i-blog.csdnimg.cn/direct/626d73342e0c406894e1017eafd30cf2.png)
