企业之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.实验环境

172.25.26.5 server5(master)
172.25.26.6 server6(slave)

2.部署过程

• server1（master）端的配置
  准备mysql的数据包

安装包解压:

a.安装解压后主从复制实现需要的安装包并将这5个安装包发给server2

b.打开数据库,并查看密码：

c.进行初始化

登录查看

编辑mysql的配置文件

重启服务使配置文件生效

创建用户授权

查看二进制日志是否打开

查看主库状态

• server6（slave）端的配置

安装mysql

数据库的初始化

• 开启mysql并查看密码
  
• 初始化

• 查看
  
  编写配置文件

重启服务

从设备的设置
== 注：log_file和log_position都为主设备上的数值==

开启从设备并且查看其状态

测试:
在主库中创建库和表并且插入数据

在从库登录查看数据是否同步

发现能查到复制成功

二.基于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的部署

• 主端配置：

主端添加gtid模式
配置文件/etc/my.cnf基于上次实验添加内容如下：

重启服务

查看主端的uuid

• 从端的配置
  编辑配置文件
  添加gtid模型：
  

.重启服务

先停掉slave，添加新的模式，然后再次开启

测试：
a.在主库中插入数据

b.在从库中查看

发现数据已经同步

三.基于gtid的半同步复制

1.定义

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

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

主库的配置（server5）

a.安装半同步设置的服务插件

b.开启半同步复制，并查看相应变量

环境变量：

状态变量：

从端的配置（server6）

a.安装插件开启半同步复制

b.先关闭半同步复制的io线程然后再打开，如果没有进行重启io线程操作，则默认还是异步复制

测试：

a.从端关掉io线程

b.在主端插入数据，会等待10s中，当发现slave挂掉后，10s后会自动变为异步复制

c.在主端查看半同步复制的情况

注：在从端的数据是没有同步过来的，当再次打开io线程，数据同步过来但是这是主从异步复制所同步的数据。