MySQL(13)---MYSQL主从复制原理

MYSQL主从复制原理

最近在做项目的时候,因为部署了 MYSQL主从复制 所以在这里记录下整个过程。这里一共会分两篇博客来写:

1、Mysql主从复制原理
2、docker部署Mysql主从复制实战

这篇只写MYSQL主从复制原理。

一、概述

1、什么是主从复制?

概念 主从复制是用来建立一个和 主数据库完全一样的数据库环境称为从数据库;主数据库一般是准实时的业务数据库。

2、主从复制作用

我们来思考如果在企业网站中,后端MYSQL数据库只有一台时候,会有以下问题

1、单点故障服务不可用
2、无法处理大量的并发数据请求
3、数据丢失

所以通过主从复制后,它的优点就很明显

1、如果主节点出现故障,那么我们就直接将服务切到从节点,来保证服务立马可用。
2、如果并发请求特别大的时候,我们可用进行读写分离操作,让主库负责写,从库负责读。
3、如果主库数据丢失,但从库还保存一份,减少数据丢失的风险。

二、主从复制原理

1、主从复制原理

这里先放一张图,这张图很好的诠释的主从复制的原理

上面主要分成了三步,下面会详细说明。

(1) Master的更新事件(update、insert、delete)会按照顺序写入bin-log中。当Slave连接到Master的后,Master机器会为Slave开启

binlog dump线程,该线程会去读取bin-log日志

(2) Slave连接到Master后,Slave库有一个I/O线程 通过请求binlog dump thread读取bin-log日志,然后写入从库的relay log日志中。

(3) Slave还有一个 SQL线程,实时监控 relay-log日志内容是否有更新,解析文件中的SQL语句,在Slave数据库中去执行。

总结

(1) 既然是要把事件记录到bin-log日志,那么对于Master就必须开启bin-log功能

(2) 整个Mysql主从复制一共开启了3个线程。Master开启 IO线程,Slave开启 IO线程 和 SQL线程

(3) 这点也很重要那就是Master和Slave交互的时候,记住这里是Slave去请求Master,而不是Master主动推给Slave。Slave通过IO线程

连接Master后发起请求,Master服务器收到Slave IO线程发来的日志请求信息,io线程去将bin-log内容返回给slave IO线程。

2、MySQL主从复制同步方式

(1)异步复制

MySQL主从同步 默认是异步复制的。就是上面三步中,只有第一步是同步的(也就是Mater写入bin log日志),就是主库写入binlog日志后即可成功返回客户端,无须等待binlog

日志传递给从库的过程。Master 不关心 Slave 的数据有没有写入成功。因此如果Master和Slave之间有网络延迟,就会造成暂时的数据不一致的现象;如果Master出故障,而数据

还没有复制过去,则会造成数据丢失;但也有好处,效率较其他两种复制方式最高。

(2)同步复制

对于同步复制而言,Master主机将事件发送给Slave主机后会触发一个等待,直到所有Slave节点(如果有多个Slave)返回数据复制成功的信息给Master。这种复制方式最安

全,但是同时,效率也是最差的。

(3)半同步复制

对于半同步复制而言,Master主机将事件发送给Slave主机后会触发一个等待,直到其中一个Slave节点(如果有多个Slave)返回数据复制成功的信息给Master。由此增强了

数据的一致性,但是因为Master主机的确认开销,会损耗一部分的性能;另外,半同步复制除了不需要等待所有Slave主机确认事件的接收外,半同步数据复制并不要求那些事件

完全地执行,因此,仍有可能看到在Slave主机上数据复制延迟的发生,如果因为网络延迟等原因造成Slave迟迟没有返回复制成功的信息,超过了Master设置的超时时长,半同步

复制就降级为异步复制方式,而后继续数据复制。


三、Mysql主从同步延时

上面也说了,Mysql默认采用的异步操作,因为它的效率明显是最高的。因为只要写入bin log后事物就结束返回成功了。但由于从库从主库异步拷贝日志 以及

串行执行 SQL 的特点,所以从库的数据一定会比主库慢一些,是有延时的。所以经常出现,刚写入主库的数据可能是读不到的,要过几十毫秒,甚至几百毫秒才能

读取到。这就是主从同步延时问题。

1、如何查看主从延迟时间

通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断:

mysql> show slave status\G;
    // 状态一
    Seconds_Behind_Master: NULL
    // 状态二
    Seconds_Behind_Master: 0
    // 状态三
    Seconds_Behind_Master: 79

Seconds_Behind_Master=0: 表示主从复制良好;

Seconds_Behind_Master=NULL: 表示io_thread或是sql_thread有任何一个发生故障;

Seconds_Behind_Master=79: 数字越大表示从库延迟越严重。

2、影响延迟因素

这里整理了影响主从复制延迟大致有以下几个原因:

1)主节点如果执行一个很大的事务,那么就会对主从延迟产生较大的影响

2)网络延迟,日志较大,slave数量过多

3)主上多线程写入,从节点只有单线程同步

4)机器性能问题,从节点是否使用了“烂机器”

5)锁冲突问题也可能导致从机的SQL线程执行慢

3、优化主从复制延迟

这个没有说去完全解决,要想解决那么就只能采用同步复制策略。不过,一般不建议使用这种同步模式。显而易见,如果写操作必须等待更新同步完成,肯定会

极大地影响性能,除非你不在乎性能。

1)大事务:将大事务分为小事务,分批更新数据

2)减少Slave的数量,不要超过5个,减少单次事务的大小

3)MySQL 5.7之后,可以使用多线程复制,使用MGR复制架构

4)在磁盘、raid卡、调度策略有问题的情况下可能会出现单个IO延迟很高的情况,可用iostat命令查看DB数据盘的IO情况,再进一步判断

5)针对锁问题可以通过抓去processlist以及查看information_schema下面和锁以及事务相关的表来查看

总结

主机与从机之间的物理延迟是无法避免的,既然无法避免就可以考虑尝试通过缓存等方式,降低新修改数据被立即读取的概率。


参考

1、Mysql主从延时

2、你知道MySQL主从复制的原理吗

3、MySQL主从同步机制和同步延时问题追查


别人骂我胖,我会生气,因为我心里承认了我胖。别人说我矮,我就会觉得好笑,因为我心里知道我不可能矮。这就是我们为什么会对别人的攻击生气。
攻我盾者,乃我内心之矛(32)
posted on 2020-12-04 02:00  雨点的名字  阅读(1019)  评论(1编辑  收藏  举报