Mysql 的复制、读写分离和基于MHA的高可用

柔情只为你懂 2022-05-24 00:18 130阅读 0赞

## 一、数据库的主从复制（基于gtid） ##

配置环境：server2为master  ip:172.25.77.2

server3为slave     ip:172.25.77.3

我这里使用的mysql版本为5.7

修改master的配置文件如图：

log-bin=mysql-bin 开启二进制日志；二进制日志必须开启，因为数据的同步实质上就是其他的MySQL数据库服务器将这个数据变更的二进制日志在本机上再执行一遍。

开启gtid模式

![20180516215519228][]

slave端配置如图

![20180516215651919][]

master登陆mysql 进行授权：

mysql>GRANT REPLICATION SLAVE ON \*.\* TO ‘admin’@’172.25.77.%’ IDENTIFIED BY ‘Redhat-98k’;

mysql>FLUSH PRIVILEGES;刷新数据使其更新

在slave指定要复制的master;

change master to master\_host='172.25.77.2',master\_user='admin',master\_password='Redhat-98k',master\_auto\_position=1;

slave端开启服务 start slave;

查看状态：SQL线程和IO线程，这两个线程yes即主从复制完成

![20180516220948583][]

测试：

master端创建linux数据库，并插入表kkk，写入内容如图：

![20180516221112965][]

slave端查看同步是否成功：

![20180516221154334][]

## 二、基于组提交的并行复制 ##

基于组的并发复制，可以支持在一个database中，并发执行relaylog中的事务。相同的二进制日志组在master上提交并行应用到slave节点上，没有跨数据库的限制，并且不需要把数据分割到多个数据库。

更改slave配置文件

![20180516222901950][]

slave-parallel-type=LOGICAL\_CLOCK 基于组提交的并行用户  
slave-parallel-workers=16         开启16个work：单线程变成多线程（前两个必须加入，后面为优化）  
master\_info\_repository=TABLE      优化选项，默认以文件存储，记录master信息，用表来记录，更新速度更快     
relay\_log\_info\_repository=TABLE  读日志信息，用表来记录（原来是刷在磁盘里）

relay\_log\_recovery=ON            激活recovery：读取master二进制日志，如果损坏，直接丢弃然后重新读取

配置完成，查看三个表的信息

![20180516223013573][]

![20180516223024686][]![20180516223032471][]![20180516223040946][]

master进程查看

![20180516224405893][]

slave进程查看![20180516224422935][]

##     ##

## 三、半同步复制    ##

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

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

配置：

两边进入数据库加入模块 开启即可，如果要用久生效写到配置文件里即可

master端：

INSTALL PLUGIN rpl\_semi\_sync\_master SONAME 'semisync\_master.so';  
set global rpl\_semi\_sync\_master\_enabled = 1;

slave端：将master改为slave即可

master端查看如下图

默认超时时间为10000ms(10s)

![20180516224747812][]

slave端查看

![20180516224812302][]

激活半同步复制

slave：stop slave io\_thread;停止slave的IO线程，再次开启即可

## 五、读写分离    ##

mysql的读写分离的基本原理是：让master（主数据库）来响应事务性操作，让slave（从数据库）来响应select非事务性操作，然后再采用主从复制来把master上的事务性操作同步到slave数据库中。

配置环境

server4安装mysql-proxy调度器

server2和server3继续上面的样子

将mysql-proxy写到环境变量里，方便操作

![20180516225606764][]

配置mysql-proxy

![20180516225752360][]

![20180516225824807][]

pid-file=/usr/local/mysql-proxy/logs/mysql-proxy.pid    需要创建logs目录

proxy-address=172.25.32.9:3306                           调度ip  
proxy-read-only-backend-addresses=172.25.32.8:3306       只读ip（slave）  
proxy-backend-addresses=172.25.32.7:3306                 只写ip(master)

proxy-lua-script=/usr/local/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua (lua脚本文件位置)

更改lua脚本

![20180516230006565][]

mysql-proxy  --defaults-file=/usr/local/mysql-proxy/conf/mysql-proxy.conf &完成后读取文件，会报错，根据错误修改

![2018051623025095][]

完成后，再次启动，并查看端口信息

![20180516230339861][]

三台虚拟机安装lsof监控工具，进行监控，查看3306端口哪个终端占用

![20180516230616578][]![20180516230627118][]![20180516230634800][]

master端授权远程登陆数据库的用户

![20180516230807823][]

选择真机进行登陆和插入

![20180516230919425][]

此时，查看监控可知：连接到master端

![20180516231004598][]

插入信息：

![20180516234408110][]![20180516234426535][]

## 六、数据库的级联复制 ##

**级联复制**：是指从主场地复制过来的又从该场地再次复制到其他场地，即A场地把数据复制到B场地，B场地又把这些数据或其中部分数据再复制到其他场地。

Master ：  172.25.77.2        =>主节点    server2

slave1   :    172.25.77.3        =>中继节点 server3

slave2   :    172.25.77.5                              server5  
  
1）先将master的库内容拷贝一份，手动把主库数据导入salve2库  
![20180517194153887][]

slave2创建这个库，并将数据导入

![20180517194305494][]![20180517194317326][]

slave2查看登陆

![20180517194350230][]

2）各个节点mysql配置文件

master如图

![20180517194815105][]

slave1配置如图

![20180517194913194][]

log\_slave\_updates=1   \#\#将B服务器从A服务器收到的更新记入到B服务器自己的二进制日志文件中，这样才能同步主库A的数据

slave2配置如图

![20180517195023692][]

3）slave1向slave2授权

![20180517195417548][]

完成后server5检验授权情况，如图表示成功

![20180517195438928][]

slave2开启复制功能

![20180517195527283][]

完成后slave2检验是否成功完成，slave2-->slave1

![20180517195627839][]

## 七、Mysql的高可用（MHA） ##

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

**该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）**。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

这里用server4：172.25.77.4作管理节点

![20180517200625118][]

server2、server3、server5作MHA数据节点

![20180517200453113][]

目前MHA主要支持一主多从的架构，**要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，**一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.7的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

配置环境：

MHA管理：server4 172.25.77.4

MHA数据节点：一主两从采用半同步复制

master: server2： 172.25.77.2

备用master server3：172.25.77.3

从库：server5：172.25.77.5

1）现在上面的级联复制的基础上，server2对server5授权

![2018051720125164][]

将server5复制指向server2

![20180517201408564][]

查看是否成功

![20180517201431799][]

三台机器开启半同步复制，即在配置文件中加入模块，但要注意每个配置文件除了sever-id都相同，保证既可以作master也可以作slave

\+![20180517202036920][]

完成后一一查看模块加入是否成功

![20180517202246207][]

这里三台数据节点搭建完毕

2)在sever4管理端

创建MHA的工作目录，并且创建相关配置文件

![20180517202518599][]

![20180517202852717][]  
manager\_workdir=/etc/masterha/              \#\#manager的工作目录  
manager\_log= /etc/masterha/manager.log      \#\#manager的日志  
master\_binlog\_dir=/var/lib/mysql                     \#\#master 保存binlog的位置，以便MHA可以找到master的日志  
password=Redhat-98k                                   \#\#mysql中root用户的密码  
user=root                                                         \#\#监控用户root  
ping\_interval=1                                                \#\#设置监控主库，发送ping包的时间间隔  
remote\_workdir=/tmp        \#\#设置远端mysql在发生切换时binlog的保存位置  
repl\_password=Redhat-98k       \#\#设置复制用户的密码  
repl\_user=admin                 \#\#设置复制环境中的复制用户名

ssh\_user=root                 \#\#设置ssh的登录用户名

candidate\_master=1      \#\#设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave

check\_repl\_delay=0        \#\#MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate\_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

3)masterha\_check\_ssh --conf=/etc/masterha/app1.conf 检查免密

![20180517202441269][]

![20180517203256670][]

这里报错，我们要做一个免密登陆，如图

![20180517203505138][]![20180517203515706][]

完成后，再次检查免密，显示ok

![20180517203602189][]

3）检测用户  
要满足两个条件：  
复制用户admin存在和允许管理员用户的远程登陆

server4管理端：masterha\_check\_repl --conf=/etc/masterha/app1.conf

![20180517203845878][]

4）测试出现故障是否能完成主从替换

第一种：自动切换

masterha\_manager --conf=/etc/masterha/app1.conf &打开服务到后台

![20180517204125253][]

查看状态，运行ok，此时master是server2

![20180517204214919][]

这是手动制造当前master server2故障

![20180517204312825][]

这里server4管理端要删除这个文件，否则默认8小时自动切换

![20180517204428869][]

删除后查看日志，可以看到sver2已经down掉，此时sevver3接管作master;

![2018051720451851][]

此时启动server2并指向复制server3，保证三台机器工作正常，在进行下一种测试

![20180517204752517][]

第二种模拟状态：手动切换：将正在运行的master转换为指定的master

![20180517204848932][]

输入yes后可以看到手动切换成功

![20180517204931249][]

此时在server3查看可知master端为server2

![20180517205153303][]

第三种模拟：手动切换故障机器

先将此时的master端server2故障

![2018051720534413][]

手动将故障的替换为自己新指定的master，这里指定新的master为server3

![20180517205541737][]

输入yes后查看日志：

![20180517205634333][]

在slave端 server5查看此时指向master为 server3

![20180517205719112][]

[20180516215519228]: /images/20220524/544dcf229af6480ebb0843b3ef45781e.png
[20180516215651919]: /images/20220524/8623da8d9ad04409bbc2c4943558efb0.png
[20180516220948583]: /images/20220524/6ccaba962b124419afaced4633ed6af7.png
[20180516221112965]: /images/20220524/aac20945034f4f9693020c31b0aecc2e.png
[20180516221154334]: /images/20220524/d2fb747e595b4ed7be8f168baf93ed92.png
[20180516222901950]: /images/20220524/c8577a40f5f448b2be80e0e818909814.png
[20180516223013573]: /images/20220524/98c7c23f386e4331b12fe7a4f7360e8b.png
[20180516223024686]: https://img-blog.csdn.net/20180516223024686
[20180516223032471]: https://img-blog.csdn.net/20180516223032471
[20180516223040946]: /images/20220524/6af252deffdd4ab4adcfaf06454ec659.png
[20180516224405893]: /images/20220524/891a412606eb4564ace0285a20eddbe0.png
[20180516224422935]: /images/20220524/461164c247a04248a5d92fe511f9469f.png
[20180516224747812]: /images/20220524/663b7648fcf24820ba42c9cf772322ac.png
[20180516224812302]: /images/20220524/d1cd6bf6dc6748ca93cacb31da5bd904.png
[20180516225606764]: /images/20220524/00b422302b1e4d81b5cbf236a30d937c.png
[20180516225752360]: /images/20220524/c4445443537d470ea51c2f31dd41639d.png
[20180516225824807]: /images/20220524/9869658f11f742709233fe97c8e4f98c.png
[20180516230006565]: /images/20220524/6235e21847414dcda5124f608acd9461.png
[2018051623025095]: /images/20220524/3e71b959f67149f199a5aeed877f9677.png
[20180516230339861]: /images/20220524/faad808f6f0f4197a981df67edf1140d.png
[20180516230616578]: https://img-blog.csdn.net/20180516230616578
[20180516230627118]: https://img-blog.csdn.net/20180516230627118
[20180516230634800]: /images/20220524/35ca6e1976384eca876c1fc104b00d77.png
[20180516230807823]: /images/20220524/6e1c8e1df4b249168811dddbb91bb961.png
[20180516230919425]: /images/20220524/7ea1e5ac995f4c53aed2b50066bad826.png
[20180516231004598]: /images/20220524/5a658ec7c6c14a62842fa00fd548474c.png
[20180516234408110]: https://img-blog.csdn.net/20180516234408110
[20180516234426535]: /images/20220524/056ce007b6ca4972aa29204b3edb5c3e.png
[20180517194153887]: /images/20220524/14347838afe34099820bdfa03b9739f9.png
[20180517194305494]: https://img-blog.csdn.net/20180517194305494
[20180517194317326]: /images/20220524/eaa851039c24456dacfb6d9c80574b8d.png
[20180517194350230]: /images/20220524/b941ee407d9649a0a55c7b68e62df4f5.png
[20180517194815105]: /images/20220524/fd33e7f94d1e458c9a949c979ca2f5ea.png
[20180517194913194]: /images/20220524/c65c42da0b0a4226a2810f9d8712b476.png
[20180517195023692]: /images/20220524/6be62b1064964294a7ad173407b5d1b5.png
[20180517195417548]: /images/20220524/ff95bd43953246ccbfec5570c1e805b8.png
[20180517195438928]: /images/20220524/cc3e09dd9ed24793a7ed39aaa7782f35.png
[20180517195527283]: /images/20220524/c2c7ad2644b247ee8a393288c28134d8.png
[20180517195627839]: /images/20220524/48b890c8b65e48198d82b5a247989161.png
[20180517200625118]: /images/20220524/682a418c9551473bae8673a827f1feae.png
[20180517200453113]: /images/20220524/e199bc09d50b4cef94fe64a7149ae4c9.png
[2018051720125164]: /images/20220524/2c4651968f524cd1a8f027700c95fc05.png
[20180517201408564]: /images/20220524/3328a54bcb5240dc94bf03529dd92933.png
[20180517201431799]: /images/20220524/a9b9ec51d2c94f439f6ee2859b95aa23.png
[20180517202036920]: /images/20220524/cee3115b78b84d5dabfdb00de4640c4f.png
[20180517202246207]: /images/20220524/448f63b35d604c9ebc47c82cbcba81d3.png
[20180517202518599]: /images/20220524/b1de5a7ce584472daa54d3e1b171ef95.png
[20180517202852717]: /images/20220524/7867c8a256ef43cfbdf9c7004a2a13e3.png
[20180517202441269]: /images/20220524/f7051e99c6874225a19731e880a3a8f3.png
[20180517203256670]: /images/20220524/98be082a72b64abeac48b91694cbff40.png
[20180517203505138]: https://img-blog.csdn.net/20180517203505138
[20180517203515706]: /images/20220524/e59b6ed833f444a982bff69b51df9093.png
[20180517203602189]: /images/20220524/5074633a5bd04007b9338e4b2c30a498.png
[20180517203845878]: /images/20220524/ac3ff8df93dd4dbaa4e8a925d7ffb589.png
[20180517204125253]: /images/20220524/e0e40938201d472999cbb8d96a77bc5d.png
[20180517204214919]: /images/20220524/884c108a1b3d41579f8f03020fb43111.png
[20180517204312825]: /images/20220524/04135eb631a04b7b9e589cef1e204190.png
[20180517204428869]: /images/20220524/06df932463c348bda5a6db57466fc40f.png
[2018051720451851]: /images/20220524/abecc1499e4343889425328ab8dd1551.png
[20180517204752517]: /images/20220524/26dde8728fea44b8a12bdd7cc87d85dc.png
[20180517204848932]: /images/20220524/f9b304fcdeaa4a1d8fc5ac02f0fd5ded.png
[20180517204931249]: /images/20220524/e99c1085a7d94e689c7b5384f4d8f44a.png
[20180517205153303]: /images/20220524/4b789a15772541d3b0e33b447993c7f9.png
[2018051720534413]: /images/20220524/5880ce0f3d40472d800df89b4cdaff54.png
[20180517205541737]: /images/20220524/ebf5c11ea849448f95e0fd47d2d5a191.png
[20180517205634333]: /images/20220524/ca45a71d49a047b99eec709375d13c8a.png
[20180517205719112]: /images/20220524/42b490ef3c914f07a2afa6e680886586.png