一、概述

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个，减少单次事务的大小

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

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

巨人的肩膀：

MySQL主从复制原理_牛奔的博客-CSDN博客

一文搞懂MYSQL主从复制原理_蜀山客e的博客-CSDN博客