企业—Mysql主从复制,基于gtid的主从复制半同步复制

一.Mysql的主从复制技术

  • mysql的主从复制又叫replication,AB复制

1.复制的用途

  • 故障切换
  • 可创建读写分离,提供更好的查询服务
  • 把备份等操作都放在从服务器上进行,减少对业务的影响

2.复制存在的问题

  • 主机拓机后,数据可能丢失
  • 从库只有一个sql thread,主库写压力大时,复制可能延时
  • 一主多从,从机不宜过多,主服务器需要同时向多台服务器中写入数据,压力会很大,这个时候就需要使用集群了

3.复制原理

  • mysql主从复制是一个异步复制的过程。从一个实例(master)复制到另一个实例(slave),整个过程要由master上的I/O进程和slave上的sql进程和I/O进程共同完成。
  • 首先master必须打开binary log(bin-log),因为整个复制过程实际上就是slave端从master端获取相应的二进制日志,然后在本地完全顺序的执行日志中纪录的各种操作。

4.主从复制过程

  • Slave 端的 IO 进程连接上 Master,向 Master 请求指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
  • Master 接收到来自 Slave 的 IO 进程的请求后,负责复制的 IO 进程根据 Slave 的请求信息,读取相应日志内容,返回给 Slave 的IO进程,并将本次请求读取的 bin-log 文件名及位置一起返回给 Slave 端
  • Slave 端的 IO 进程接收到信息后,将接收到的日志内容依次添加到 Slave 端的 relay-log(中继日志) 文件的最末端,并将读取到的 Master 端的 bin-log 的文件名和位置记录到 master-info 文件中,以便在下一次读取的时候能够清楚的告诉 Master :”我需要从某个 bin-log 的哪个位置开始往后的日志内容,请发给我”;
  • Slave 端的 Sql 进程检测到 relay-log (中继日志)中新增加了内容后,会马上解析 relay-log 的内容成为在 Master 端真实执行时候的那些可执行的内容,并在本地执行。

过程中产生三个线程(thread):

  • 两个 IO线程:主库会创建一个线程,用来发送 binlog 内容到从库;从库I/O线程读取主库的 binlog 输出线程发送的更新并拷贝这些更新到本地文件,其中包括 relay-log(中继日志) 文件
  • 一个 SQL线程:SQL负责将中继日志应用到 slave 数据库中,完成 AB (主从)复制数据同步。

二.主从复制实现

1.实验环境

主机名(IP)用途
server1(172.25.254.1)matser
server2(172.25.254.2)slave

2.部署过程

  • server1(master)端的配置

a.官网下载安装包并且在主库中安装mysql

  • 安装包解压
    在这里插入图片描述

  • 安装解压后主从复制实现需要的安装包并将这5个安装包发给server2
    在这里插入图片描述
    在这里插入图片描述
    b.打开数据库
    在这里插入图片描述
    c.查看密码
    在这里插入图片描述
    d.进行初始化
    在这里插入图片描述
    e.登录查看
    在这里插入图片描述
    f.编辑mysql的配置文件
    在这里插入图片描述
    文件添加内容如下:
    在这里插入图片描述
    g.重启服务使配置文件生效
    在这里插入图片描述
    h.创建用户授权
    在这里插入图片描述

  • 查看二进制日志是否打开
    在这里插入图片描述

  • 查看主库状态
    在这里插入图片描述

  • server2(slave)端的配置

a.安装mysql
在这里插入图片描述
b.数据库的初始化

  • 开启mysql并查看密码
    在这里插入图片描述
  • 初始化
    在这里插入图片描述
  • 查看
    在这里插入图片描述
    c.编写配置文件
    在这里插入图片描述
    文件添加内容如下:
    在这里插入图片描述
    d.重启服务
    在这里插入图片描述
    e.从设备的设置
    注:log_file和log_position都为主设备上的数值
    在这里插入图片描述
    f.开启从设备并且查看其状态
    在这里插入图片描述
  • 测试

a.在主库中创建库和表并且插入数据
在这里插入图片描述
b.在从库登录查看数据是否同步
在这里插入图片描述
发现能查到复制成功

二.基于gtid的主从复制

1.基于gtid主从复制简介

  • mysql数据库从5.6.5开始新增一种基于gtid的复制方式。gtid(global transaction id)是对于一个已提交事务的编号。gtid实际上是由uuid+tid组成的,其中uuid是mysql实例的一个标识,tid则代表了该实例上交的事务数量,并且随着事务的提交单调递增。
  • 主从复制默认是通过pos(position)复制,就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个事件都有一个起始编号,一个终止编号,在配置主从复制节点时,要求其从master的pos开始同步数据库里面的数据,这也称作传统复制技术。
  • gtid就是类似pos的作用,不过它是整个mysql复制架构全局通用的,即在整个mysql冗余架构中,它们的日志文件里面事件的gtid的数值是一致的。
  • gtid是一个对于已提交的事物的编号,并且是一个全局唯一的编号。
  • 通过gtid保证每个主库上提交的事务在集群中有一个唯一的id。这种方式强化了主备的一致性,故障恢复及其容错能力。

2.pos与gtid的区别

俩者都是日志文件里的一个标志,如果将整个mysql集群看作一个整体,pos就是局部的,gtid就是全局的。

3.gtid的部署

  • 主端配置:

a.主端添加gtid模式

配置文件添加内容如下:
在这里插入图片描述
b.重启服务
在这里插入图片描述
c.查看主端的uuid
在这里插入图片描述

  • 从端的配置

a.编辑配置文件
添加gtid模型:
在这里插入图片描述
b.重启服务
在这里插入图片描述
c.先停掉slave,添加新的模式,然后再次开启
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

  • 测试
    a.在主库中插入数据
    在这里插入图片描述
    b.在从库中查看
    在这里插入图片描述
    发现数据已经同步

三.基于gtid的半同步复制

1.定义

  • MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理,这样就会有一个问题,主如果挂掉了,此时主上已经提交的事务可能并没有传到从上,如果此时,强行将从提升为主,可能导致新主上的数据不完整。则半同步复制就解决数据丢失的问题。

2.基于gtid的半同步的部署

  • 主库的配置(server1)

a.安装半同步设置的服务插件
在这里插入图片描述
b.开启半同步复制,并查看相应变量
在这里插入图片描述
环境变量:
在这里插入图片描述
状态变量:
在这里插入图片描述

  • 从端的配置(server2)

a.安装插件开启半同步复制
在这里插入图片描述
b.先关闭半同步复制的io线程然后再打开,如果没有进行重启io线程操作,则默认还是异步复制
在这里插入图片描述

  • 测试:

a.从端关掉io线程
在这里插入图片描述
b.在主端插入数据,会等待10s中,当发现slave挂掉后,10s后会自动变为异步复制
在这里插入图片描述
c.在主端查看半同步复制的情况
在这里插入图片描述
注:在从端的数据是没有同步过来的,当再次打开io线程,数据同步过来但是这是主从异步复制所同步的数据。

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值