数据库复制衍变

参考文档：http://www.ywnds.com/?p=7023

SQL复制的演变

在2000年，MySQL 3.23.15版本引入了Replication。Replication作为一种准实时同步方式，得到广泛应用。这个时候的Replicaton的实现涉及到两个线程，一个在Master，一个在Slave。Slave的I/O和SQL功能是作为一个线程，从Master获取到event后直接apply，没有relay log。这种方式使得读取event的速度会被Slave replay速度拖慢，当主备存在较大延迟时候，会导致大量binary log没有备份到Slave端。

在2002年，MySQL 4.0.2版本将Slave端event读取和执行独立成两个线程（IO线程和SQL线程），同时引入了relay log。IO线程读取event后写入relay log，SQL线程从relay log中读取event然后执行。这样即使SQL线程执行慢，Master的binary log也会尽可能的同步到Slave。当Master宕机，切换到Slave，不会出现大量数据丢失。

在2010年MySQL 5.5版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。于是在MySQL在5.5中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中。那么半同步复制是否可以做到不丢失数据呢？下面分析。

在2016年，MySQL在5.7.17中引入了一个全新的技术，称之为InnoDB Group Replication。目前官方MySQL 5.7.17基于Group replication的全同步技术已经问世，全同步技术带来了更多的数据一致性保障。相信是未来同步技术一个重要方向，值得期待。MySQL 5.7 Group Replication

• 简单的说衍变史

1. slave从master获取event，直接apply
   2.（relaylog，异步）增加了relaylog，将获取event和执行回放，分成2个线程，IO线程和SQL线程
   3.（relaylog，半同步）主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中
2. 全同步

半同步复制的几个细节

• 从库节点只有在接收到某一个事务的所有Binlog，将其写入并Flush到Relay Log文件之后，才会通知对应主库上面的等待线程。
• 如果在等待过程中，等待时间已经超过了配置的超时时间，没有任何一个从节点通知当前事务，那么此时主库会自动转换为异步复制，当至少一个半同步从节点赶上来时，主库便会自动转换为半同步方式的复制

复制的整体流程

image.png

一、在主库上把数据记录到binary log

根据WAL（write ahead log）的思路，我们知道，事务日志的产生肯定是在实际数据变化前，在数据库事务完成数据更新前，产生了binlog

二、备库将主库的binlog复制到自己的relay log

image.png

根据binlog的协议流程，我们可以了解到是从发了binlog dump命令，相当于订阅，然后主给从进行推送的模式。推送完后，从的I/O会睡眠，知道下一次被主唤醒

三、回放日志
专门的SQL线程去执行，知道追上I/O线程。这里是一些性能瓶颈的所在，因为主库可能是多线程的，但是备库是单线程在进行回放