Lamp架构——mysql集群及组复制（3）

一、介绍及环境搭建

msql组复制，实施简单，但要求较高，同步采用的是分布式文件系统协议，比半同步更严谨更慢，是一种全同步方案，mysql分布式集群（京东在用），当前最多支持九个节点。

组复制要求较高，而且与之前架构配置不同，所以设置一个干净的实验环境。

关闭所有节点mysql进程

1.单主组复制与多主组复制相关介绍

单主模式适合大于写的场景，因为只有master可以写。
多主模式的每个节点不但可读可写，也都可以同步。


下边实验做的是多主组复制,也就是每个节点都可以写入，其他原理与上面相同，相关介绍见下
mysql多主复制与单主复制相关介绍

1.节点1server5组复制配置

清空节点server5的数据库目录

修改配置文件并初始化

配置 group_replication_bootstrap_group 指示插件是否引导组。 在这种情况下，即使 s1 是组的第一个成员，我们也会在选项文件中将此变量设置为 off。 相反，我们在实例运行时配置 group_replication_bootstrap_group，以确保只有一个成员实际引导该组。

配置 group_replication_group_name 告诉插件它正在加入或创建的组被命名为“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。group_replication_group_name 的值必须是有效的 UUID。 在为二进制日志中的组复制事件设置 GTID 时，内部使用此 UUID。 可以使用 SELECT UUID() 来生成 UUID。

组复制默认是单主模式，所以需要关闭单主模式

33061是组复制监听端口

组复制校验特别严谨，要求必须是一致的，slave端有多余的日志时，也会报错。

初始化数据库,启动数据库，并修改密码

[root@server5 mysql]# mysqld --initialize --user=mysql
[root@server5 mysql]# /etc/init.d/mysqld start
[root@server5 mysql]# mysql -p

使用命令行修改数据库登陆密码

mysql> alter user root@localhost identified by 'westos';

禁止记录二进制日志，创建组复制用户，并赋予权限，再开启二进制日志记录，设置组复制

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.04 sec)

mysql> show plugins;

配置用户后，使用 CHANGE MASTER TO 语句将服务器配置为在下次需要从另一个成员恢复其状态时使用 group_replication_recovery 复制通道的给定凭据。 发出以下命令，将 rpl_user 和 password 替换为创建用户时使用的值。分布式恢复是加入组且与组成员不具有相同事务集的服务器所采取的第一步。 如果未为 group_replication_recovery 复制通道和 rpl_user 正确设置这些凭据，如图所示，服务器将无法连接到捐赠者成员并运行分布式恢复过程以获得与其他组成员的同步，因此最终无法加入该组。

首次启动组的过程称为引导,需要使用 group_replication_bootstrap_group 系统变量来引导组。 引导只能由单个服务器完成，即启动组的服务器并且只执行一次。 这就是为什么 group_replication_bootstrap_group 选项的值没有存储在实例的选项文件中的原因。 如果它保存在选项文件中，则在重新启动服务器时会自动引导第二个具有相同名称的组。 这将导致两个不同的组具有相同的名称。

第一条指令只在第一个启动节点上运行
mysql> SET GLOBAL group_replication_bootstrap_group=ON;

mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;

查看组以及组成员
mysql> SELECT * FROM performance_schema.replication_group_members;

2.节点2server6配置

清空数据库目录

[root@server6 mysql]# pwd
/data/mysql
[root@server6 mysql]# rm -fr *

编辑配置文件/etc/my.cnf

[root@server6 mysql]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
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

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= "172.25.254.16:33061"
group_replication_group_seeds= "172.25.254.15:33061,172.25.254.16:33061,172.25.254.17:33061"
group_replication_bootstrap_group=off
group_replication_ip_whitelist="172.25.254.0/24,127.0.0.1/8"
group_replication_single_primary_mode=OFF
group_replication_enforce_update_everywhere_checks=ON

初始化数据库，并启动数据库，修改管理员密码
关闭记录二进制日志，创建用户并赋予复制权限，创建完成后，正常开启二进制日志的记录

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;

配置组复制，查看安装插件

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
mysql> show plugins;

启动组复制
因为server5已经是该组复制的引导节点，所以不需要再执行引导再指令，直接启动组复制即可自动加进去。

查找启动失败原因，查看日志
修改配置文件

[root@server6 mysql]# vim /etc/my.cnf
group_replication_allow_local_disjoint_gtids_join=1
参数为1或ON都是开启的意思

在配置文件修改参数是需要重启生效的，也可用set_global命令热生效
启动组复制

mysql> set global group_replication_allow_local_disjoint_gtids_join=ON;

节点一:server5查看组成员

3.节点3server7配置

清空数据目录

修改配置文件/etc/my.cnf

[root@server7 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
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

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= "172.25.254.17:33061"
group_replication_group_seeds= "172.25.254.15:33061,172.25.254.16:33061,172.25.254.17:33061"
group_replication_bootstrap_group=off
group_replication_ip_whitelist="172.25.254.0/24,127.0.0.1/8"
group_replication_single_primary_mode=OFF
group_replication_enforce_update_everywhere_checks=ON
group_replication_allow_local_disjoint_gtids_join=1
~                                                  

初始化并修改管理员密码
关闭二进制日志记录，创建组复制用户并赋予权限

配置组复制，并启动

节点1（server5）查看组复制成员
三个节点的状态一定是online的，如果不是就是报错。现在三个节点都是主，也就是多主模式，当前组允许down一个节点。

二、测试

激活组复制后，对数据库是有要求的，innodb引擎创建表结构需要主键。

节点1插入表数据

mysql> CREATE DATABASE test;
mysql> use test;
mysql> desc t1;
mysql>  INSERT INTO t1 VALUES (1, 'Luis');

查看节点2和节点3

在节点二，往t1表插入数据，保证主键的值唯一

查看另外两个节点数据是否同步
在节点三上，往t1表插入数据，保证主键的值唯一

查看另外两个节点的数据是否同步

以上设置的mysql组复制其实就是mysql的分布式集群
数据库在企业的地位很高，企业的数据库就是企业的灵魂，现在数据不仅在mysql数据库，还有newsql，比如tidb就是一种。分布式数据库才能真正解决瓶颈，自带高可用、负载均衡。分布式主要问题就是解决单体的限制，分而治之，打破了单体的性能瓶颈，无论是硬件还是软件，单机都是有性能上限的，分布式可以通过水平扩容节点达到整体性能的提升。传统mysql主从还是有用的，包括组复制还是基于mysql主从，还是基于二进制日志，只不过校验逻辑边的更复杂。

上述多主组复制架构会出现一个问题，虽然每个节点都可以写入，且同步到不同节点，但每个节点只能删除该结点写入的数据否则会报错

故障分析 | mysql mgr 多主数据不能更新案例浅析