文章目录
- 前言
- 同步原理
- 复制的核心流程
- 写在最后
前言
随着社会的进步大家对服务端应用程序的性能指标有着越来越高的要求,比如响应时间、吞吐率、QPS、TPS等等。基本上大多数系统都会要求响应时间不超过3s,当然对吞吐量和并发量也会根据具体的业务场景进行要求。所以在实际的开发过程中我们不得不优化系统的各种组件,比如数据库端就是一个很大的方向。
数据库的优化不仅仅是对数据结构、索引、SQL语句、执行引擎选择进行合理安排,更多的是在数据量大的时候采用集群的方式进行分摊压力提升性能,比如我们Mysql主从集群的读写分离、分库分表。
既然说到了Mysql主从集群是一般项目中采用的方案,那我们今天就来剖析一下这些Mysql主从节点是如何完成数据同步的呢?
同步原理
说到主从同步的原理,我们就需要了解在数据库中的一个重要日志文件,就是binlog二进制文件,它记录了对数据库进行更新的事件,事实上主从同步的原理就是基于binlog进行数据同步的,说直白点就是从库按照一定的规则重新执行一次主库的binlog。
在主从复制的过程中,会基于三个线程来操作:
一个是binlog dump线程,位于master节点上,当从库执行change master命令连接到master创建,主要是监听master写binlog事件,发现binlog有变动就通知slave的IO线程,并传入具体的同步位置灯信息。
另外两个线程分别是I/O线程和SQL线程,它们都分别位于slave节点上,是从库执行start slave创建的。 IO线程是接收主库binlog dump线程推送的位置等信息,并作为参数到主库执行语句拷贝到本机器的relay log中。而SQL线程则是将slave relay log中的执行语句写入从库。
复制的核心流程
下面我们一起来了解主从复制的核心流程:
1、首先slave执行change master命令,带入master ip地址、端口、binlog日志名称和位置等信息连接到master,此时master开启一个监听binglog 变化的dump线程;
2、slave继续执行 start slave命令开始同步,此时slave创建一个IO线程、一个SQL线程来满足同步;
3、当master节点接收到一个写请求时,这个写请求可能是增删改操作,此时会把写请求的更新操作都记录到binlog日志中;
4、 binlog dump线程会监听到master binlog日志变化,然后将binlog包含位置等信息的变化事件发送给slave节点上的I/O线程;当主库读取事件的时候,会在Binglog上加锁,读取完成之后,再将锁释放掉;
5、slave节点上的I/O线程接收到同步事件后,会将binlog 同步位置等参数带入到master拉日志并将binlog日志先写入到本地的relaylog中,relaylog中就保存了binlog日志;
6、slave节点上的SQL线程,会读取relaylog中的binlog日志,将其解析成具体的增删改操作,把这些在master节点上进行过的操作,重新在slave节点上也执行一次。
写在最后
Mysql主从同步的原理就是基于binlog进行数据同步的,说直白点就是从库按照一定的规则重新执行主库的binlog。当然在实际的开发中只要我们按照官方命令搭建好了主从集群,基本上就没有太大的问题。