MySQL MGR高可用集群布署

Posted 2021-05-26 ~~~~~~~~~~~~~~

配置组复制前提要求：

​
1、innodb存储引擎：数据必须存放在InnoDB事务存储引擎中。事务被乐观地执行，然后在提交时检查是否有冲突。
如果存在冲突，为了在整个组中保持一致性，将回滚一些事务。这意味着需要事务性存储引擎。此外，InnoDB还提供了一些额外的功能，可以更好地管理和处理与组复制一起操作时的冲突。使用其他存储引擎(包括临时内存存储引擎)可能导致组复制出错。通过在组成员上设置系统变量disabled_storage_engines，可以防止使用其他存储引擎，例如:disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
​
2、主键：组要复制的每个表都必须有一个已定义的主键，或者等效的主键，等效的主键是非空的唯一键。这些键需要作为表中每一行的唯一标识符，使系统能够通过准确地标识每个事务修改了哪些行来确定哪些事务发生冲突。
​
3、IPV4网络：mysql组复制使用的组通信引擎仅支持IPv4。因此，Group Replication需要IPv4网络基础设施。
​
4、网络性能：MySQL Group Replication被设计为部署在服务器实例彼此非常接近的集群环境中。网络延迟和网络带宽都会影响组的性能和稳定性。所有组成员之间必须始终保持双向通信。如果入站或出站通信阻塞服务器实例(例如,通过防火墙,或者连接问题),该成员不能在组中工作,组成员(包括有问题的成员)可能无法为受影响的服务器实例报告正确的成员状态。
​
​

组成员实例配置要求

1、唯一的server_id
2、二进制日志
3、副本更新记录
4、二进制日志行格式
5、关闭二进制日志校验
6、开启全局事务标识符
7、复制信息存储库设置为TABLE
8、事务写集提取
9、小写表名
10、多线程类型

官方要求译文如下：

独特的服务器标识符。
根据复制拓扑中所有服务器的需要，使用server_id系统变量为服务器配置唯一的服务器ID。
当默认服务器ID为0时，复制拓扑中的服务器无法相互连接。
服务器ID必须为1 ~(232)−1的正整数，且不能与复制拓扑中其他服务器使用的其他服务器ID相同。
​
二进制日志活动。
设置——log-bin [= log_file_name]。
MySQL Group Replication复制二进制日志内容，因此需要打开二进制日志进行操作。
该选项默认启用。
参见第5.4.4节“二进制日志”。
​
副本更新记录。
设置——log-slave-updates。
服务器需要记录通过复制应用程序应用的二进制日志。
该组中的服务器需要记录它们从该组接收和应用的所有事务。
这是必需的，因为恢复是依靠组中参与者的二进制日志进行的。
因此，每个事务的副本需要存在于每个服务器上，即使那些事务不是在服务器本身上启动的。
​
二进制日志行格式。
设置——binlog-format =行。
Group Replication依赖于基于行的复制格式在组中的服务器之间一致地传播更改。
它依赖于基于行的基础设施来提取必要的信息，以检测在组中不同服务器中并发执行的事务之间的冲突。
请参见16.2.1节“复制格式”。
​
二进制日志校验关闭。
设置——binlog-checksum =没有。
由于复制事件校验和的设计限制，Group replication不能使用它们，并且必须禁用它们。
​
全局事务标识符开启。
设置gtid_mode=ON和enforce_gtid_consistency=ON。
Group Replication使用全局事务标识符精确地跟踪每个服务器实例上提交了哪些事务，从而能够推断哪些服务器执行了可能与其他地方已经提交的事务冲突的事务。
换句话说，显式事务标识符是框架的一个基本部分，它能够确定哪些事务可能发生冲突。
请参见16.1.3节，“使用全局事务标识符的复制”。
​
复制信息存储库。
设置master_info_repository=TABLE和relay_log_info_repository=TABLE。
复制应用程序需要将源和副本元数据写入mysql。
slave_master_info和mysql。
slave_relay_log_info系统表。
这确保了Group Replication插件具有一致性的可恢复性和复制元数据的事务性管理。
请参见16.2.4.2节“复制元数据存储库”。
​
事务写集提取。
Set——transaction-write-set-extraction=XXHASH64以便在收集行以将其记录到二进制日志时，服务器也收集写集。
写集基于每一行的主键，是标记的简化和紧凑视图，唯一标识更改的行。
然后，该标记用于检测冲突。
​
小写表名。
将——lower-case-table-names设置为所有组成员的相同值。
使用InnoDB存储引擎时设置为1是正确的，这是组复制需要的。
注意，这个设置不是所有平台上的默认设置。
​
多线程的类型。
Group Replication成员可以配置为多线程副本，从而允许并行应用事务。
slave_parallel_workers的非零值启用成员上的多线程应用程序，最多可以指定1024个并行应用程序线程。
如果这样做，还需要进行以下设置:
​
slave_preserve_commit_order = 1
此设置是为了确保并行事务的最终提交与原始事务的顺序相同。
Group Replication依赖于基于保证所有参与成员以相同的顺序接收和应用已提交事务的一致性机制。
​
slave_parallel_type = LOGICAL_CLOCK
当slave_preserve_commit_order=1时需要这个设置。
它指定用于决定哪些事务允许在副本上并行执行的策略。
​
设置slave_parallel_workers=0将禁用并行执行，并为副本提供一个应用程序线程而没有协调线程。
通过该设置，slave_parallel_type和slave_preserve_commit_order选项没有作用，并且会被忽略。

具体配置如下：

[mysqld]
server_id=1
log_bin=/var/lib/mysql/binlogs/master
log_bin_index=/var/lib/mysql/binlogs/master.index
log_slave_updates=1
binlog-format=row
binlog_checksum=NONE
gtid_mode=on
enforce_gtid_consistency=on
master_info_repository=table
relay_log_info_repository=table
transaction-write-set-extraction=XXHASH64
lower-case-table-names=1
slave_preserve_commit_order = 1
slave_parallel_type = LOGICAL_CLOCK

组复制配置要求

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_replication_group_name告诉插件，它正在加入或创建的组名为“aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”。

• group_replication_group_name必须是合法的UUID。当在二进制日志中为组复制事件设置gtid时，内部使用这个UUID。您可以使用SELECT UUID()来生成UUID。

• 将group_replication_start_on_boot变量设置为off，将指示插件在服务器启动时不自动启动操作。在设置Group Replication时，这一点很重要，因为它确保您可以在手动启动插件之前配置服务器。一旦配置了成员，您可以将group_replication_start_on_boot设置为on，以便在服务器启动时自动启动组复制。

• 配置group_replication_local_address设置成员与组内其他成员通信时使用的网络地址和端口。组复制将此地址用于涉及组通信引擎(XCom, Paxos变体)的远程实例的内部成员到成员连接。

  *此地址必须与用于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地址

• 配置group_replication_group_seeds将设置组成员的主机名和端口，新成员将使用这些主机名和端口建立到组的连接。这些成员称为种子成员。一旦建立连接，将在performance_schema.replication_group_members中列出组成员信息。通常group_replication_group_seeds列表包含每个组成员group_replication_local_address的主机名:端口，但这不是强制性的，可以选择组成员的一个子集作为seed。

  *group_replication_group_seeds中列出的主机名:端口是seed成员的内部网络地址，由group_replication_local_address配置，而不是用于客户端连接的SQL主机名:端口，如performance_schema所示。replication_group_members表。

• 启动组的服务器不使用这个选项，因为它是初始服务器，因此它负责引导组。换句话说，引导组的服务器上的任何现有数据都将用作下一个加入成员的数据。第二个服务器加入请求组中唯一的一个成员加入，第二个服务器上丢失的数据将从引导成员上的donor数据复制，然后展开组。加入的第三个服务器可以请求这两个中的任何一个加入，数据同步到新成员，然后组再次展开。后续服务器在加入时重复此过程。

  *当同时加入多个服务器时，请确保它们指向组中已经存在的种子成员。不要使用也加入组的成员作为种子，因为在联系他们时，他们可能还不在组中。最好先启动引导成员，然后让它创建组。然后让它成为其他加入成员的种子成员。这确保在加入其他成员时形成一个小组。不支持创建分组并同时加入多个成员。它可能会起作用，但很可能会出现操作竞争，然后加入组的行为以错误或超时告终。

• 配置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)。

 

搭建实操

角色	IP地址	Mysql版本	操作系统	主机名
master	192.168.88.181	mysql 5.7.34	cenots 7.5	master
slave01	192.168.88.155	mysql 5.7.34	cenots 7.5	slave01
slave02	192.168.88.156	mysql 5.7.34	cenots 7.5	slave02

配置/etc/hosts文件

192.168.88.181 master
192.168.88.155 slave01
192.168.88.156 slave02

在所有实例上操作：

*组复制使用异步复制协议实现分布式恢复，在将组成员加入到组之前同步组成员。分布式恢复过程依赖于一个名为group_replication_recovery的复制通道，该通道用于将事务从捐赠成员传输到加入组的成员。因此，您需要设置具有正确权限的复制用户，以便“组复制”可以建立直接的成员到成员的恢复复制通道。

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';

在master上进行组引导操作：

*第一次启动一个组的过程称为引导。使用group_replication_bootstrap_group系统变量引导组。引导应该只由单个服务器完成，即只启动一次组的服务器。这就是为什么group_replication_bootstrap_group选项的值没有存储在实例的选项文件中。如果它保存在选项文件中，在重新启动时，服务器自动引导具有相同名称的第二组。这将导致两个名称相同的截然不同的组。同样的道理也适用于将此选项设置为ON时，停止并重新启动插件。

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

start语句执行成功后，组已经启动，可以使用

SELECT * FROM performance_schema.replication_group_members;

查看组成员信息；

 

在slave节点上执行加入组操作：

 START GROUP_REPLICATION;
 
 *如遇报错：
 This member has more executed transactions than those present in the group.
 The member contains transactions not present in the group. The member will now exit the group.
 请在所有节点上执行reset master;命令，然后重新执行组引导及加入组操作；

最终查询组成员状态如下：

MySQL [test]> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 440f27cb-bb99-11eb-9961-000c291aa359 | slave01     |        3306 | ONLINE       |
| group_replication_applier | 8394db9e-bb9a-11eb-8868-000c295e43ee | master      |        3306 | ONLINE       |
| group_replication_applier | d14927b5-bb9a-11eb-bb98-000c297f17d8 | slave02     |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
3 rows in set (0.00 sec)

到此，单主mgr布署完成；

可通过以下语句成员ID查看主节点信息：
SHOW STATUS LIKE 'group_replication_primary_member';

各节点my.cnf配置文件如下：

master:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
master_info_repository=table
relay_log_info_repository=table
symbolic-links=0
server_id=1
log_bin=/var/lib/mysql/binlogs/master
log_bin_index=/var/lib/mysql/binlogs/master.index
gtid_mode=on
enforce_gtid_consistency=on
binlog_checksum=NONE
log_slave_updates=1
binlog-format=row
transaction-write-set-extraction=XXHASH64
lower-case-table-names=1
slave_preserve_commit_order = 1
slave_parallel_type = LOGICAL_CLOCK
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
plugin_load_add='group_replication.so'
group_replication_group_name='249a232b-bb9e-11eb-b567-000c295e43ee'
group_replication_start_on_boot=off
group_replication_local_address= "192.168.88.181:33061"
group_replication_group_seeds="192.168.88.181:33061,192.168.88.155:33061,192.168.88.156:33061"
group_replication_bootstrap_group=off
[mysqld_safe]
log-error=/var/log/mysql/mysql.log
pid-file=/var/run/mysql/mysql.pid
!includedir /etc/my.cnf.d

slave01:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
server_id=2
log_bin=/var/lib/mysql/binlogs/slave01
log_bin_index=/var/lib/mysql/binlogs/slave01.index
log_slave_updates=1
binlog-format=row
binlog_checksum=NONE
gtid_mode=on
enforce_gtid_consistency=on
master_info_repository=table
relay_log_info_repository=table
transaction-write-set-extraction=XXHASH64
lower-case-table-names=1
slave_preserve_commit_order = 1
slave_parallel_type = LOGICAL_CLOCK
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
plugin_load_add='group_replication.so'
group_replication_group_name='249a232b-bb9e-11eb-b567-000c295e43ee'
group_replication_start_on_boot=off
group_replication_local_address= "192.168.88.155:33061"
group_replication_group_seeds="192.168.88.181:33061,192.168.88.155:33061,192.168.88.156:33061"
group_replication_bootstrap_group=off
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d

slave:02

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
server_id=3
log_bin=/var/lib/mysql/binlogs/slave02
log_bin_index=/var/lib/mysql/binlogs/slave02.index
log_slave_updates=1
binlog-format=row
binlog_checksum=NONE
gtid_mode=on
enforce_gtid_consistency=on
master_info_repository=table
relay_log_info_repository=table
transaction-write-set-extraction=XXHASH64
lower-case-table-names=1
slave_preserve_commit_order = 1
slave_parallel_type = LOGICAL_CLOCK
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
plugin_load_add='group_replication.so'
group_replication_group_name='249a232b-bb9e-11eb-b567-000c295e43ee'
group_replication_start_on_boot=off
group_replication_local_address= "192.168.88.156:33061"
group_replication_group_seeds="192.168.88.181:33061,192.168.88.155:33061,192.168.88.156:33061"
group_replication_bootstrap_group=off
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d

切换为多主模式

在所有实例上执行：

 stop group_replication;
 set global group_replication_single_primary_mode=OFF;
 set global group_replication_enforce_update_everywhere_checks=ON;

在其中一个实例上执行：

SET GLOBAL group_replication_bootstrap_group=ON; 
START GROUP_REPLICATION; 
SET GLOBAL group_replication_bootstrap_group=OFF;

其他节点加入组：

START GROUP_REPLICATION;