MySQL Group Replication 同步 or 异步?

来源:互联网 发布:软件外包公司管理制度 编辑:程序博客网 时间:2024/05/22 06:07

参考国外MySQL大神的博客lefred.be,理解一下Group Replication是同步还是异步的,原文地址请戳:MySQL Group Replication… synchronous or asynchronous replication ?

经过前面文章的讨论,我们知道,Group Replication利用分布式一致性协议,来保证数据的最终一致性。我们知道,传统的复制,是异步复制的。那么,对于组复制,到底它是异步的还是同步的?

Group Replication = 组复制

理解Replication

通俗来说,复制是指主库(master)上写的数据,能够在从库(slave)上保持同步。复制涉及以下步骤:

  1. 主库本地提交更新
  2. 主库生成binlog event
  3. 主库传输binlog event到从库上
  4. 从库将传输得到的binlog event追加到relay log中
  5. 从库应用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上开启事务,执行一系列的操作:

cert_trx1

cert_trx3

接着事务提交,事务内所产生的binlog封装成全局有序的write set,传播到组内其他节点:

cert_trx5-1

接收完binlog的节点就可以自行进行certify阶段,决定这些binlog event是否能够并自己本地应用?会不会产生冲突?

cert_trx6-1

当主节点收到大多数节点的certify阶段完成后,就可以返回并响应事务的提交,而不用等待所有的节点,还有接下来binlog add到relay log再从relay log应用数据这些阶段,通通不用等

cert_trx7-1.png

其他节点对于binlog追加到relay log以及最后的应用,都是独立进行的:

cert_trx8-1.png

cert_trx9-3.png

由于数据的应用是异步的操作,实际上解释了组复制只能保证数据最终一致性这个结论。也就说,很有可能你会在从节点上,读取不到你刚刚提交的记录!理解组复制是最终一致性的,这一点很重要。另外,上面也总结了,组复制,实际上还是异步的复制。