一.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线程,数据同步过来但是这是主从异步复制所同步的数据。