[mysql] 17.2. mysql MGR 安装参考手册_1（ Single-Primary Mode）
MySQL组复制作为MySQL服务器的插件提供，并且组中的每个服务器都需要配置和安装插件。本节提供详细的教程，其中包含创建具有至少三个成员的复制组所需的步骤。
组中的每个MySQL服务器实例都可以在独立的物理主机上运行，这是部署组复制的推荐方法。本节说明如何使用三个MySQL Server实例创建复制组，每个实例在不同的主机上运行。
Group Architecture
Configuring an Instance for Group Replication
储存引擎
对于组复制，数据必须存储在 InnoDB 存储引擎中。使用其他存储引擎（包括临时 MEMORY 存储引擎）可能会导致组复制中的错误。可以设置 disabled_storage_engines 系统变量以防止其使用：
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"请注意，在 MyISAM 存储引擎被禁用的情况下，将MySQL实例升级到仍使用mysql_upgrade的发行版（在MySQL 8.0.16之前）时，mysql_upgrade可能会失败并显示错误。要解决此问题，您可以在运行mysql_upgrade时重新启用该存储引擎，然后在重新启动服务器时再次禁用它。
Replication Framework
以下设置为MySQL组复制要求配置。
server_id=1
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这些设置将服务器配置为使用唯一标识符1，以启用全局事务标识符并将复制元数据存储在系统表中而不是文件中。此外，它指示服务器打开二进制日志记录，使用基于行的格式并禁用二进制日志事件校验和。有关更多详细信息，请参见 第17.7.1节“组复制要求”。
组复制设置
以下部分为服务器配置“组复制”设置。
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=off-
plugin-load-add：将组复制插件添加到服务器在启动时加载的插件列表中。在生产部署中，这比手动安装插件更好。 -
group_replication_group_name ：告诉插件加入或创建的组命名为“ aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaaa”。
group_replication_group_name 的值必须是有效的UUID。在二进制日志中为组复制事件设置GTID时在内部使用此UUID。可以使用
SELECT UUID()用来生成UUID。 -
group_replication_start_on_boot ：
off指示组复制插件在服务器启动时不自动启动操作。这在设置组复制时很重要，因为它可确保您可以在手动启动插件之前配置服务器。配置成员后，您可以设置 group_replication_start_on_boot 为on以便在服务器启动时自动启动组复制。 -
group_replication_local_address ：该成员用于与组中其他成员进行内部通信的网络地址和端口。组复制将此地址用于涉及组通信引擎的远程实例（XCom，Paxos的变体）的内部成员间连接。
注意：该地址必须 与SQL使用的 hostname与port 所使用的地址不同， 且不可以被客户端使用。运行组复制时，只能将其用于组成员之间的内部通信。
group_replication_local_addres 的网络配置必须可以被所有主机解析。例如，如果每个服务器实例位于具有固定网络地址的不同计算机上，则可以使用计算机的IP地址，例如10.0.0.1。如果使用主机名，则必须使用标准名称，并确保可以通过DNS对其进行解析，并且配置正确
/etc/hosts文件或其他名称解析过程。从MySQL 8.0.14起，可以使用IPv6地址（或解析为它们的主机名）以及IPv4地址。group_replication_local_address 推荐端口号为 33061。 group_replication_local_address 作为组成员的唯一标识符。只要主机名或IP地址都不同，就可以对复制组的所有成员使用相同的端口，如以上所示。或者，可以对所有成员使用相同的主机名或IP地址，只要端口都不同即可。
-
group_replication_group_seeds ：组成员的主机名和端口，新成员用来建立其与组的连接。这些成员称为种子成员。建立连接后，组成员身份信息将列在 performance_schema.replication_group_members。通常，
group_replication_group_seeds 列表包含每个成员的 roup_replication_local_address的hostname:port， 这不是强制性的，可以选择小组成员的子集作为种子。注意这是内部通讯的，不是客户端连接的地址。启动组的服务器不使用此选项，因为它是初始化服务，因此，它负责引导。换句话说，引导该组的服务器上的任何现有数据都将用作下一个加入成员。第二个服务器联接要求组中的一个成员唯一加入，第二个服务器上的任何丢失数据都将从引导成员上的施主数据中复制，然后组扩展。第三个服务器加入可以要求这两个中的任何一个加入，数据同步到新成员，然后该组再次扩展。
警告同时加入多台服务器时，请确保它们指向组中已经存在的种子成员。请勿将新加入组的成员用作种子，因为联系后它们可能尚未加入该组。
推荐的作法是先启动引导程序成员，然后让其创建组。然后，使其成为要加入的其余成员的种子成员。这样可以确保在加入其余成员时形成一个组。不支持同时创建组和加入多个成员。它可能会起作用，但操作很可能会竞争，然后加入该组的行为最终会出错或超时。
-
group_replication_bootstrap_group ：指示插件是否引导组。在这种情况下，即使s1是组的第一个成员，我们也会在选项文件中将此变量设置为off。相反，在实例运行期间配置 group_replication_bootstrap_group ，以确保只有一个成员实际引导该组。
注意：group_replication_bootstrap_group 变量在任何时候都只能在一个服务实例上启用，通常是在第一次引导该组时启用（或者在整个组关闭并再次备份的情况下启用）。如果多次引导组（例如，当多个服务器实例设置了此选项时），则它们可能会出现脑裂的场景，其中存在两个具有相同名称的不同组。在第一个服务器实例联机后，始终将group_replication_bootstrap_group 设置为关闭。
用户凭证
组复制使用异步（asynchronous ）复制协议来实现 “分布式恢复”，在将组成员加入组之前对其进行同步。分布式恢复过程依赖于group_replication_recovery复制的通道，该通道用于将事务从施主成员转移到加入该组的成员。因此，您需要设置具有正确权限的复制用户，以便组复制可以建立直接的成员到成员恢复复制通道。
启动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 复制通道设置这些凭据，则服务器将无法连接到施主成员并运行分布式恢复过程以与其他组成员保持同步，因此最终无法加入该组。同样，如果服务器无法通过服务器正确识别其他成员hostname则恢复过程可能会失败。建议运行MySQL的操作系统hostname使用DNS或本地设置具有唯一标识。
启动组复制
配置并启动服务器s1后，安装组复制插件。如果您plugin_load_add='group_replication.so'在选项文件中使用 过，则将安装“组复制”插件，然后可以继续执行下一步。如果您决定手动安装插件，请连接到服务器并发出以下命令：
INSTALL PLUGIN group_replication SONAME 'group_replication.so';mysql.session用户必须存在，然后才能加载组复制。 mysql.session已在MySQL 5.7.19版本中添加。如果您的数据字典是使用较早版本初始化的，则必须进行MySQL升级。如果未运行升级，则组复制无法启动，并显示错误消息 There was an error when trying to access the server with user: mysql.session@localhost. Make sure the user is present in the server and that mysql_upgrade was ran after a server update.。
要检查插件是否已成功安装，使用 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 |
+----------------------------+----------+--------------------+-----引导组
首次启动组的过程称为引导。您可以使用 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');检查表t1和二进制日志的内容。
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.34-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语句写入二进制日志。同样，数据被插入表中并写入二进制日志。下一节将说明二进制日志条目的重要性，当新成员试图追赶并联机时，该组会不断增长并执行分布式恢复。
- 点赞
- 收藏
- 关注作者
评论（0）