mysql 主从复制基于gtid的同步复制，并行复制，半同步复制

傷城~ 2022-05-10 11:54 273阅读 0赞

## **一、mysql 主从复制** ##

**1.主从形式**

mysql主从复制 灵活

*  一主一从
 *  主主复制
 *  一主多从---扩展系统读取的性能，因为读是在从库读取的；
 *  多主一从---5.7开始支持
 *  联级复制---

**2.主从复制的用途及部署条件**

mysql主从复制用途

*  实时灾备，用于故障切换
 *  读写分离，提供查询服务
 *  备份，避免影响业务

主从部署必要条件：

*  主库开启binlog日志（设置log-bin参数）
 *  主从server-id不同
 *  从库服务器能连通主库

**3.主从原理**

mysql主从复制的原理

其通过三个线程来完成，在master节点上运行的binlogdump线程以及在slave节点上运行的I/O线程和SQL线程。  
1. master节点上的binlogdump线程，在slave与其正常连接的情况下，将binlog发送到slave上。  
2.slave节点上的I/O线程，通过读取master节点发送的内容，并将数据复制到本地的relaylog中。  
3.slave节点上的SQL线程，读取relaylog中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

## **二、主从复制--异步复制** ##

MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。  
实验环境：

Mysql5.7版

linux系统版本：Redhat 6.5版

系统防火墙关闭

server2:(Master)

server3:(Slave)

**1.master和 slave 数据库的搭建**

安装以下软件包

mysql-community-client-5.7.17-1.el6.x86\_64.rpm  
mysql-community-common-5.7.17-1.el6.x86\_64.rpm  
mysql-community-devel-5.7.17-1.el6.x86\_64.rpm  
mysql-community-libs-5.7.17-1.el6.x86\_64.rpm  
mysql-community-libs-compat-5.7.17-1.el6.x86\_64.rpm  
mysql-community-server-5.7.17-1.el6.x86\_64.rpm

**2.master 的部署**

\[root@server2 ~\]\# vim /etc/my.cnf

server-id=1
    log-bin=mysql-bin

server-id 为服务器的默认id ,master 和 slave 不能相同，只要是整数即可

log-bin 表示二进制日志

\[root@server2 ~\]\# /etc/init.d/mysqld start

在日志里查找数据库的原始密码

![70][]

\[root@server2 ~\]\# mysql\_secure\_installation    初始化数据库，并设定新密码

密码格式为：字母大小写+符号+数字 (大于8位）

![70 1][]

![70 2][]

![70 3][]

![70 4][]

查看数据库是否搭建成功

\[root@server2 ~\]\# mysql -p

![70 5][]

可以查看master 的id

![70 6][]

授权slave 以 repl 的身份从master的网段登陆，密码为自己设置的mysql 密码

mysql> grant replication slave on \*.\* to repl@'172.25.254.%' identified by 'WESTOS.com123';

授权后查看 master id  会发生变化

![70 7][]

**3.slave 的部署**

测试刚才master的授权是否成功

登陆密码为授权的密码

测试后要退出mysql

![70 8][]

\[root@server3 ~\]\# vim /etc/my.cnf

server-id =2

\[root@server3 ~\]\# /etc/init.d/mysqld start

\[root@server3 ~\]\# grep password /var/log/mysqld.log   查看初始密码  
2018-09-28T01:39:56.901926Z 1 \[Note\] A temporary password is generated for root@localhost: GwrgWQ0o=0ak

\[root@server3 ~\]\# mysql\_secure\_installation   初始化数据库，设置mysql密码

\[root@server3 ~\]\# mysql -p

![70 9][]

开启selave 并查看其状态

若io 线程和sql 线程都已开启，则表示成功

![70 10][]

4.测试是否同步

在master 中

创建一个库和表，并在表里写入数据

![70 11][]

在selave 中查看是否有master 中所创建的数据

![70 12][]

证明mysql 的同步复制成功

## **三、基于GTID的同步复制** ##

**1.GTID工作原理**

*  master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
 *  slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
 *  sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
 *  如果有记录，说明该GTID的事务已经执行，slave会忽略。
 *  如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
 *  在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

**2. GTID的优点：**

*  一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次
 *  GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置
 *  减少手工干预和降低服务故障时间，当主机挂了之后通过软件从众多的备机中提升一台备机为主机

**3.同步部署**

**实验环境同上**

1）在master 和 selave 中的/etc/my.cnf同时添加参数

vim /etc/my.cnf

表示开启gtid模块

![70 13][]

/etc/init.d/mysqld restart

2）在selave 中

![70 14][]

![70 15][]

**4.测试**

在master 中

进入所创建的库中，在其所创建的表中写入数据

![70 16][]

在selave 中 查看是否同步数据

![70 17][]

数据完全一致，说明搭建成功

## **四、半同步复制** ##

*  半同步复制的原理  
    1、当Slave主机连接到Master时，能够查看其是否处于半同步复制的机制。  
    2、当Master上开启半同步复制的功能时，至少应该有一个Slave开启其功能。此时，一个线程在Master上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的Slave已收到此事务的所有事件，或等待超时。  
    3、当一个事务的事件都已写入其relay-log中且已刷新到磁盘上，Slave才会告知已收到。  
    4、如果等待超时，也就是Master没被告知已收到，此时Master会自动转换为异步复制的机制。当至少一个半同步的Slave赶上了，Master与其Slave自动转换为半同步复制的机制。  
    5、半同步复制的功能要在Master，Slave都开启，半同步复制才会起作用；否则，只开启一边，它依然为异步复制。
 *  同步，异步，半同步复制的对比
    
     *  同步复制：Master提交事务，直到事务在所有的Slave都已提交，此时才会返回客户端，事务执行完毕。缺点：完成一个事务可能会有很大的延迟。
     *  异步复制：当Slave准备好才会向Master请求binlog。缺点：不能保证一些事件都能够被所有的Slave所接收。
     *  半同步复制：半同步复制工作的机制处于同步和异步之间，Master的事务提交阻塞，只要一个Slave已收到该事务的事件且已记录。它不会等待所有的Slave都告知已收到，且它只是接收，并不用等其完全执行且提交。

**1.master 部署**

部署半同步模块 安装插件

![70 18][]

设置临时同步

![70 19][]

永久设定同步

vim /etc/my.cnf  设置变量，启用半同步复制

![70 20][]

/etc/init.d/mysqld restart

**2.在selave 中 安装插件**

![70 21][]

设置变量 启用半同步模式

![70 22][]

重新连接主服务器（半同步才会生效）

![70 23][]

**3.master 上查看是否启用了半同步**

主要看 Rpl\_semi\_sync\_master\_clients 是否为1，

Rpl\_semi\_sync\_master\_status               是否为ON

若符合则表示半同步复制机制已经正常工作，如果Rpl\_semi\_sync\_master\_status   为OFF，说明出现了网络延迟或selave io 线程延迟

![70 24][]

**4.测试**

slave上关闭io\_thread

![70 25][]

然后在master上执行数据库操作，比如插入等，结果就是操作会等待10s返回结果，这时候退回异步复制，slave上没有接收到数据，这时候我们去查看master上的相关状态：

在 master 上创建数据

此时插入数据会有一个10s的timeout，所以会卡顿一会，有些参数的值也变了：

![70 26][]

在selave 中查看是否同步

![70 27][]

在selave 开启io\_thread再去查看数据库的变化，发现数据同步了

![70 28][]

## **五、并行复制** ##

**1.并行复制的简介**

*  一般主从复制，有三个线程参与，都是单线程：Binlog Dump（主） —–>IO Thread （从） —–> SQL Thread（从）。复制出现延迟一般出在两个地方  
    1）SQL线程忙不过来（可能需要应用数据量较大，可能和从库本身的一些操作有锁和资源的冲突；主库可以并发写，SQL线程不可以；主要原因）  
    2）网络抖动导致IO线程复制延迟（次要原因）。  
    　　MySQL从5.6开始有了SQL Thread多个的概念，可以并发还原数据，即并行复制技术。
 *  MySQL5.6中，设置参数slave\_parallel\_workers=4(>1)，即可有4个SQL Thread（coordinator线程）来进行并行复制，其状态为：Waiting for an evant from Coordinator。  
    但是其并行只是基于Schema的，也就是基于库的。如果数据库实例中存在多个Schema，这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形，  
    那基于库的并发就没有卵用。其核心思想是：不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致。
 *  在MySQL 5.7中，引入了基于组提交的并行复制（Enhanced Multi-threaded Slaves），设置参数slave\_parallel\_workers>0并且global.slave\_parallel\_type＝‘LOGICAL\_CLOCK’，即可支持一个schema下，slave\_parallel\_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想：一个组提交的事务都是可以并行回放（配合binary log group commit）；  
    slave机器的relay log中 last\_committed相同的事务（sequence\_num不同）可以并发执行。  
    其中，变量slave-parallel-type可以有两个值：DATABASE 默认值，基于库的并行复制方式；LOGICAL\_CLOCK：基于组提交的并行复制方式

**2. 部署**

添加一台selave (server4)

1)在 第一台 selave 上

vim /etc/my.cnf

![70 29][]

/etc/init.d/mysqld restart

2)部署新的selave

安装mysql

vim /etc/my.cnf

server-id=3

/etc/init.d/mysqld  start

\[root@server4 mysql\]\# grep password /var/log/mysqld.log

\[root@server4 mysql\]\# mysql\_secure\_installation

3）在第一台 selave 上

![70 30][]

4）在新的selave 中测试授权是否成功

![70 31][]

5)在master 中

*  master\_info\_repository解释  
    开启MTS功能后，务必将参数master\_info\_repostitory设置为TABLE，这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升，资源的竞争也会变大。在之前InnoSQL的版本中，添加了参数来控制刷新master.info这个文件的频率，甚至可以不刷新这个文件。因为刷新这个文件是没有必要的，即根据master-info.log这个文件恢复本身就是不可靠的。在MySQL 5.7中，I可以将master\_info\_repository设置为TABLE，来减小这部分的开销。
 *  slave\_parallel\_workers解释  
    若将slave\_parallel\_workers设置为0，则MySQL 5.7退化为原单线程复制，但将slave\_parallel\_workers设置为1，则SQL线程功能转化为coordinator线程，但是只有1个worker线程进行回放，也是单线程复制。然而，这两种性能却又有一些的区别，因为多了一次coordinator线程的转发，因此slave\_parallel\_workers=1的性能反而比0还要差

vim /etc/my.cnf

slave-parallel-type=LOGICAL\_CLOCK

slave-parallel-workers=16

master\_info\_repository=TABLE

relay\_log\_info\_repository=TABLE

relay\_log\_recovery=ON

/etc/init.d/muysqld restart

将库的内容导入到westos.sql文件中，并传到server4上

\[root@server2 ~\]\# mysqldump -p westos > westos.sql

\[root@server2 ~\]\# scp westos.sql server4:

6）在新slave 中

因为server4中没有westos库，在文件中先创建库

\[root@server4 ~\]\# vim westos.sql

![70 32][]

恢复westos库

\[root@server4 ~\]\# mysql -p < westos.sql

![70 33][]

**3.测试**

在master 中写入数据

![70 34][]

在server3（selave）中查看是否同步

![70 35][]

在server4(selave)中查看是否同步

![70 36][]

两台selave都同步了master的数据，说明达到了并行复制的效果

[70]: /images/20220510/2dafddded3d8467699bd479b165b0796.png
[70 1]: /images/20220510/0e35d14d354542fd8116c072f244bab9.png
[70 2]: /images/20220510/d1fb2f8e9a704c67a17509949ef6618a.png
[70 3]: /images/20220510/2b69d0542dee463aa6d09ab6ad1f8116.png
[70 4]: /images/20220510/6f18583c4df043aa9fdb4d80b6b5a349.png
[70 5]: /images/20220510/4a1171bfe11f486e865f5e8d16d3105a.png
[70 6]: /images/20220510/a69ce90c40864e2cb558d5c8ac5c1b85.png
[70 7]: /images/20220510/79aa9e09598449659b0d8091e43f798f.png
[70 8]: /images/20220510/5311fd5958fe467c931e84e3a0ebcd81.png
[70 9]: /images/20220510/69e10c18fd5d488ca702331613bd251b.png
[70 10]: /images/20220510/6c62114c5e7e4ab9b771215e01c0dcbe.png
[70 11]: /images/20220510/4301baed7dfe4556a432d7fa2fa0eeff.png
[70 12]: /images/20220510/ffbc5d2db8c14aba91ed3f22b2245291.png
[70 13]: /images/20220510/12fd06e478cb4bb096d15c59865b9c35.png
[70 14]: /images/20220510/8b3215273c8c4a65b3f898e7d0699edd.png
[70 15]: /images/20220510/b81bb9c194854d79a088366bf483ad80.png
[70 16]: /images/20220510/f7cc80ef9c54431ba73f6231009d83f8.png
[70 17]: /images/20220510/5a24e7b1c22d4b649e4db9d0bbda7520.png
[70 18]: /images/20220510/821309b63d4a41ddbfa8a42d23a2f6bb.png
[70 19]: /images/20220510/ae8bb954555a4e6b8283d030a16ca3fd.png
[70 20]: /images/20220510/0215db28b5df46d5bdf9321a33502e16.png
[70 21]: /images/20220510/4f19452dc21d453684a91ff41e8ff3bd.png
[70 22]: /images/20220510/5e9d9e54c03e433e9adb0bfe7f9caa3e.png
[70 23]: /images/20220510/6b2a08c7767b472ea08fc290ee125a76.png
[70 24]: /images/20220510/9d15cc61212543a09d396884baad7716.png
[70 25]: /images/20220510/c17813bc613144769d664bb26b08e944.png
[70 26]: /images/20220510/e3ab8a7b84f2471387c0330272e6f036.png
[70 27]: /images/20220510/d9596407adc24673a21b11ee7924da82.png
[70 28]: /images/20220510/68fb90c278984c448df3094260377a06.png
[70 29]: /images/20220510/17459517067947f7bd2b57427d65efeb.png
[70 30]: /images/20220510/b62255b937b74ff7b6ce54533432a0d7.png
[70 31]: /images/20220510/9cac7fc22ace4a0798c08ce1c53b0c73.png
[70 32]: /images/20220510/25cdc34d42d048a8ad9fe6bdc7f914f9.png
[70 33]: /images/20220510/254188ba3cff43789e6f7b8c782e0525.png
[70 34]: /images/20220510/8ef8c114c9ad43e0862dc8bd44b9cf23.png
[70 35]: /images/20220510/80c876b1b47a4458b2168733650b7219.png
[70 36]: /images/20220510/74bcb0ba9f6542d7a72ac68aa888ab97.png