MySQL学习之主从复制原理

MySQL复制概述

简单来说就是保证主服务器（Master）和从服务器（Slave）的数据是一致性的，向Master插入数据后，Slave会自动从Master把修改的数据同步过来（有一定的延迟），通过这种方式来保证数据的一致性，就是MySQL复制

在实际的生产中，为了解决Mysql的单点故障问题，为提高MySQL的整体服务性能，一般都会采用「主从复制」。

比如：在复杂的业务系统中，有一句sql执行后导致锁表，并且这条sql的的执行时间比较长，那么此sql执行的期间导致服务不可用，这样就会严重影响用户的体验度。

主从复制中分为「主服务器（master）「和」从服务器（slave）」，「主服务器负责写，而从服务器负责读」，Mysql的主从复制的过程是一个「异步的过程」。

这样读写分离的过程能够使整体的服务性能提高，即使写操作时间比较长，也不影响读操作的进行。

复制如何工作

复制有三个步骤：

1. Master将数据改变记录到二进制日志(binary log)中，也就是配置文件log-bin指定的文件，这些记录叫做二进制日志事件(binary log events)
2. Slave通过I/O线程读取Master中的binary log events并写入到它的中继日志(relay log)
3. Slave重做中继日志中的事件，把中继日志中的事件信息一条一条的在本地执行一次，完成数据在本地的存储，从而实现将改变反映到它自己的数据(数据重放)
   

第一步Master记录二进制日志， 每次提交事务完成数据更新前，Master将数据更新的时间记录到二进制日志中，MySql会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。再记录二进制日志后，主库会告诉存储引擎可以提交事务了。

第二步，Slave将Master的二进制日志复制到本地的中继日志中，首先，Slave会启动一个工作线程，称为I/O线程， I/O线程跟Master建立一个普通的客户端链接，然后再Master上启动一个特殊的二进制转储（binlog dump）线程（该线程没有对应的SQL命令），这个二进制转储线程会读取主库上的二进制日志中的事件。从库I/O线程将接受到事件记录到中继日志中。

第三步从库的SQL线程执行最后异步，该线程的从中继日志中读取事件并在从库执行，从而实现从库数据更新。

这种复制架构实现了获取事件和重放事件的解偶，允许这两个过程异步进行。也就是说I/O线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要的一点是主库上并发运行的查询在从库只能串行化执行，因为只有一个SQL线程重放中继日志中的事件。这是很多工作负载的性能瓶颈所在。因为始终受限于单线程。

在进行主从复制的时候，需要注意以下几个关键的时刻

1、主库A执行完成一个事务，写入binlog，我们把这个时刻记为T1;

2、之后传给备库B,我们把备库B接受完这个binlog的时刻记为T2;

3、备库B执行完成这个事务，我们把这个时刻记为T3;

所谓的主备延迟就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。SBM在进行计算的时候也是按照这样的方式，每个事务的binlog中都有一个时间字段，用于记录主库写入的时间，备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到SBM。

如果刚刚的流程听明白了，那么下面我们就要开始分析产生这个时间差值的原因有哪些了，以方便我们更好解决生产环境中存在的问题。

MySQL的主从复制延迟问题

实例规格过小

在某些部署环境中，备库所在的机器性能要比主库所在的机器性能差。此时如果机器的资源不足的话就会影响备库同步的效率；

DDL 操作

备库充当了读库，一般情况下主要写的压力在于主库，那么备库会提供一部分读的压力，而如果备库的查询压力过大的话，备库的查询消耗了大量的CPU资源，那么必不可少的就会影响同步的速度

大事务

大事务：特指对数据进行增删改的 insert，update，delete，replace 这一类语句。在一个事务中包含对数百万行数据的操作；或者是一个 SQL 语句修改百万行数据，导致执行时间超过30s。当主实例执行大数据量的 DML 操作，大量的 binlog 日志传送到从库时，从库需要花费与主实例相同的时间来完成相应事务，进而导致从库出现数据延迟。

随机写

主库的写操作是顺序写binlog，从库单线程去主库顺序读binlog，从库取到binlog之后在本地执行。mysql的主从复制都是单线程的操作，但是由于主库是顺序写，所以效率很高，而从库也是顺序读取主库的日志，此时的效率也是比较高的，但是当数据拉取回来之后变成了随机的操作，而不是顺序的，所以此时成本会提高。

Waiting for table metadata lock 报错

从库在同步数据的同时，可能跟其他查询的线程发生锁抢占的情况，此时也会发生延时。

TPS并发非常高

当主库的TPS并发非常高的时候，产生的DDL数量超过了一个线程所能承受的范围的时候，那么也可能带来延迟

网络带宽

在进行binlog日志传输的时候，如果网络带宽也不是很好，那么网络延迟也可能造成数据同步延迟，这些就是可能会造成备库延迟的原因

如何解决复制延迟的问题

架构方面

①、业务的持久化层的实现采用分库架构，让不同的业务请求分散到不同的数据库服务上，分散单台机器的压力

②、服务的基础架构在业务和mysql之间加入缓存层，减少mysql的读的压力，但是需要注意的是，如果数据经常要发生修改，那么这种设计是不合理的，因为需要频繁地去更新缓存中的数据，保持数据的一致性，导致缓存的命中率很低，所以此时就要慎用缓存了

③、使用更好的硬件设备，比如cpu，ssd等，但是这种方案一般对于公司而言不太能接受，原因也很简单，会增加公司的成本，而一般公司其实都很抠门，所以意义也不大，但是你要知道这也是解决问题的一个方法，只不过你需要评估的是投入产出比而已。

从库配置方面

1、修改sync_binlog的参数的值

想要合理设置此参数的值必须要清楚地知道binlog的写盘的流程，每个线程有自己的binlog cache，但是共用同一份binlog。write指的就是把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度快fsync才是将数据持久化到磁盘的操作。一般情况下，我们认为fsync才占用磁盘的IOPS

而write和fsync的时机就是由参数sync_binlog来进行控制的。

1、当sync_binlog=0的时候，表示每次提交事务都只write，不fsync

2、当sync_binlog=1的时候，表示每次提交事务都执行fsync

3、当sync_binlog=N的时候，表示每次提交事务都write，但积累N个事务后才fsync。

一般在公司的大部分应用场景中，我们建议将此参数的值设置为1，因为这样的话能够保证数据的安全性，但是如果出现主从复制的延迟问题，可以考虑将此值设置为100~1000中的某个数值，非常不建议设置为0，因为设置为0的时候没有办法控制丢失日志的数据量，但是如果是对安全性要求比较高的业务系统，这个参数产生的意义就不是那么大了。

2、直接禁用salve上的binlog，当从库的数据在做同步的时候，有可能从库的binlog也会进行记录，此时的话肯定也会消耗io的资源，因此可以考虑将其关闭，但是需要注意，如果你搭建的集群是级联的模式的话，那么此时的binlog也会发送到另外一台从库里方便进行数据同步，此时的话，这个配置项也不会起到太大的作用。

3、设置innodb_flush_log_at_trx_commit 属性，这个属性在我讲日志的时候讲过，用来表示每一次的事务提交是否需要把日志都写入磁盘，这是很浪费时间的，一共有三个属性值，分别是0（每次写到服务缓存，一秒钟刷写一次），1（每次事务提交都刷写一次磁盘），2（每次写到os缓存，一秒钟刷写一次），一般情况下我们推荐设置成2，这样就算mysql的服务宕机了，卸载os缓存中的数据也会进行持久化。

参考

https://blog.csdn.net/m0_73311735/article/details/127935751