文章目录
- 前言
- 主备原理
- binlog的三种格式
- 循环复制问题
- 主备的搭建
- 总结
前言
mysql在日常中的使用是比较多的,大部分可能也都搭建过主从复制,或者集群模式。但是其中的原理不知道大家是否清楚。今天我们主要介绍的就是mysql主从复制的原理。
主备原理
主备复制的实现主要考的是binlog,通过主数据库binlog同步到副数据库,来实现主备之间的数据同步。如下图
第一张图是主备的一个模式,第二个图是实现数据同步的原理。
我们可以看出,在同步的过程中备库开启了两个线程,一个是iothread,这个线程是去主库进行数据复制(也就是同步binlog),另一个线程就是执行binlog,将数据插入到磁盘。
binlog的三种格式
binlog有三种格式,如下
1.statement
2.row
3.mixed
这三种格式各有各的特点
1.statement格式:binlog中保存的是你的原生sql。
mysql> delete from t /*comment*/ where a>=4 and t_modified<='2018-11-10' limit 1;
但是原生sql会有一个问题,就是如果是带有limit的sql,可能a和b的数据会出现不一致的情况。
如上面的sql,你如果走的不同的索引,可能对应的数据是不一样的,如果你a库走的是a索引,b库走的是t_modified索引。那么删除的数据是不一样的,这样a和b两个库的数据,就会出现不一致的情况。
2.row格式:这个格式中,binlog直接存储的是那一行的数据,这样就可以通过id去删除或者修改,肯定不会出现操作数据不一致的情况,也就不会出现a和b数据不一致的情况。
3.mixed格式:看这个名字大家就知道,这个就是上面两种格式的混合。
循环复制问题
假如有三个数据库a,b,c,a为主库,b也为主库,c为b和a的备库,b又为a的备库。这个时候就会出现一个问题,就是a执行一个数据操作,产生一条日志。然后将日志同步到b,这个时候b执行完,又会产生一条日志,同步到a。这样就是一直循环下去。
怎么解决循环日志呢,通过一个serverid,即可实现,然后要把a和b的serverid设置的不一样,且执行不是自己serverid的操作,不会产生自己serverid的日志。这样就能避免循环日志的问题。
主备的搭建
主备模式的搭建方式有很多,这里给大家简单介绍一种。大家可使用开源工具mycat,来实现主备模式,不管是一对一还是一堆多,都可以通过简单的配置进行实现。
总结
通过上面的介绍,大家可以发现,主备的实现,主要还是依赖binlog日志的归档能力。所以想要很好的理解主备的实现原理,必须要理解binlog日志。