1.mysql的全同步复制(组复制)的基础知识
组复制模型:不分主从,都一样
它支持单主模型和多主模型两种工作方式(默认是单主模型)
单主模型:从复制组中众多个MySQL节点中自动选举一个master节点,只有master节点可以写,其他节点自动设置为read only
当master节点故障时,会自动选举一个新的master节点,选举成功后,它将设置为可写,其他slave将指向这个新的master
多主模型:复制组中的任何一个节点都可以写,因此没有master和slave的概念
只要突然故障的节点数量不太多,这个多主模型就能继续可用
组复制原理:
复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务
但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。
换句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,以确保组内一致。
组复制能够根据在一组 server 中复制系统的状态来创建具有冗余的容错系统。因此,只要它不是全部或多数 server 发生故障,即使有一些 server 故障,系统仍然可用,最多只是性能和可伸缩性降低,但它仍然可用。server 故障是孤立并且独立的。它们由组成员服务来监控,组成员服务依赖于分布式故障检测系统,其能够在任何 server 自愿地或由于意外停止而离开组时发出信号。
总之,MySQL 组复制提供了高可用性,高弹性,可靠的 MySQL 服务
但是组复制的效率很低
当master节点写数据的时候,会等待所有的slave节点完成数据的复制,然后才继续往下进行
组复制的每一个节点都可能是slave
2.实验环境(基于上个实验)
实验环境:(一主多从模式),一个master节点+两个slave节点
3.实现组复制过程(全同步)
组复制(全同步复制),互相主从,互相为master和slave
就相当于一个集群,都可以作为master和slave
只需要在一个上面开启组复制即可,大家都是master
(1)在server1上面进行设置(组同步的发起者)
查看一下UUID备用,三个节点的uuid使用同一个值,而且不能与三个节点自身的uuid相同
[root@server1 mysql]# vim /etc/my.cnf
binlog_checksum=NONE #关闭binlog校验
binlog_format=ROW #组复制依赖基于行的复制格式
loose-group_replication_bootstrap_group=off
##插件是否自动引导,这个选项一般都要off掉,只需要由发起组复制的节点开启,并只启动一次,如果是on,下次再启动时,会生成一个同名的组,可能会发生脑裂
loose-group_replication_single_primary_mode=OFF #后两行是开启多主模式的参数
启动数据库:
开启mysql服务 systemctl restart mysqld
初始化:
server1进行配置:
注:是通过主机名来识别主机的,所以主机之间要有解析。
server1上插入数据测试
(2)server2开始配置:
编辑配置文件 (修改的只有两个地方),开启服务
[root@server2 mysql]# vim /etc/my.cnf
查看报错日志得出解决方案:
[root@server2 mysql]# vim /var/log/mysqld.log
在server1上查看是否成功
第三台和server2配置一样:
测试:
其他两台都有数据
可以看出,已经实现了组复制
可以在任意一个节点写数据,其他两个节点会进行组复制
注:如你在重启服务时出现报错,有可能手残把配置文件写错了
找到错误后先执行一次关闭服务操作,然后删除mysql数据目录下的所有内容,再次尝试打开服务
开启组复制时报错,有可能是已经写入数据,两端数据不一致
change master的时报错,需要先将配置文件的最后一个模块注释掉,然后启动mysql服务