MySQL组复制MGR(一)– 技术概述

痞子衡嵌入式:16MB以上NOR Flash使用不当可能会造成软复位后i.MXRT无法正常启动

(一)复制技术的发展

MySQL的复制技术主要经历了异步主从复制,半同步复制,组复制(Group Replication)3个阶段。

(1)传统的异步主从复制

传统的MySQL提供了一种简单的主从复制方法。有1个主服务器(master),有1个或多个从服务器(slave),主服务器执行事务,然后提交,从服务器异步接收日志,并重新应用日志。

该架构存在的问题有:如果主服务器/数据库crash了,日志没有完成传送到备库,那么当备库切换为主库的时候,可能存在数据丢失的风险。

异步复制架构如下:

                                     图1.MySQL Asynchronous Replication


(2)半同步复制

半同步复制向同步协议添加一个步骤,这意味着主库在执行提交的时候,需要等待从库确认已经接收到事务,才能进行提交。

该架构存在的问题有:主库必须等待备库接收到日志并返回响应才算完成事物,造成了主库的延迟,这个延迟最少是一个TCP/IP往返的时间,因此半同步复制最好在延迟低的网络中使用

半同步复制架构如下:

Java Web(2)-jQuery下

                                    图2.MySQL semisynchronous Replication


(3)组复制

组复制是一种可用于实施容错系统的技术。组复制是一组服务器,每个服务器都有自己的完整数据副本,并通过消息传递相互交互。一个组复制由多个服务器组成,该组中的每个服务器都可以随时独立执行事务。但是,所有读写事务仅在获得组批准后才提交,换句话说,对于任何读写事务,该组都需要确定提交,因此提交操作不是来自原始服务器的单方面决定。只读事务不需要组内协调,可以立即提交。

组复制可以是单主模式和多主模式,多主模式意味所有组成员都可以执行写操作,这样就可能存在事务冲突,根据组复制冲突监测机制,如果存在两个不同的server成员更新同一行的并发事务,排在最前面的可以在所有server成员上提交,第二个事务在源server上回滚,并在组中的其它server上删除。

                                      图3.MySQL Group Replication

关于三种复制技术,个人觉得:异步复制提供了主从方案,降低了单节点运行数据库的风险;后续的半同步复制是异步主从复制的加强,解决了数据丢失的风险,但是依然存在网络延迟,切换麻烦的问题(例如10个节点,1主9从,主节点宕机,当把一个从节点提升为主节点后,其它节点需要手动修改master),而组复制则拥有了自动故障转移failover的能力,当主节点发生故障(单主模式才需考虑)时,组内部会自动选择主节点。


(二)组复制的容错能力

组复制建立在Paxos分布式算法之上,以提供服务器之间的分布式协调,因此,他需要大多数服务器处于活动状态才能正常工作。如果有n台服务器,最多允许故障的服务器数量为f,那么n与f之间的关系为:n=2f+1。或许这么看有些难以理解,可以看下面的关系:

组复制服务器数量 多数 允许故障的服务器数量
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3

对组复制有了一定的了解,接下来,我们一起来搭建组复制。。。

MySQL组复制MGR(一)– 技术概述
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

全栈的自我修养: 0005 Java 包扫描实现和应用(Jar篇)