mysql高可用 之 组复制（全同步)的实现

组复制

MGR(MySQL Group Replication)
组复制是MySQL5.7版本出现的新特性，它提供了高可用、高扩展、高可靠的MySQL集群服务。
MySQL组复制分单主模式和多主模式，mysql 的复制技术仅解决了数据同步的问题，如果 master 宕机，意味着数据库管理员需要介入，应用系统可能需要修改数据库连接地址或者重启才能实现。（这里也可以使用数据库中间件产品来避免应用系统数据库连接的问题，例如 mycat 和 atlas 等产品）。
组复制在数据库层面上做到了，只要集群中大多数主机可用，则服务可用，也就是说3台服务器的集群，允许其中1台宕机。

组复制的原理

组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的server集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制，实现了基于复制协议的多主更新。

复制组由多个 server成员构成,并且组中的每个server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。换句话说, 对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。

一个Replication-group就是一组节点，每个节点都可以独立执行事务，而读写事务则会在于group内的其他节点进行协调之后再commit。因此，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。

组复制的模式

single-primary mode(单写模式) 组内只有一个节点负责写入，读可以从任意一个节点读取，组内数据保持最终一致；
multi-primary mode(多写模式)，即写会下发到组内所有节点，组内所有节点同时可读，也是能够保证组内数据最终一致性。

组复制的特点

• 高一致性
  在master-slave之间实现了强一致性；
  对于只读事务，组间实例无需进行通讯，就可以处理事务；对于读写(RW)事务，组内所有节点必须经过通讯，共同决定事务提交与否。
• 高容错性
  确保组内高可用。只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；
• 高扩展性
  良好的扩展能力，可动态增删节点，组成员自动管理。节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；
• 高灵活性
  有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；
  多主模式下，所有 server 都可以同时处理更新操作。
• 多写，写冲突检测;
  在高并发的多写模式下，节点间事务的提交可能会产生冲突，比如，两个不同的事务在两个节点上操作了同一行数据，这个时候就会产生冲突。首先，Group Replication（GR）能够识别到这个冲突，然后对此的处理是，依赖事务提交的时间先后顺序，先发起提交的节点能够正确提交，而后面的提交，会失败
• 故障检测
  MGR自带故障检测机制，可以识别组内成员是否挂掉(组内节点心跳检测)。当一个节点失效，将由其他节点决定是否将这个失效的节点从group里面剔除。

组复制的故障检测

组复制故障检测

故障检测是提供关于哪些 server 可能已死的信息(猜测)的分布式服务。 某个 server 无响应时触发猜测，组中其余成员进行协调决定以排除给定成员。如果某个 server 与组的其余成员隔离,则它会怀疑所有其他 server 都失败了。由于无法与组达成协议(因为它无法确保仲裁成员数),其怀疑不会产生后果。当服务器以此方式与组隔离时,它无法执行任何本地事务。 在线 server 列表通常称为视图，新成员server的加入离开，无论是自愿还是被迫的离开，该组都会动态地重新规划其配置,并触发视图更新。

实验步骤(多主模式的实现)

让serevr 1server2 server3成为一个组，一起对外提供服务。实现多主模式，serevr1和server2和server3都可以写和读，只要一个上面写，其他两台都会同步数据。

实验环境:

server1  主数据库  172.25.2.10
server2  从库1   172.25.2.11
server3  从库2  172.25.2.254


关闭3台主机的防火墙和selinux 

由于之前在虚拟机上对mysql做了一些配置，需要对将之前的操作清除。

serevr1的配置（组复制发起者)

1.关闭 mysqld systemctl stop mysqld

观察server1上mysql的uuid

2.删除server1上的 mysql 数据
3.修改serevr1的配置文件

group_replication_bootstrap_group=off ##插件是否自动引导， 这个选项一般都要 off 掉，只需要由发起组复制的节点开启，并只启动一次，如果是 on，下次再启动时，会生成一个同名的组，可能会发生脑裂

5.初始化数据库

grep password /var/log/mysqld.log

6.登录数据库，先修改密码
7.登录数据库
8.配置server1
关闭二进制日志，防止传到其他 server 上

添加用户

CREATE USER rpl_user@'%' IDENTIFIED BY 'W..';

为用户做授权

GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; 

刷新FLUSH PRIVILEGES;

开启日志

表明做组复制

CHANGE	MASTER	TO	MASTER_USER='rpl_user',
MASTER_PASSWORD='Wsp+123ld' FOR CHANNEL 'group_replication_recovery'; mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';

##加载组复制的插件

发现报错，原因是已经存在，之前在配置文件里写过。
查看插件
开启组复制，只有组复制发起节点开启这个参数

SET GLOBAL group_replication_bootstrap_group=ON;

START GROUP_REPLICATION;

让serevr1成为组里面的一员

SET GLOBAL group_replication_bootstrap_group=OFF;

查看 server1 是否 online

基于域名，因此hosts文件需要做好。

 SELECT * FROM performance_schema.replication_group_members; 

server2的配置(添加server2到组内）

复制server1的my.cnf文件，做一些改动就好.

注意几个serevr的UUID也就是_group_name必须一样

启动 mysqld

systemctl start mysqld

初始化

grep password /var/log/mysqld.log

登录mysql
登录mysql

进行相应配置

 SET SQL_LOG_BIN=0; 

CREATE USER rpl_user@'%' IDENTIFIED BY 'W..';

GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';

FLUSH PRIVILEGES;

开启二进制日志

 SET SQL_LOG_BIN=1;

这里不需要做 server1 上做的 SET GLOBAL group_replication_bootstrap_group=ON;

下载插件时，显示错误,因为已经安装。
开启组复制

START GROUP_REPLICATION;

开启组复制可能会报错,查看 mysql 日志’ ‘cat /var/log/mysqld.log ,找到解决办法’

停止组复制.

STOP GROUP_REPLICATION; 

set global group_replication_allow_local_disjoint_gtids_join=on; 

重新开启组复制就可以

将上述操作，在server3中做一次，只需要更改文件的某些地方就可以
配置好后在 server1 上查看

 SELECT * FROM performance_schema.replication_group_members;

可以看到三台serevr都上线。
表示正常这时在任何一个节点都可以看到刚才插入的数据
在任何节点写入数据，其他节点也能看到。

测试

比如在serevr3上插入数据，更改数据库，在其他两台主机上都能看到刚插入的数据。