原理:将主服务器的binlog日志复制到从服务器上执行一遍,达到主从数据的一致状态。python
过程:从库开启一个I/O线程,向主库请求Binlog日志。主节点开启一个binlog dump线程,检查本身的二进制日志,并发送给从节点;从库将接收到的数据保存到中继日志(Relay log)中,另外开启一个SQL线程,把Relay中的操做在自身机器上执行一遍数据库
优势:安全
这里的日志格式就是指二进制日志的三种格式:基于语句statement的复制、基于行row的复制、基于语句和行(mix)的复制。其中基于row的复制方式更能保证主从库数据的一致性,但日志量较大,在设置时考虑磁盘的空间问题服务器
show variables like ‘%binlog%format%’; #查看当前使用的binlog的格式 set binlog_format = ‘row’; #设置格式,这种方法只在当前session生效 set global binlog_format = ‘row’; #在全局下设置binlog格式,会影响全部的Session
在主库的请求压力很是大时,可经过配置一主多从复制架构实现读写分离,把大量对实时性要求不是很高的请求经过负载均衡分发到多个从库上去读取数据,下降主库的读取压力。并且在主库出现宕机时,可将一个从库切换为主库继续提供服务网络
由于每一个从库在主库上都会有一个独立的Binlog Dump线程来推送binlog日志,因此随着从库数量的增长,主库的IO压力和网络压力也会随之增长,这时,多级复制架构应运而生。session
多级复制架构只是在一主多从的基础上,再主库和各个从库之间增长了一个二级主库Master2,这个二级主库仅仅用来将一级主库推送给它的BInlog日志再推送给各个从库,以此来减轻一级主库的推送压力。架构
但它的缺点就是Binlog日志要通过两次复制才能到达从库,增长了复制的延时。并发
咱们能够经过在二级从库上应用Blackhol存储引擎(黑洞引擎)来解决这一问题,下降多级复制的延时。负载均衡
“黑洞引擎”就是写入Blackhole表中数据并不会写到磁盘上,因此这个Blackhole表永远是个空表,对数据的插入/更新/删除操做仅在Binlog中记录,并复制到从库中去。异步
双主复制架构适用于须要进行主从切换的场景
在只有一个主库的架构下,当主库宕机后,将其中一个从库切换为主库继续提供服务。原来的主库就没有数据来源了,那么当这个新的主库接收到新的数据时,原来的主库却没有同步,所以他们的数据差别愈来愈大,那么原来的主库就没法成为主从复制环境中的一员了。当原来的主库恢复正常后,须要从新将其添加进复制环境中去。
那为了不重复添加主库的问题,双主复制应运而生。两个数据库互为主从,当主库宕机恢复后,因为它仍是原来从库(如今主库)的从机,因此它仍是会复制新的主库上的数据。那么不管主库的角色怎么切换,原来的主库都不会脱离复制环境。
MySQL的主从复制有两种复制方式,分别是异步复制和半同步复制
一、逻辑上
MySQL默认的复制便是异步的,主库在执行完客户端提交的事务后会当即将结果返给给客户端,并不关心从库是否已经接收并处理,这样就会有一个问题,主若是crash掉了,此时主上已经提交的事务可能并无传到从库上,若是此时,强行将从提高为主,可能致使新主上的数据不完整。
二、技术上
主库将事务 Binlog 事件写入到 Binlog 文件中,此时主库只会通知一下 Dump 线程发送这些新的 Binlog,而后主库就会继续处理提交操做,而此时不会保证这些 Binlog 传到任何一个从库节点上。
一、逻辑上
指当主库执行完一个事务,全部的从库都执行了该事务才返回给客户端。由于须要等待全部从库执行完该事务才能返回,因此全同步复制的性能必然会收到严重的影响。
二、技术上
当主库提交事务以后,全部的从库节点必须收到、APPLY而且提交这些事务,而后主库线程才能继续作后续操做。但缺点是,主库完成一个事务的时间会被拉长,性能下降。
一、逻辑上
是介于全同步复制与全异步复制之间的一种,主库只须要等待至少一个从库节点收到而且 Flush Binlog 到 Relay Log 文件便可,主库不须要等待全部从库给主库反馈。同时,这里只是一个收到的反馈,而不是已经彻底完成而且提交的反馈,如此,节省了不少时间。
二、技术上
介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是马上返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制,半同步复制提升了数据的安全性,同时它也形成了必定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。因此,半同步复制最好在低延时的网络中使用。