在单主模式下部署组复制
组中的每个MySQL服务器实例都可以在独立的物理主机上运行,这是部署组复制的推荐方法。本节说明如何使用三个MySQL Server实例创建复制组,每个实例在不同的主机上运行。有关在同一主机上部署多个运行组复制的MySQL服务器实例的信息(例如出于测试目的),请参见“在本地部署组复制”。
组架构

本教程介绍了如何使用“组复制”插件获取和部署MySQL Server,如何在创建组之前配置每个服务器实例,以及如何使用“性能模式”监视来验证一切正常。
部署实例以进行组复制
第一步是部署至少三个MySQL Server实例,此过程演示了如何为实例使用多个主机,分别名为s1,s2和s3。假定在每个主机上都安装了MySQL Server,请参见安装和升级MySQL。组复制是MySQL Server 8.0随附的内置MySQL插件,因此不需要其他安装。有关MySQL插件的更多背景信息,请参见“ MySQL Server插件”。
在此示例中,三个实例用于该组,这是创建组的最小实例数。添加更多实例将增加组的容错能力。例如,如果该组由三个成员组成,则在一个实例失败的情况下,该组可以继续。但是,如果发生另一个故障,该组将无法继续处理写事务。通过添加更多实例,在组继续处理事务时可能发生故障的服务器数量也会增加。一个组中最多可以使用9个实例。有关更多信息,请参见“故障检测”。
配置实例进行组复制
本节说明要用于组复制的MySQL Server实例所需的配置设置。有关背景信息,
- 存储引擎
- 复制框架
- 组复制设置
存储引擎
对于组复制,数据必须存储在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时重新启用该存储引擎,然后在重新启动服务器时再次将其禁用。有关更多信息,请参见“mysql_upgrade-检查和升级MySQL表”。
复制框架
以下设置根据MySQL组复制要求配置复制。
server_id=1 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE
这些设置将服务器配置为使用唯一标识符1,以启用“使用全局事务标识符进行复制”,仅允许执行可以使用GTID安全记录的语句,并禁止为事件编写校验和。写入二进制日志。
如果您使用的MySQL版本低于8.0.3,则默认版本已进行了改进以进行复制,则需要将这些行添加到成员的选项文件中。
log_bin=binlog log_slave_updates=ON binlog_format=ROW master_info_repository=TABLE relay_log_info_repository=TABLE
这些设置指示服务器打开二进制日志记录,使用基于行的格式,将复制元数据存储在系统表中而不是文件中,并禁用二进制日志事件校验和。有关更多详细信息,请参见“组复制要求”。
组复制设置
此时,选项文件可确保已配置服务器,并指示该服务器在给定配置下实例化复制基础结构。以下部分为服务器配置“组复制”设置。
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_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变体)的远程实例的内部成员间连接。重要
组复制本地地址必须不同于,
hostname
并且port
用于SQL,并且不得用于客户端应用程序。运行组复制时,只能将其用于组成员之间的内部通信。group_replication_local_address
所有组成员都必须解析由配置的网络地址。例如,如果每个服务器实例位于具有固定网络地址的不同计算机上,则可以使用计算机的IP地址,例如10.0.0.1。如果使用主机名,则必须使用标准名称,并确保可以通过DNS对其进行解析,并且配置正确/etc/hosts
文件或其他名称解析过程。从MySQL 8.0.14起,可以使用IPv6地址(或解析为它们的主机名)以及IPv4地址。组可以包含使用IPv6的成员和使用IPv4的成员的混合。有关对IPv6网络以及IPv4和IPv6混合组的组复制支持的更多信息,请参见“对IPv6以及对IPv6和IPv4混合组的支持”。推荐的端口号为
group_replication_local_address
33061。group_replication_local_address
组复制将其用作复制组中组成员的唯一标识符。只要主机名或IP地址都不同,就可以对复制组的所有成员使用相同的端口,如本教程所示。或者,您可以对所有成员使用相同的主机名或IP地址,只要端口都不同即可,例如,如“本地部署组复制”所示。重要
尽管组复制本地地址
hostname
与port
SQL的不同,但组复制的加入成员的分布式恢复过程可能会失败,如果服务器无法使用服务器的SQL正确识别其他成员hostname
。建议运行MySQL的操作系统hostname
使用DNS或本地设置具有正确配置的唯一。该hostname
可在验证Member_host
的列performance_schema.replication_group_members
表。如果多个组成员hostname
将操作系统的默认设置外部化,则该成员可能无法解析到正确的成员地址,也无法加入该组。在这种情况下,可使用report_host
配置唯一性hostname
以由每个服务器外部化。配置
group_replication_group_seeds
设置组成员的主机名和端口,新成员使用该主机名和端口建立与组的连接。这些成员称为种子成员。建立连接后,组成员身份信息将列在performance_schema.replication_group_members
。通常,group_replication_group_seeds
列表包含hostname:port
每个小组成员的group_replication_local_address
,但这不是强制性的,可以选择小组成员的子集作为种子。重要
该
hostname:port
列在group_replication_group_seeds
是种子构件的内部网络地址,由被配置group_replication_local_address
,而不是SQLhostname:port
用于客户端连接,并且例如在显示performance_schema.replication_group_members
表中。启动组的服务器不使用此选项,因为它是初始服务器,因此它负责引导组。换句话说,引导该组的服务器上的任何现有数据都将用作下一个加入成员的数据。第二个服务器联接要求组中的一个成员也是唯一的成员联接,第二个服务器上的任何丢失数据都将从引导成员上的施主数据中复制,然后该组扩展。第三个服务器加入可以要求这两个中的任何一个加入,数据同步到新成员,然后该组再次扩展。
警告
同时加入多台服务器时,请确保它们指向组中已经存在的种子成员。不要将也加入该组的成员用作种子,因为联系后它们可能尚未加入该组。
优良作法是先启动引导程序成员,然后让其创建组。然后,使其成为要加入的其余成员的种子成员。这样可以确保在加入其余成员时形成一个组。
不支持同时创建组和加入多个成员。可能可行,但是操作很可能会竞争,然后加入该组的行为最终会出错或超时。
加入成员必须使用种子成员在
group_replication_group_seeds
选项中发布的相同协议(IPv4或IPv6)与种子成员进行通信。为了将IP复制白名单用于组复制,种子成员上的白名单必须包括种子成员提供的协议的加入成员的IP地址,或解析为该协议地址的主机名。除加入会员的地址或主机名外,还必须设置此地址或主机名并将其列入白名单group_replication_local_address
如果该地址的协议与种子成员的公告协议不匹配。如果加入成员没有适当协议的白名单地址,则拒绝其连接尝试。有关更多信息,请参见“组复制IP地址白名单”。配置
group_replication_bootstrap_group
指示插件是否引导组。在这种情况下,即使s1是组的第一个成员,我们也会在选项文件中将此变量设置为off。相反,我们配置group_replication_bootstrap_group
实例运行的时间,以确保只有一个成员实际引导该组。重要
group_replication_bootstrap_group
只能在任何时候(通常是在第一次引导该组时)(或者在整个组关闭后又重新备份的情况下)随时在属于该组的一个服务器实例上启用该变量。如果您多次引导该组,例如,当多个服务器实例设置了此选项时,它们可能会创建一个人为分裂的场景,其中存在两个具有相同名称的不同组。始终group_replication_bootstrap_group=off
在第一个服务器实例联机后设置。
如果使用的实例运行的MySQL版本早于8.0.2,则还需要将transaction_write_set_extraction
变量配置为XXHASH64。该变量指示服务器,对于每个事务,它必须收集写集,并使用XXHASH64哈希算法将其编码为哈希。从MySQL 8.0.2开始,此设置为默认设置,否则将以下内容添加到选项文件中:
transaction_write_set_extraction=XXHASH64
该组中所有服务器的配置都非常相似。您需要更改有关每个服务器的细节(例如server_id
,datadir
,group_replication_local_address
)。本教程稍后将对此进行说明。
用户凭证
组复制使用分布式恢复过程将组成员加入组时进行同步。分布式恢复涉及使用名为复制的通道将事务从捐赠者的二进制日志传输到加入成员group_replication_recovery
。因此,您必须设置具有正确权限的复制用户,以便组复制可以建立直接的成员到成员复制通道。如果已将组成员设置为支持将远程克隆操作用作分布式恢复的一部分(可从MySQL 8.0.17获得),则此复制用户还将用作施主上的克隆用户,并且需要正确的权限也是这个角色。有关分布式恢复的完整说明,请参见“分布式恢复的工作方式”。
可以在二进制日志中捕获设置复制用户以进行分布式恢复的过程,然后可以依靠分布式恢复来复制用于创建用户的语句。或者,您可以在创建复制用户之前禁用二进制日志记录,然后在每个成员上手动创建用户,例如,如果要避免将更改传播到其他服务器实例。如果这样做,请确保在配置用户后重新启用二进制日志记录。
如果您为复制组设置了克隆,则group_replication_recovery
在克隆之后,供体用于复制通道的复制用户和密码将在克隆后转移到加入成员,然后再由加入成员使用,因此它们在那里必须有效。因此,通过远程克隆操作接收到状态转移的所有组成员都使用相同的复制用户和密码进行分布式恢复。
重要如果您的组的分布式恢复连接使用SSL,则在加入成员连接到施主之前,必须在每台服务器上创建复制用户。有关为分布式恢复连接设置SSL的说明,请参见“组复制安全套接字层(SSL)支持”
要创建用于分布式恢复的复制用户,请按照下列步骤操作:
- 启动MySQL服务器实例,然后将客户端连接到它。
如果要禁用二进制日志记录以便在每个实例上分别创建复制用户,请执行以下语句:
mysql>
SET SQL_LOG_BIN=0;创建一个具有
REPLICATION SLAVE
特权的MySQL用户,该特权可用于分布式恢复,如果服务器被设置为支持克隆,则该BACKUP_ADMIN
特权将用作克隆操作中的捐助者。在此示例中,显示了rpl_user
具有密码的用户password
。配置服务器时,请使用适当的用户名和密码:mysql>
CREATE USER rpl_user@'%'IDENTIFIED BY 'password'; mysql>GRANT REPLICATION SLAVE ON *.*TO rpl_user@'%'; mysql>GRANT BACKUP_ADMINON *.*TO rpl_user@'%'; mysql>FLUSH PRIVILEGES ;如果禁用了二进制日志记录,请在创建用户后立即通过发出以下语句再次启用它:
mysql>
SET SQL_LOG_BIN=1;配置用户后,使用
CHANGE MASTER TO
语句将服务器配置为使用给定的凭据通过分布式恢复或远程克隆操作进行状态转移。发出以下语句,替换rpl_user
并替换password
为创建用户时使用的值:mysql>
CHANGE MASTER TO MASTER_USER ='rpl_user',MASTER_PASSWORD ='password' \\FOR CHANNEL 'group_replication_recovery';如果没有为
group_replication_recovery
复制通道正确设置这些凭据rpl_user
,如图所示,则服务器无法连接到施主以执行状态传输,因此无法加入组。
使用组复制和缓存SHA-2用户凭据插件
默认情况下,在MySQL 8中创建的用户使用“缓存SHA-2可插拔身份验证”。如果rpl_user
您为分布式恢复配置的使用缓存SHA-2身份验证插件,而您没有为复制通道使用“组复制安全套接字层(SSL)支持”,则将group_replication_recovery
RSA密钥对用于密码交换,请参见“创建SSL和RSA证书和密钥”。您可以将的公共密钥复制rpl_user
到加入成员,也可以配置供体以在需要时提供公共密钥。
更为安全的方法是将的公钥复制rpl_user
到加入成员。然后,您需要group_replication_recovery_public_key_path
在加入成员上配置系统变量,并带有指向的公钥的路径rpl_user
。
可选地,一种不太安全的方法是group_replication_recovery_get_public_key=ON
对捐赠者进行设置,以便他们rpl_user
向加入成员提供的公钥。无法验证服务器的身份,因此仅group_replication_recovery_get_public_key=ON
在您确定不存在服务器身份受到威胁(例如,中间人攻击)的风险时才进行设置。
启动组复制
配置并启动服务器s1后,安装组复制插件。如果您plugin_load_add='group_replication.so'
在选项文件中使用过,则将安装“组复制”插件,然后可以继续执行下一步。如果您决定手动安装插件,请连接到服务器并发出以下命令:
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
重要该
mysql.session
用户必须存在,然后才能加载组复制。mysql.session
已在MySQL版本8.0.2中添加。如果您的数据字典是使用较早版本初始化的,则必须执行MySQL升级过程(请参见“升级MySQL”)。如果未运行升级,则组复制无法启动,并显示错误消息尝试使用用户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 | +---------------------------- +---------- +-------------------- +---------------------- +------------- +
自举组
首次启动组的过程称为引导。您可以使用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 INTPRIMARY KEY , c2 TEXT NOT NULL); mysql>INSERT INTO t1VALUES (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: 8.0.21 -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语句写入二进制日志。此外,数据已插入表中并写入二进制日志,因此可以通过从捐赠者的二进制日志进行状态转移将其用于分布式恢复。
将实例添加到组
此时,该组中有一个成员,服务器s1,其中有一些数据。现在是时候通过添加先前配置的其他两个服务器来扩展组。
添加第二个实例
为了添加第二个实例,服务器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 binlog_checksum=NONE # # 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时使用的命令相同。该成员需要具有在“用户凭据”中配置的相同复制用户。。如果您依靠分布式恢复在所有成员上配置用户,则当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@'%';GRANT BACKUP_ADMINON *.*TO rpl_user@'%';SET SQL_LOG_BIN=1;CHANGE MASTER TO MASTER_USER ='rpl_user',MASTER_PASSWORD ='password' \\FOR CHANNEL 'group_replication_recovery';
如果您正在使用SHA-2身份验证缓存插件(MySQL 8中的默认设置),请参阅使用组复制和SHA-2用户凭据缓存插件。
如有必要,安装组复制插件,
启动组复制,并且s2启动加入组的过程。
mysql>START GROUP_REPLICATION ;
不像是同在S1上执行这些前面的步骤,这里有在你的差异并不需要自举的组,因为已经组exiists。换句话说,将s2 group_replication_bootstrap_group
设置为off,并且SET GLOBAL group_replication_bootstrap_group=ON;
在启动组复制之前不会发出问题,因为服务器s1已创建并引导了该组。此时,仅需要将服务器s2添加到现有组中。
当组复制成功启动并且服务器加入该组时,它将检查该super_read_only
变量。通过super_read_only
在成员的配置文件中将其设置为ON,可以确保由于任何原因启动组复制而失败的服务器不接受事务。如果服务器应以读写实例的形式加入该组,例如以单主要组的主要实例或多主要组的成员的身份加入,则当该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尝试加入该组时,“分布式恢复”确保s2应用了与s1相同的事务。完成此过程后,s2可以作为成员加入该组,这时将其标记为ONLINE。换句话说,它必须已经自动追上了服务器s1。s2联机后,它便开始处理与该组的事务。验证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: 8.0.21 -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。
添加其他实例
向组中添加其他实例与添加第二台服务器基本上是相同的步骤顺序,除了必须更改服务器s2的配置之外。总结所需的命令:
1.创建配置文件
[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 binlog_checksum=NONE # # 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= off
2.启动服务器并连接到它。为group_replication_recovery通道配置分布式恢复凭据。
SET SQL_LOG_BIN=0;CREATE USER rpl_user@'%'IDENTIFIED BY 'password';GRANT REPLICATION SLAVE ON *.*TO rpl_user@'%';GRANT BACKUP_ADMINON *.*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 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: 8.0.21 -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 | +--------------- +------ +---------------- +----------- +------------- +-------------------------------------------------------------------- +
上一个 HOME UP NEXT