【MGR】MySQL Group Replication快速开始

news2024/11/16 8:53:57

目录

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.coloradmin.cn/o/1490878.html

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

相关文章

【Git】项目源码迁移到另一个gitlab(保留原来提交历史记录)

【Git】项目源码迁移到另一个gitlab(保留原来提交历史记录)

目录 前情提要迁移方案IDEA远程仓库管理团队其他成员切换gitgit命令操作界面 前情提要 公司原来是自己私有部署的gitlab。有了研发云后就希望将代码推送到研发云的代码仓库上。这时候需要迁移并保留原来提交的历史记录。 迁移方案 登录新的gitlab(代码仓库)新建空白项目获取…
阅读更多...
hive sql无法停止

hive sql无法停止

排查流程 hive任务停止是调用org.apache.hive.jdbc.HiveStatement的close()方法实现的 其底层是委托给org.apache.hive.service.cli.thrift.TCLIService.Iface客户端实例来实现。 同时，通过JDK动态代理为其织入了synchronized同步机制：其底层是委托给…
阅读更多...
进入软件测试行业，这些问题你一定要知道！

进入软件测试行业，这些问题你一定要知道！

很多转行的朋友都会选择进入软件测试开发行业，如果确定进入软件测试开发行业，那么这些问题你一定要知道！ 一、软件测试发展前景 1、测试人员与开发人员的配比已经从最初的1:10、1:8，发展到如今的1:3、1:2。未来会继续趋于平衡&…
阅读更多...
flink重温笔记（十）：Flink 高级 API 开发——flink 四大基石之 State（涉及Checkpoint）

flink重温笔记（十）：Flink 高级 API 开发——flink 四大基石之 State（涉及Checkpoint）

Flink学习笔记 前言：今天是学习 flink 的第 10 天啦！学习了 flink 四大基石之 State （状态），主要是解决大数据领域增量计算的效果，能够保存已经计算过的结果数据状态！重点学习了 state 的类型划…
阅读更多...
ABAP - SALV教程12 显示图标和提示信息

ABAP - SALV教程12 显示图标和提示信息

ALV要求字段的值为图标的需求并不多见，一般都用于红黄绿灯，来表示单据的执行状态，添加图标的方式也可以实现红黄绿灯的功能，也可以参考SALV实现红黄绿灯这篇文章：http://t.csdnimg.cn/Dzx7x效果图SAVL列设置为图标图标…
阅读更多...
1688淘宝天猫无货源API(商品列表、商品详情、店铺商品、sku）

1688淘宝天猫无货源API(商品列表、商品详情、店铺商品、sku）

item_get 获得淘宝商品详情item_get_pro 获得淘宝商品详情高级版item_review 获得淘宝商品评论item_search 按关键字搜索淘宝商品item_search_img 按图搜索淘宝商品（拍立淘）item_search_shop 获得店铺的所有商品item_search_seller 搜索店铺列表 API公共…
阅读更多...
【LeetCode】升级打怪之路 Day 13：优先级队列的应用

【LeetCode】升级打怪之路 Day 13：优先级队列的应用

今日题目： 23. 合并 K 个升序链表 | LeetCode378. 有序矩阵中第 K 小的元素 | LeetCode373. 查找和最小的 K 对数字 | LeetCode703. 数据流中的第 K 大元素 | LeetCode347. 前 K 个高频元素 | LeetCode 目录 Problem 1：合并多个有序链表 【classic】LC 2…
阅读更多...
一些硬件知识（五）

一些硬件知识（五）

选择MCU时需要考虑以下几个方面：1。首先考虑引脚功能数量是否够用2.其次如果跑RTOS操作系统的话对堆栈有要求3.需要考虑单片机某个功能的极限性能，例如做BLDC驱动板子的时候要求对电机的电流做到精确采样，此时会选用这个方向表现较好的MCU,例…
阅读更多...
如何搭建Nacos集群

如何搭建Nacos集群

1.搭建Nacos集群 众所周知，在实际的工作中，Nacos的生成环境下一定要部署为集群状态 其中包含3个nacos节点，然后一个负载均衡器代理3个Nacos。这里负载均衡器可以使用nginx。 我们计划的集群结构： 我就直接在本机上开三个Nacos来搭…
阅读更多...
变分推断中的ELBO(证据下界)

变分推断中的ELBO(证据下界)

一、变分推断简介 变分推理的目标是近似潜在变量(latent variables)在观测变量（observed variables）下的条件概率。解决该问题，需要使用优化方法。在变分推断中，需要使用到的一个重要理论，是平均场理论。 1、平均场理论 来源于物理学，是一种研究复杂多体问题的方法，将…
阅读更多...
Rust 中如何解析 JSON?

Rust 中如何解析 JSON?

Rust 中如何解析 JSON? 在本文中，我们将讨论如何在 Rust 中使用 JSON 解析库，以及比较最流行的库及其性能。 JSON 解析基础知识 手动解析 JSON 要开始在 Rust 中使用 JSON，您需要安装一个可以轻松操作 JSON 的库。目前可用的流行crate之一…
阅读更多...
07 系统的线性时不变特性

07 系统的线性时不变特性

各位看官，大家好！本讲为《数字信号处理理论篇》07 系统的线性时不变特性。（特别提示：课程内容为由浅入深的特性，而且前后对照，不要跳跃观看，请按照文章或视频顺序进行观看。 从本讲开始开始为大…
阅读更多...
【Python】进阶学习：__len__()方法的使用介绍

【Python】进阶学习：__len__()方法的使用介绍

【Python】进阶学习：__len__()方法的使用介绍 🌈 个人主页：高斯小哥 🔥 高质量专栏：Matplotlib之旅：零基础精通数据可视化、Python基础【高质量合集】、PyTorch零基础入门教程👈 希望得到您的订…
阅读更多...
shadertoy 游戏《来自星尘》摇杆复刻

shadertoy 游戏《来自星尘》摇杆复刻

正确的做法应该是上 noise 而不是叠加 sin 波，不过如果不想麻烦的话叠波还是一个不错的选择：整体效果如下，已经非常形似 直接上链接：Shader - Shadertoy BETA float radiusScale 0.9; float variation(vec2 v1, vec2 v2, float …
阅读更多...
KCV（Key Check Value）的作用(验证密钥导入是否正确)与算法(DES/3DES或AES)示例

KCV（Key Check Value）的作用(验证密钥导入是否正确)与算法(DES/3DES或AES)示例

KCV的作用与算法 KCV（Key Check Value）的计算通常与加密算法有关，不同算法计算KCV的方式不同。以下是常见算法的KCV计算方法： DES/3DES算法： KCV是通过使用ECB模式的3DES加密8字节’00’来计算的。例如，…
阅读更多...
【鸿蒙 HarmonyOS 4.0】弹性布局（Flex）

【鸿蒙 HarmonyOS 4.0】弹性布局（Flex）

一、介绍 弹性布局（Flex）提供更加有效的方式对容器中的子元素进行排列、对齐和分配剩余空间。容器默认存在主轴与交叉轴，子元素默认沿主轴排列，子元素在主轴方向的尺寸称为主轴尺寸，在交叉轴方向的尺寸称为交叉轴尺寸…
阅读更多...
Pipy 进化：从可编程代理到应用引擎

Pipy 进化：从可编程代理到应用引擎

网络功能变得越来越复杂，编写和维护的难度提升；新的基于 Pipy 的应用中，Pipy 角色从数据平面变成控制面，需要执行更多复杂非网络的逻辑；从长远来看，Pipy 将更像是一个常见的类似 shell/bash 的系统脚本工具…
阅读更多...
如何在MinIO系统中进行配置并结合内网穿透实现公网远程连接上传文件

如何在MinIO系统中进行配置并结合内网穿透实现公网远程连接上传文件

文章目录 前言1. 创建Buckets和Access Keys2. Linux 安装Cpolar3. 创建连接MinIO服务公网地址4. 远程调用MinIO服务小结5. 固定连接TCP公网地址6. 固定地址连接测试 前言 MinIO是一款高性能、分布式的对象存储系统，它可以100%的运行在标准硬件上，即X86等…
阅读更多...
力扣hot100题解（python版33-35题）

力扣hot100题解（python版33-35题）

33、排序链表 给你链表的头结点 head ，请将其按 升序 排列并返回 排序后的链表 。 示例 1： 输入：head [4,2,1,3] 输出：[1,2,3,4]示例 2： 输入：head [-1,5,3,4,0] 输出：[-1,0,3,4,5]示例 3&a…
阅读更多...
你知道该如何使用 JS 创建 css 类样式吗？

你知道该如何使用 JS 创建 css 类样式吗？

前言 去年我为公司内部开发了一个浏览器插件，当时为了加快开发进度，我没有选用现成的插件框架，而是直接使用原生 JavaScript 搭配 Rollup 进行打包。由于这是一个浏览器插件，我不可避免地需要对页面元素进行操作，比如…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023