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