企业级mysql数据库集群实战——mysql的全同步复制(组复制)

本文介绍了MySQL 5.7.17引入的组复制功能,包括单主和多主模型,强调了高可用性和一致性。通过搭建一主多从的实验环境,详细阐述了全同步复制的配置步骤,以及解决配置过程中遇到的问题,最终验证了组复制的正确实现。
摘要由CSDN通过智能技术生成

1.mysql的全同步复制(组复制)的基础知识

组复制模型:
MySQL组复制是MySQL 5.7.17开始引入的新功能,为主从复制实现高可用功能
它支持单主模型和多主模型两种工作方式(默认是单主模型)
单主模型:从复制组中众多个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节点

主机名 IP 功能
server1 172.25.12.1 master节点
server2 172.25.12.2 slave节点
server3 172.25.12.3 slave节点

这个实验是在之前的半同步做完之后做的,因此要准备实验环境

  • (1)重新开启一台新的虚拟机server3
    在这里插入图片描述
  • (2)把server1上面的要安装的包传输给server3
    在这里插入图片描述
  • (3)给server3安装数据库
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值