MySQL主从复制原理

news2024/12/26 11:29:27

一、概述

1、什么是主从复制

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

2、主从复制的作用

高可用，实时灾备，用于故障切换。比如主库挂了，可以切从库。
读写分离，提供查询服务，减少主库压力，提升性能
备份数据，避免影响业务。

二、主从复制原理

1、主从复制原理

一、概述

1、什么是主从复制

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

2、主从复制的作用

高可用，实时灾备，用于故障切换。比如主库挂了，可以切从库。
读写分离，提供查询服务，减少主库压力，提升性能
备份数据，避免影响业务。

二、主从复制原理

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数据库中去执行。

2、主主、主从、主备的区别

（1）数据库主主：两台都是主数据库，同时对外提供读写操作。客户端访问任意一台。数据存在双向同步。

（2）库主从：一台是主数据库，同时对外提供读写操作。一台是从数据库，对外提供读的操作。数据从主库同步到从库。

从库和备库，就是slave库功能不同因此叫法不一样而已。一般slave库都会对外提供读的功能的，因此，大家日常听得最多的就是主从。

3、MySQL是怎样保证主从一致的

（1）binlog格式
binlog 日志有三种格式，分别是 statement，row 和 mixed。

如果是 statement 格式，binlog 记录的是 SQL的原文，如果主库和从库选的索引不一致，可能会导致主库不一致。我们来分析一下。假设主库执行删除这个SQL(其中，a 和 create_time 都会有索引)如下：

delete from t where a > '666' and create_time < '2022-03-02' limit 1;

我们知道，数据库选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条SQL时，使用的是索引a，而从库在执行这条SQL时，使用了索引 create_time。最后主从数据不一致了。

如何解决这个问题呢？

可以把binlog格式修改为 row。row 格式的 binlog 日志，记录的不是 SQL原文，而是两个 event: Table_map 和 Delete_rows。Table_map event 说明要操作的表，Delete_rows event 用于定义要删除的行为，记录删除的具体行数。row 格式的binlog记录的就是要删除的主键ID信息，因此不会出现主从不一致的问题。

但是如果SQL删除10万行数据，使用row格式就会很占空间的，10万条数据都在 binlog 里面，写 binlog 的时候也很耗IO。但是 statement 格式的binlog可能会导致数据不一致，因此设计MySQL的大叔想了一个折中的方案，mixed 格式的 binlog。所谓的 mixed格式其实就是 row 和 statement 格式混合使用，当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用 statement 格式。

4、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主从同步延时

1、主从同步延时问题

Mysql默认采用的异步操作，因为它的效率明显是最高的。因为只要写入bin log后事务就结束返回成功了。但由于从库从主库异步拷贝日志以及串行执行 SQL 的特点，所以从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。这就是主从同步延时问题。

2、影响延迟因素

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

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

2）网络延迟，日志较大，slave数量过多

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

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

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

3、优化主从复制延迟

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

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

1）大事务：将大事务分为小事务，分批更新数据

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