您现在的位置是: 网站首页 > 程序设计  > MySQL 

MySQL主从复制

2020年2月10日 08:00 1091人围观

简介主从复制过程存在三个线程,Master端的I/O线程,Slave的I/O线程与SQL线程。Master端需要开启binlog日志,Slave端需要开启relaylog。

1. MySQL主从复制

  • 原理:将主服务器的binlog日志复制到从服务器上执行一遍,达到主从数据的一致状态。
  • 过程:从库开启一个I/O线程,向主库请求Binlog日志。主节点开启一个binlog dump线程,检查自己的二进制日志,并发送给从节点;从库将接收到的数据保存到中继日志(Relay log)中,另外开启一个SQL线程,把Relay中的操作在自身机器上执行一遍
  • 优点
    • 作为备用数据库,并且不影响业务
    • 可做读写分离,一般是一个写库,一个或多个读库,分布在不同的服务器上,充分发挥服务器和数据库的性能,但要保证数据的一致性

2. 主从复制的日志格式

  二进制日志Binlog的格式主要有三种:基于语句statement的复制、基于行row的复制、基于语句和行(mix)的复制。

  1. Statement:基于SQL语句级别的Binlog,每条修改数据的SQL都会保存到Binlog里面。
  2. ROW:基于行级别,每一行数据的变化都会记录到Binlog里面,但是并不记住原始SQL语句,因此它会记录的非常详细,日志量也比statement格式记录的多得多。在主从复制中,这样的Binlog格式不会因存储过程或触发器原因造成主从数据不一致的问题。
  3. Mixed:混合Statement和Row模式。

在mysql5.7中,默认是ROW模式记录

mysql> show variables like 'binlog_format%'; 
+---------------+-------+ 
| Variable_name | Value | 
+---------------+-------+ 
| binlog_format | ROW   | 
+---------------+-------+ 
1 row in set (0.00 sec) 

上面的三种复制模式也对应了MySQL的三种复制技术:

binlog_format=Statement:基于SQL语句的复制,在MySQL5.1.4之前的版本都是基于SQL语句的复制

binlog_format=ROW:基于行的复制

binlog_Mixed:混合复制模式,基于行的复制和基于SQL语句的复制。

总结:在MySQL的主从复制中,主库的Binlog_format设置为ROW格式比Statement格式更能保证从库数据的一致性,只是ROW格式下的Binlog日志可能会增大非常多,在设置时需要考虑磁盘空间问题。

3. 复制架构

3.1、一主多从架构

  在主库的请求压力非常大时,可通过配置一主多从复制架构实现读写分离,把大量对实时性要求不是很高的请求通过负载均衡分发到多个从库上去读取数据,降低主库的读取压力。而且在主库出现宕机时,可将一个从库切换为主库继续提供服务

3.2、多级复制架构

  因为每个从库在主库上都会有一个独立的Binlog Dump线程来推送binlog日志,所以随着从库数量的增加,主库的IO压力和网络压力也会随之增加,这时,多级复制架构应运而生。

  多级复制架构只是在一主多从的基础上,再主库和各个从库之间增加了一个二级主库Master2,这个二级主库仅仅用来将一级主库推送给它的BInlog日志再推送给各个从库,以此来减轻一级主库的推送压力。

  但它的缺点就是Binlog日志要经过两次复制才能到达从库,增加了复制的延时。 我们可以通过在二级从库上应用Blackhol存储引擎(黑洞引擎)来解决这一问题,降低多级复制的延时。“黑洞引擎”就是写入Blackhole表中数据并不会写到磁盘上,所以这个Blackhole表永远是个空表,对数据的插入/更新/删除操作仅在Binlog中记录,并复制到从库中去。

3.3、双主复制/Dual Master架构

双主复制架构适用于需要进行主从切换的场景

  在只有一个主库的架构下,当主库宕机后,将其中一个从库切换为主库继续提供服务。原来的主库就没有数据来源了,那么当这个新的主库接收到新的数据时,原来的主库却没有同步,因此他们的数据差异越来越大,那么原来的主库就无法成为主从复制环境中的一员了。当原来的主库恢复正常后,需要重新将其添加进复制环境中去。

  那为了避免重复添加主库的问题,双主复制应运而生。两个数据库互为主从,当主库宕机恢复后,由于它还是原来从库(现在主库)的从机,所以它还是会复制新的主库上的数据。那么无论主库的角色怎么切换,原来的主库都不会脱离复制环境。

4. 复制方式

MySQL的主从复制有两种复制方式,分别是异步复制和半同步复制

  • 异步复制
  • 逻辑上
    MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理,这样就会有一个问题,主如果crash掉了,此时主上已经提交的事务可能并没有传到从库上,如果此时,强行将从提升为主,可能导致新主上的数据不完整。

  • 技术上
    主库将事务 Binlog 事件写入到 Binlog 文件中,此时主库只会通知一下 Dump 线程发送这些新的 Binlog,然后主库就会继续处理提交操作,而此时不会保证这些 Binlog 传到任何一个从库节点上。

  • 全同步复制

  • 逻辑上
    指当主库执行完一个事务,所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回,所以全同步复制的性能必然会收到严重的影响。

  • 技术上
    当主库提交事务之后,所有的从库节点必须收到、APPLY并且提交这些事务,然后主库线程才能继续做后续操作。但缺点是,主库完成一个事务的时间会被拉长,性能降低。

  • 半同步复制

  • 逻辑上
    是介于全同步复制与全异步复制之间的一种,主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可,主库不需要等待所有从库给主库反馈。同时,这里只是一个收到的反馈,而不是已经完全完成并且提交的反馈,如此,节省了很多时间。

  • 技术上
    介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,半同步复制最好在低延时的网络中使用。

上一篇: MySQL索引面试题

下一篇: MySQL四种隔离级别