参考国外MySQL大神的博客lefred.be,理解一下Group Replication是同步还是异步的,原文地址请戳:MySQL Group Replication… synchronous or asynchronous replication ?
经过前面文章的讨论,我们知道,Group Replication利用分布式一致性协议,来保证数据的最终一致性。我们知道,传统的复制,是异步复制的。那么,对于组复制,到底它是异步的还是同步的?
Group Replication = 组复制
理解Replication
通俗来说,复制是指主库(master)上写的数据,能够在从库(slave)上保持同步。复制涉及以下步骤:
- 主库本地提交更新
- 主库生成binlog event
- 主库传输binlog event到从库上
- 从库将传输得到的binlog event追加到relay log中
- 从库应用relay log中的binlog event,实现数据的同步
组复制仍然是异步的复制
实际上,对于组复制来说,只有【第3步】是同步的,剩下的步骤都是异步的。在组复制中,步骤3相当于发送write set,write set中包含一系列全局有序的bin log event。而对于binlog event add到 relay log以及最后对于relay log的应用,都是异步的。
另外一点很重要,只有当事务commit的时候,才会发送write set,也就是将当前事务所涉及到的binlog event在组内进行传播。假设你的事务是个大事务,产生了很多binlog event,那么这个事务的提交将是一个耗时的操作,它将会等待组内的大多数(majority)存活节点共同决议这个提交,才会返回。
用一组图来分析说明这个过程:
这里我们假设node1-3组成MGR集群,模式为单主模式,即node1为主,node2和node3为从节点
在主节点node1上开启事务,执行一系列的操作:
接着事务提交,事务内所产生的binlog封装成全局有序的write set,传播到组内其他节点:
接收完binlog的节点就可以自行进行certify阶段,决定这些binlog event是否能够并自己本地应用?会不会产生冲突?
当主节点收到大多数节点的certify阶段完成后,就可以返回并响应事务的提交,而不用等待所有的节点,还有接下来binlog add到relay log再从relay log应用数据这些阶段,通通不用等
其他节点对于binlog追加到relay log以及最后的应用,都是独立进行的:
由于数据的应用是异步的操作,实际上解释了组复制只能保证数据最终一致性这个结论。也就说,很有可能你会在从节点上,读取不到你刚刚提交的记录!理解组复制是最终一致性的,这一点很重要。另外,上面也总结了,组复制,实际上还是异步的复制。