【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=off
plugin-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= off

2. 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                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/721391.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Java基础概念 1-6注释关键字字面量变量-基本用法变量-使用方式和注意事项变量练习-计算公交车的人数

Java基础概念 1-6注释关键字字面量变量-基本用法变量-使用方式和注意事项变量练习-计算公交车的人数

Java基础概念 1-注释 单行注释 // 多行注释 /* */ 文档注释 /** */ --暂时不用 例: public class HelloWorld{ //main方法,表示程序的主入口.public static void main (String[] args){/*输出语句(打印语句)会把小括号内的内容进行输出打印.*/System.out.…
阅读更多...
Ethersacn的交易数据是什么样的（2）

Ethersacn的交易数据是什么样的（2）

分析 Raw Transanction RLP（Recursive Length Prefix）是一种以太坊中用于序列化数据的编码方式。它被用于将各种数据结构转换为二进制格式，以便在以太坊中传输和存储。RLP 是一种递归的编码方式，允许对复杂的数据结构进行编码。所…
阅读更多...
鸿蒙实战应用开发：【拨打电话】功能

鸿蒙实战应用开发：【拨打电话】功能

概述 本示例通过输入电话，进行电话拨打，及电话相关信息的显示。 样例展示 涉及OpenHarmony技术特性 网络通信 基础信息 拨打电话 介绍 本示例使用call相关接口实现了拨打电话并显示电话相关信息的功能 效果预览 使用说明 1.输入电话号码后&#…
阅读更多...
EIP-1559

EIP-1559

EIP EIP是以太坊改进提案（Ethereum Improvement Proposal）的缩写。它是一种标准化的提案制度，用于描述和讨论对以太坊区块链网络的改进和升级。EIP的目的是提供一个开放的、透明的过程，让社区成员、开发者和其他利益相关者能够共同…
阅读更多...
paypal绑卡教程

paypal绑卡教程

绑定信用卡到PayPal账户的流程可能会有轻微变化，具体步骤可能根据您所在的地区和PayPal的最新政策而有所不同。以下是一般的流程： 登录PayPal账户： 打开PayPal的官方网站或应用程序，使用您的账户登录凭据登录。 导航至钱包&#…
阅读更多...
Kafka面经

Kafka面经

1.Kafka如何保证消息不丢失 生产者： 1.Producer 默认是异步发送消息，这种情况下要确保消息发送成功，有两个方法 a. 把异步发送改成同步发送，这样 producer 就能实时知道消息发送的结果。 b. 添加异步回调函数来监听消息发送的结…
阅读更多...
redis02 安装

redis02 安装

官网下载 传送门https://redis.io/download/#redis-downloads 安装Redis mac m1安装 下载你需要版本的软件包放到指定的目录下进行解压 cd 到解压好的redis目录 运行下面的命令进行编译测试 sudo make test 中途可能会提示你安装make工具，按提示安装即可&…
阅读更多...
JWT身份验证

JWT身份验证

在实际项目中一般会使用jwt鉴权方式。 JWT知识点 jwt，全称json web token ，JSON Web令牌是一种开放的行业标准RFC 7519方法，用于在两方安全地表示声明。具体网上有许多文章介绍，这里做简单的使用。 1.数据结构 JSON Web Token…
阅读更多...
Unity 动态加载音频和音效

Unity 动态加载音频和音效

想要加载音效和音频需要两个组件： 听： 播： 一收一发 在层级中，右键创建 音频源 ，放入物体的子物体中。 播放 方式一 拖动需要播放的音频文件到，音频源组件中。 using System.Collections; using Syst…
阅读更多...
Guitar Pro 8.1中文版永久许可证激活2024最新24位注册激活码生成器

Guitar Pro 8.1中文版永久许可证激活2024最新24位注册激活码生成器

Guitar Pro是一款非常受欢迎的音乐制作软件，它可以帮助用户创建和编辑各种音乐曲谱。从其诞生以来就送专门为了编写吉他谱而研发迭代的。 尽管这款产品可能已经成为全球最受欢迎的吉他打谱软件，在编写吉他六线谱和乐队总谱中始终处于行业领先地位&#…
阅读更多...
Java求职技能清单（2024版）

Java求职技能清单（2024版）

一、Java基础扎实（反射、集合、IO、NIO、多线程、设计模式、通信协议等基础技术） （一）Java （二）网络IO （三）NIO模型 （…
阅读更多...
释放数据湖潜力：小红书如何实现数仓效率与成本的双重优化

释放数据湖潜力：小红书如何实现数仓效率与成本的双重优化

在当今以数据为核心的商业环境中，企业正面临着海量数据的处理和分析挑战。为克服传统数据仓库在处理速度、灵活性和成本效率方面的局限，小红书数据仓库团队引入如 Apache Iceberg 等数据湖技术，将其与数仓架构相结合，以释放数据湖…
阅读更多...
2024全网最全Excel函数与公式应用

2024全网最全Excel函数与公式应用

💂 个人网站:【 海拥】【神级代码资源网站】【办公神器】🤟 基于Web端打造的：👉轻量化工具创作平台💅 想寻找共同学习交流的小伙伴，请点击【全栈技术交流群】 引言 Excel是一款广泛应用于商业、教育和个人…
阅读更多...
VUE3项目学习系列--项目配置（二）

VUE3项目学习系列--项目配置（二）

在项目团队开发过程中，多人协同开发为保证项目格式书写格式统一标准化，因此需要进行代码格式化校验，包括在代码编写过程中以及代码提交前进行自动格式化，因此需要进行在项目中进行相关的配置使之代码格式一致。 一、eslint配置 …
阅读更多...
【世界首富宝座易主】贝佐斯超越马斯克，再登世界首富宝座

【世界首富宝座易主】贝佐斯超越马斯克，再登世界首富宝座

贝佐斯超越马斯克，再登世界首富宝座 杰佛瑞普雷斯顿「杰夫」贝佐斯（英语：Jeffrey Preston1964年1月12日），生于美国新墨西哥州，美国网际网路巨头亚马逊公司创始人及现任董事长，《华盛顿邮报》大股…
阅读更多...
哈希的简单介绍

哈希的简单介绍

unordered系列关联式容器 在C98中，STL提供了底层为红黑树结构的一系列关联式容器，在查询时效率可达到 l o g 2 N log_2 N log2​N，即最差情况下需要比较红黑树的高度次，当树中的节点非常多时，查询效率也不理想。最好的…
阅读更多...
一本书讲透ChatGPT——理论与实践的完美结合，大模型技术工程师的必备指南

一本书讲透ChatGPT——理论与实践的完美结合，大模型技术工程师的必备指南

写在前面 OpenAI 在 2022 年 11 月推出了人工智能聊天应用—ChatGPT。它具有广泛的应用场景，在多项专业和学术基准测试中表现出的智力水平，不仅接近甚至有时超越了人类的平均水平。这使得 ChatGPT 在推出之初就受到广大用户的欢迎，被科技界誉…
阅读更多...
Vue3学习记录（三）--- 组合式API之生命周期和模板引用

Vue3学习记录（三）--- 组合式API之生命周期和模板引用

一、生命周期 1、简介 ​ 生命周期，指的是一个 Vue 实例从创建到销毁的完整阶段，强调的是一个时间段。 ​ 生命周期钩子函数，指的是 Vue 实例提供的内置函数，函数的参数为一个回调函数。这些钩子函数会在实例生命周期的某些固定…
阅读更多...
win系统如何同时安装MySQL5和MySQL8

win系统如何同时安装MySQL5和MySQL8

win系统如何同时安装MySQL5和MySQL8 文章目录 win系统如何同时安装MySQL5和MySQL81、准备好两种版本的数据库2、下载后解压到你指定的目录3、手动配置安装MySQL5和8安装MySQL53.1创建my.ini文件3.2生成data文件夹 安装MySQL83.1创建my.ini文件3.2生成data文件夹 4、配置环境变量…
阅读更多...
汽车车灯照明灯具维修的常见误区有哪些呢?

汽车车灯照明灯具维修的常见误区有哪些呢?

汽车车灯照明灯具维修的常见误区有哪些呢? 汽车灯具维修的常见误区包括以下几个方面： 忽视车灯的日常保养：许多车主在日常使用中忽视了车灯的保养，只有当车灯出现故障时才进行维修。然而，定期检查和保养车灯是预防故障发生的重要…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023