MySQL Cluster 数据复制的三种方式

MySQL Cluster 数据同步的发展是从 “弱一致性” 到 “”强一致性” 的进化。

了解这个发展过程，理解各个数据复制模式的特征，才能在具体的场景下选择合适的方案。

异步复制（MySQL Replication）

主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。

主从同步过程中 Master 有一个工作线程 IO dump thread，Slave 有 IO thread 和 SQL thread 两个工作线程。

Master 将接收到的 SQL 请求记录到自己的 binlog 中，Slave IO thread 去请求 Master 的 binlog，将 binlog 写到自己的 relay log 中，然后 Slave 重放 relay log 中的 SQL 语句。

这种方式数据写入的效率是最高的，但是 Master 宕机的时，如果数据没有同步完，就会出现丢失数据的情况。

半同步复制（MySQL Semisync）

介于 “全同步复制” 和 “异步复制” 之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。

同时，这里只是一个收到的反馈，而不是已经完全执行并且提交的反馈，这样就节省了很多时间。

半同步复制提升了主从之间数据的一致性，让复制更加安全可靠。

全同步复制（MySQL Group Replication）

MGR 全称 MySQL Group Replication，是 MySQL 官方于 2016 年推出的一个全新的高可用扩展解决方案，是一种基于 paxos 协议的状态机复制。在 MGR 出现之前，MySQL Cluster 都是以 master-slave 架构出现的。

MGR 由若干个节点共同组成一个复制组，一个事务提交，必须经过组内大多数节点（N／2+1）决议并通过，才能提交。consensus 层为一致性协议层，在事务提交过程中，发生级间通讯，由2个节点决议（cerity）通过这个事务，事务才能够得以提交并响应。

当主库提交事务之后，所有的从库节点必须收到，APPLY 并且提交这些事务，然后主库线程才能继续做后续操作。这种方式的明显缺点就是，主库完成一个事务的时间被拉长，性能降低。

组复制是为了解决异步复制和半同步复制可能产生的数据不一致问题。

总结

不同业务场景对数据读写效率以及一致性要求是不同的。

在微服务架构中，不同的微服务可以根据自己业务对数据一致性和读写效率的要求，选择不同的 MySQL Cluster 模式。

例如：

日志管理可以选择 MySQL Replication 。

资源管理可以选择 MySQL Semisync。

费用管理可以选择 MySQL Group Replication 。