MYSQL的主从复制及延迟原因

1.为什么需要主从复制？

业务量越来越大，I/O访问频率过高，单机已经无法满足，此时要做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

再看看你的业务需求，是否进行读写分离；如果采取读写分离，那么主库写入的数据要在其他从库查询的时候要能查得到。在用户看来，无论你后台有多少台数据库服务器，对于用户而言就像一台一样。所以我们就需要考虑一个很重要的问题：多库中的数据的一致性问题。这就引出了我们的主从复制

2.什么是主从复制？

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

---

3.MYSQL内部实现持久化机制的时候采用什么方式？

答案是日志的方式，那么有几种形式的日志呢？

其中bin log就是用来进行主从复制的操作

---

4.主从复制的原理

上面就是主从复制的原理图，接下来我们来讲解一下实现流程
​ 1. master服务器将数据的改变记录二进制binlog日志，当master上的数据发生改变时，则将其改变写入二进制日志中；

​ 2. slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件

​ 3.同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。

简要概括：

• 从库会生成两个线程,一个I/O线程,一个SQL线程
• I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中
• 主库会生成一个log dump线程,用来给从库I/O线程传binlog
• SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行

---

5.主从复制延迟原因

由上面的原理实现来看，我们要考虑一下到底哪里会出现延迟问题？这时候我们要了解一下什么是顺序读写和随机读写。

顺序读写：文件指针只能从头移动到尾。
随机读写：文件指针可以随意移动，根据需要。

一般来说，顺序读是比随机读快的，因为指针随意移动是比较浪费时间的。

我们继续来讲解延迟问题

我把上面的实现流程分为了4个步骤，第一个步骤是master服务器将数据的改变记录二进制binlog日志；第二个步骤是从库建立I/O线程来读取主库的bin log；第三个步骤是把从主库读取过来的日志存放到本地的relay log；第四个步骤是SQL线程读取relay log文件中的日志,并解析成sql语句逐一执行。

我们继续分析，第一个步骤生成bin log日志是append操作，属于顺序读写的过程，所以不是主要产生延迟问题的原因；第二个步骤也是顺序读写的，也不是主要原因。但是有人就会问，如果主机和从机不在同一个局域网内，它们之间的网络延迟不也会造成影响吗？有一句话说的好，“不给马儿吃草又让马儿跑”。对于那些跨异地机房，一般不会用公共的传送道，而是用自己的公司独特的传送道，所以第二个步骤也不是要考虑的对象；第三个步骤想当然的也是顺序读写的过程，所以也不是考虑的对象；那么只剩下第四个步骤会产生延迟了，第四个步骤是先把日志读取此时还是顺序读过程，因为是同一个文件读取，之后在本地relay，此时就是随机写的过程了，为什么呢？

假设replay日志中写入两条语句，id为1和id为200，当我们执行这两条SQL语句的时候，想象一下两个id的行数据不在同一个磁盘块，那么此时执行是很耗费时间的，这里的随机写不是指SQL的执行顺序，而是执行语句要找到对应的数据的过程。

总结：当前3个步骤执行速度很快，第四个步骤速度很慢，此时就会造成replay日志堆积，下图的生成者消费者问题形象的说明延迟所造成的后果，虽然最终结果还是一样的，但是造成的延迟问题不是能被忽略的