MySQL的复制演进之路(起始篇)
Posted 一起来了解数据库啊
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL的复制演进之路(起始篇)相关的知识,希望对你有一定的参考价值。
MySQL复制含有以下优点:
当主库出现问题时,可以快速切换,从库提升为主库继续提供服务。
可以实现读写分离,降低主库的访问压力。
在从库上执行备份,避免对主库造成影响。
可以实现在线升级,先升级备库,再升级主库。
目前MySQL支持两种数据同步方法,传统复制和基于GTID的复制。
传统复制:基于二进制日志文件和位置进行复制,在进行主从配置复制时,需要指定从主库获取的二进制文件(binlog file) 和位置点(binlog position)。
基于GTID的复制:GTID,全称Global Transaction ID,从MySQL5.6及以后开始支持,利用GTID可以自动在主库中寻找需要复制的二进制日志记录,不需要关心日志文件或位置,简化了复制的配置。
MySQL通过三个线程完成主从复制,即Binlog Dump线程,I/O线程,SQL线程,其中Binlog Dump在主库上,I/O线程和SQL线程在从库上,当进行主从复制时,MySQL主库在事务提交时将数据变更作为事件Events记录到binlog二进制日志中,然后主库创建Binlog Dump线程读取事件发送给I/O线程,I/O线程获取到事件数据后更新到从库的中继日志Relay Log中,然后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件进行回放,如果开启了并行复制,则SQL线程转变成coordinator(协调者),进行数据复制,从而实现数据一致。
流程如下:
MySQL支持以下几种不同类型的数据同步:
异步复制:最早的复制技术,MySQL内置支持,不需要安装插件,MySQL主库执行完更新操作后立即commit,然后向slave同步数据,性能最高,但是数据不是实时同步到从库,当主库在从库有延迟时发生故障时可能会导致主从数据不一致。
半同步复制(after commit):主库执行完更新操作后立即向从库复制数据,至少一个从库接收到数据后写入到Relay Log中,此时从库向主库返回ACK确认信息,然后才会进行commit,但是早期的半同步复制中,主库在等待ACK的InnoDB存储引擎内部已经进行commit操作,只是阻塞了返回给发起事务提交的客户端消息而已,如果有其他会话对该事务修改的数据进行查询,会查询到最新数据,当主库发生故障时,可能会发生幻读。
增强半同步复制(after sync):主库执行完更新操作后立即向从库复制数据,至少一个从库接收到数据后写入到Relay Log中,此时从库向主库返回ACK确认信息,然后才会进行commit。这是对半同步复制漏洞的修复。
延迟复制:可以通过设置使得从库故意滞后于主库一段指定的时间,以便出现误操作时能进行补救。
强同步复制:保证写操作完全同步到其他数据节点,主库在执行完更新操作后立即向从库复制数据,从库接收到数据并执行完后才向主库放回ACK信息,然后主库才进行commit操作。
演进过程大致如下:
好了,今天就到这吧,MySQL的复制进程经历了一系列的演进之路,从最开始的异步复制到后面的半同步复制,再到后面的增强半同步,以及后来的MGR,在追求卓越的道路上从未放弃。想想,你是不是也是这样呢,在学习之路上始终坚持呢,让我们一起加油。MySQL的复制知识点很多很杂,期待未来与你一起学习探讨。
以上是关于MySQL的复制演进之路(起始篇)的主要内容,如果未能解决你的问题,请参考以下文章