建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

彩虹上的水瓶座

发帖: 75粉丝: 33

级别 : 版主

发消息 + 关注

发表于2020年06月17日 15:45:17 330 3
直达本楼层的链接
楼主
显示全部楼层
[博文鉴赏] GaussDB for DWS高可用之主备从HA技术

技术背景

随着客户业务对数据可靠性和服务可用性要求的提高,主备架构在OLAP系统中也已被广泛使用。而分析型数据库往往数据量大,节点数多,分布式系统下发生硬件故障已成为常态。

对于传统两副本系统(一主一备最大可用HA模式),单节点故障后,为了服务可用性,一般都会选择让另一个正常节点继续提供服务,在故障节点恢复前数据只有单副本运行。而由于数据量大,往往故障节点修复时间和数据重建时间都很长,此时一旦正常主机再次发生故障,将造成数据丢失的严重后果。另外,根据分布式CAP原理,两副本系统一旦采用最大可用策略,将损失分区容错性(即脑裂双主,下文详述)。

尽管三副本通过多数派复制策略可以解决上述问题,但三副本带来了更多的存储成本开销,在OLAP数据库中无法成为主流解决方案。因此,GaussDB for DWS创新性的在数据节点(DN)引入从备概念,使得集群在任意单点故障时仍保持两副本可用,相比传统三副本节约了三分之一的存储空间,但数据可靠性基本持平。

技术原理

主备从HA1.png

如上图所示,GaussDB for DWS引入备机和从备的概念,正常情况下主机和备机通过日志流复制和数据页流复制进行强同步,主机与从备仅保持连接并不发送日志和数据,因此从备不占用额外存储资源。当备机发生故障时,主机自动感知,将未完成同步的日志和数据发送给从备,并保持主从强同步。主备同步向主从同步的切换在内核底层HA实现,事务层并不感知,因此不会造成任何报错和不一致。

同理,当主机发生故障时,由集群管理感知并仲裁备机升主,升主后的备机连接从备进行主从强同步。因此,在一组DN内发生单点故障后,不会影响服务可用性,同时数据仍然有两份副本的可靠性保障。

日志分叉与脑裂

主备从HA2.png

尽管GaussDB for DWS主备间是强同步,但各自落盘顺序总有先后。与绝大多数数据库一样,GaussDB for DWS的物理日志总是先写主机后写备机。如上图所示,主机崩溃前可能有一部分日志未同步给备机(红色部分未同步,蓝色部分已同步),备机升主后会提供服务,会写入新的日志(绿色部分)。由于物理日志按照lsn顺序递增,主机的红色日志与备机的绿色日志占用了相同的一段lsn,形成冲突,即日志分叉。

日志分叉可能带来严重问题,例如一旦分叉后发生集群重启,传统两副本方式可能无法通过日志长度判断应该选谁成为新主,选错将造成数据丢失(应选包含绿色日志的节点为主,因为其可能包含已提交事务;而红色段日志一定不存在已提交事务,可以丢弃)。

在引入从备后,主机故障备机升主,升主后将与从备进行强同步,因此从备上的日志一定与新主保持一致。在上述场景中,DN响应升主命令时可以额外判断从备日志,通过校验CRC来判断日志是否分叉,与从备日志一致的才能升主成功,从而保证了仲裁的正确性和数据的一致性。

此外,在极限断网、进程僵死、集群管理失效等场景下,有可能在主机存活时错误的将备机升主,形成双主脑裂。传统的两副本HA机制无法识别此类场景,只能通过外部加固手段减少脑裂发生的概率。而在主备从架构下,从备可临时作为仲裁者,类似三副本多数派机制。DN响应升主时与从备建连并进行日志校验,只有与从备形成多数派的主机才实际有效,而另外的主机因无法与从备强同步而自动失效,从而解决了脑裂的问题。

数据可靠性

对于服务可用性,主备从HA与三副本多数派复制和两副本最大可用HA相同,都能够容忍单副本故障。对于数据可靠性,主备从HA提供了强于两副本、接近三副本的能力。

主备从HA3.png

以上图所示场景为例,备机故障一段时间后恢复。从时间轴上看,可以分为P1主备同步、P2主从同步、P3备机追赶和P4主备同步四个阶段。

P1/P4:主备同步,数据拥有两副本可靠性,数据可靠性与传统两副本相同。

P2:发生单节点故障,主从同步,数据仍然具有两副本可靠性,优于传统两副本。此时如果主机磁盘损坏无法恢复,由于从备仍有一份数据,当备机恢复后即可提供服务,而传统两副本则必须等待主机恢复才能提供服务,否则会数据丢失。

P3:备机恢复后追赶P2阶段生成的日志和数据,此时主机仍然与从备强同步并正常服务。追赶阶段一旦发生主机故障,备机升主时可以连接从备补齐日志和数据并提供服务;而传统两副本则因备机没有追赶完成而无法恢复服务,否则会数据丢失。

以上,主备从HAP2P3阶段相比两副本有额外的可靠性优势。而相比三副本,只有在主备两节点都发生磁盘损坏且不可恢复的场景下,可靠性方面具有劣势。

总结

综上所述,主备从HA在保持了两副本存储成本的前提下,解决了传统两副本最大可用HA模式中因日志分叉造成的数据一致性问题和脑裂问题,同时提供了接近三副本的更高数据可靠性。


转载自博文链接为:

https://bbs.huaweicloud.com/blogs/175249

举报
分享

分享文章到朋友圈

分享文章到微博

彩虹上的水瓶座

发帖: 75粉丝: 33

级别 : 版主

发消息 + 关注

发表于2020年06月17日 15:55:54
直达本楼层的链接
沙发
显示全部楼层

不知道CAP原理的小伙伴,可以参考这篇分享

https://bbs.huaweicloud.com/forum/thread-60675-1-1.html

点赞1 评论 引用 举报

独孤求败马?

发帖: 119粉丝: 1

级别 : 版主

发消息 + 关注

发表于2020年06月17日 16:11:18
直达本楼层的链接
板凳
显示全部楼层

详细有内涵,感谢分享

点赞 评论 引用 举报

独孤求败马?

发帖: 119粉丝: 1

级别 : 版主

发消息 + 关注

发表于2020年06月17日 16:19:36
直达本楼层的链接
地板
显示全部楼层

有个问题问下,当备机坏了,主从开始同步,这时候从机是没有数据的,你所说的主从开始同步除了将主备没有拷贝完成的日志复制了过去,数据是怎么实现一致的?

评论
西湖怪人 2020-6-17 16:59 评论

对于行存表,非multi insert场景,日志可以恢复所有的数据。对于列存及行存multi insert(开启数据页复制参数),会走数据页复制流程,主机通过记录BCM标记来判断哪些页面完成了主备同步。主从复制的页面不会记录BCM标记位,因此备机故障恢复后可以根据BCM标记位来补齐这部分数据页(catchup)。 详细可参考https://bbs.huaweicloud.com/blogs/175234 2.2.3 BCM与catchup设计。

... 查看全部
点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册