lnmp架构-mysql（一）异步复制、异步GTID模式

lpf_linux

已于 2022-07-17 20:17:41 修改

阅读量275

点赞数

文章标签： mysql 数据库 linux

于 2022-07-13 16:10:08 首次发布

本文链接：https://blog.csdn.net/xxxxxxxxxxxxxz/article/details/125750019

版权

主从复制类别：

同步复制：Master会等待所有的Slave都回应后才会提交，同步性能最差。
异步复制：Master不用等待Slave回应就可以提交。
半同步复制：Master至少会等待一个Slave回应后提交。
延迟复制：Slave要落后于Master指定的时间。

1 异步复制

1 异步复制概念

传统的MySQL复制采用主从的方式进行，可以一主一从也可以一主多从主库执行一个事务，提交后稍后异步的传送到从库中

如果是基于语句的复制则会重新执行，如果是基于行的负责则会应用日志，同时是shared-nothing的架构，即所有服务器拥有同样的数据复制。

传统的MySQL主从复制架构是MySQL保持数据一致性的最基本架构，如下图所示，一主一从架构，从库给主库发起读数据请求后，主库会通过 dump线程把binlog日志文件推送给从库，从库的I/O线程把接收到数据更新到relay log，之后从库的SQL线程把relay log应用为binlog日志，直到主库与从库的binlog日志文件完全数据一致，达到主从同步。

接下来我们看一下MySQL 异步复制，如下图所示，一主两从架构，应用发来的事务请求，经过执行之后写入binlog，主库master把binlog日志推送给从库 salve1和slave2 ，主库不需要等到从库是否成功更新数据到relay log，主库直接提交事务即可。这种模式牺牲了数据一致性，不能很好保证主从数据一致性。

模拟异步复制场景举例，三个人对话，一个人在不停歇的演讲，不需要知道两个听众是否听懂，听众也不需要做出回应，等演讲完毕，有可能听众没听懂，最终大家认知到信息可能不一致，为了解决上述问题MySQL5.5.8 就有了半同步复制。

mysql一主多从:

流程：slave端向master拿认证，master的Binlog Dump线程始终监听master数据变更，有变更，将二进制日志数据发送给I/O线程（在slave端），I/O将接受到的二进制日志数据保存到relog中继日志，然后持久化到磁盘）；SQL线程读取中继日志数据，进行回放（和master作相同的操作），如果该slave有下一个slave，则将回放操作写入二进制日志中，供下一个slave获取进行回放。

一主多从：

1 A ->B,A->C,A把数据发给B和C，压力较大，适合读多写少的情况。

2 A ->B->C A把数据发给B，B 发给C，缓解了A的压力。

2 异步复制：一主多从A ->B->C

2.1 实验前准备：

server3上也要一个mysql数据库，复制server1、2上的数据库即可。不用重新编译

[root@server1 etc]# scp -r /usr/local/mysql/ server3:/usr/local/ #copy整个mysql安装目录

[root@server2 etc]# scp /etc/my.cnf server3:/etc/ #copy配置文件

[root@server2 etc]# scp /etc/init.d/mysqld server3:/etc/init.d/ #copy脚本

server3上：更改/etc/my.cnf配置文件，添加mysql用户，创建数据目录，改用户名用户组权限

server3数据库准备完成

2.2 一主多从A ->B->C（server1 -> server2 -> server3）

server1（A）上添加数据，server2（B）上获得server1的二进制日志，后使用I/O把二进制日志数据保存到B上的中继日志中（存储到磁盘文件中），B使用中继日志进行回放后，B把回放操作写进二进制日志供下一个slave（C）获取。

server2配置文件：配置完成重启服务/etc/init.d/mysqld restart

实验1：server1上添加数据,server2上中继日志回放（中继日志含有添加数据的操作），并把回放操作写入二进制日志中（二进制日志含有添加数据的操作）

[root@server2 mysql]# mysqlbinlog server2-relay-bin.000007 -v#查看中继日志

[root@server2 mysql]# mysqlbinlog mysql-bin.000001 -v#查看二进制日志

都有server1新添加数据

实验2：作一主多从时，三台机器上mysql数据库基础要一样，所以将server1、2的数据备份给server3

下面备份要锁表备份（备份过程不允许用户写）

实验3：一主多从A ->B->C

server3上授权访问server2，双yes表示设置主从成功

开始：

server1上添加新数据user4、5

server3、2上查看发现自动复制过来。

主上压力很大，作备份可以在从机上进行备份

上述一主多从问题：

master端只是

复制有延迟，网络也有延迟

3 GTID异步复制

解释1：在主从同步时 GTID_Event 和事务的 Binlog 会一起传递到从库，由中继日志接收，从库在执行的时候使用对应的 GTID 写 binlog；主从同步以后，可以通过 GTID 确定从库目前同步的位置了。在启动主从复制时，不需要指定 binlog 文件名和 postion 号，直接 auto 即可。MySQL 会自动读取最后一个 relay log，获取到上次已经复制的 GTID 号，从此号码开始向后复制即可。

解释2：master节点在更新数据的时候，会在事务前产生GTID信息，一同记录到binlog日志中。slave节点的io线程将binlog写入到本地relay log中。然后SQL线程从relay log中读取GTID，设置gtid_next的值为该gtid，然后对比slave端的binlog是否有记录。如果有记录的话，说明该GTID的事务已经运行，slave会忽略。如果没有记录的话，slave就会执行该GTID对应的事务，并记录到binlog中。

【简单来说：可以通过 GTID 自动找点，无需像之前那样通过 binlog 名和 position 号找点】

MySQL5.6 在原有主从复制的基础上增加了一个新的复制方式，即基于GTID的复制方式，它由UUID和事务ID两个部分组成，具有如下特点。

GTID事务是全局唯一性的，并且一个事务对应一个GTID值。

一个GTID值在同一个MySQL实例上只会执行一次。

GTID相较与传统复制的优势

主从搭建更加简便，不用手动特地指定position位置。

复制集群内有一个统一的标识，识别、管理上更方便。

故障转移更容易，不用像传统复制那样需要找 log_file 和 log_Pos的位置。

通常情况下GTID是连续没有空洞的，更能保证数据的一致性，零丢失。

相对于ROW复制模式，数据安全性更高，切换更简单。

比传统的复制更加安全，一个GTID在一个MySQL实例上只会执行一次，避免重复执行导致数据混乱或者主从不一致。