Lamp——mysql组复制协议（全同步机制）

---

** 默认MySQL主从复制方式是异步的，after_commit模式和after_sync模式是半同步方式。**
同步方式复制对数据一致性要求高，速度最慢。
同步方式的部署分为单主模式和多主模式。
多主模式是每个节点都可以对数据写，单主模式是只能master写数据。mysql的主从复制是单主模式，salve不可以对数据写。

当集群中的任何节点在执行的时候，都会将日志发送到集群中所有节点上，然后开始校验。只要有一个节点校验不通过，那么所有节点都不做该操作。

MySQL集群，基于组复制技术，每个节点即是主又是从，每个节点都可以主从复制

实验环境：
server5上安装了MHA管理器，关闭server5.
server2、server3和server4构成MySQL集群。server2为引导节点。

可以根据官方文档进行。

搭建MySQL集群，实现组复制

server3关闭mysqld

server4关闭mysqld

server2关闭mysqld：
将mysql的数据文件清空。（至于数据文件在哪个目录，可以查看/etc/my.cnf中的datadir）
并编写主配置文件

将虚拟机上的mysql卸载，重装了一次，发现 /etc 下没有 my.cnf 文件 !!!
使用mysql --help | grep my.cnf
可以查看到mysql 是从哪些目录读取配置文件的，然后自己 vim my.cnf 并将自己写的 my.cnf 文件放到这个目录中，重启mysql就可以识别自己的配置文件了。

在重启mysql服务之前，一定要确认mysql的数据文件目录是空的。
重启服务之后，进行初始化

server2为引导节点

将server2上的配置文件传到server3上

先将server3的mysqld关闭，并把mysqld的数据文件目录清空。


MySQL初始化

server2为引导节点，server3只需开启组复制即可。


设置server3强制加入


在server2上可以看到集群中成员的状态。
如果看到某个成员，比如server3的状态是RECOVERING，
那么就要查看serve3的日志，cat /var/log/mysqld.log
在做实验的时候，有一次server3的状态是RECOVERING，查看日志，发现是server3和server2上的域名解析没写对。将/etc/hosts文件写正确就好了。

server2将配置文件传给server4
同样地，server4先将mysql服务关闭，并数据文件目录清空。

server4的my.cnf 因为是直接从server2复制来的，直接修改server-id 以及local_address就好
在最后加上，强制加入集群
vim /etc/my.cnf

在server2上查看到集群成员的状态为online

在server2上创建数据库test，并在test中创建表t1，并插入一条数据。

在server3上可以同步到server2上的数据，查看到数据库test，
server3也可以对数据进行写操作

server4上可以读取到server2与server3写的数据
同时，server4也可以写数据

server2上也可以看到server3和server4上写的数据

成员故障

这时，server2突然down。。。

server3看到只有server4和自己是online。
server3再向数据库中写入数据
server4还是能查看到数据的更改。

server2恢复
需要重新加入组复制
并且server2能查看到自己down时，数据发生的更改。

集群中的成员能及时查看成员状态。

server2、server3、server4构成一个MySQL集群，该集群中每个成员既是主又是从，每个成员都可以主从复制。