GaussDB for DWS高可用之CN>M组件高可用介绍
GaussDB(DWS)高可用之CN>M组件高可用介绍
1. 前言
- 适用版本:【8.0.0及以上】
GaussDB(DWS) 的内核侧组件为DN、CN、GTM,内核侧组件是通过集群管理组件CM server、CM agent 来进行管理的。内核组件和集群管理组件共同组成了GaussDB(DWS) 集群。组件的逻辑关系如下图:
2. 内核高可用
2.1 DN 高可用
DN 的高可用是基于主备从的架构进行构筑,详细的原理请参见之前技术博文,本文不展开描述。
2.2 CN 高可用
在 DWS 集群中通常会部署多个CN,每个CN都可读写。如果一个CN故障,那么客户端可以使用其它CN。由于CN只存储元信息数据(即每张用户表数据分布在哪几个DN),因此只有DDL操作时才涉及到CN存储数据,DML时CN并不需要写数据。
- CN 数据同步
在DDL操作时,接收业务的CN会把该SQL发送到所有其他CN与所有DN,通过两阶段提交来保证各个CN的数据一致性。这里也有一个场景:即当一个CN故障时,那么集群便无法操作DDL,此时CM已经提供了CN的自动剔除和加回功能,可以方便的处理CN的故障。
- CN 重建方式
CN 的修复是通过使用一个正常的CN重建故障CN, 具体技术是用CN build 的方式使用其它CN重建出CN, 这个也是充分利用CN间互为多写互为备机的机制。在较老版本中使用gs_dump工具来实现 CN 的重建。
- CN 状态转换
CN的状态分为 4 种如下图:Normal: 是正常提供服务,Starting: 实例启动过程,Down: 停止,Deleted: 被剔除状态。 在集群中CN的操作都是由CM agent来完成的,基本上不需要人工介入。CN的状态转换图如图1所示。
3. GTM 高可用
在DWS集群中,GTM的作用是产生全局唯一的事务号及sequence id, 在DWS集群中GTM主备两个实例,主GTM提供服务和给备GTM同步信息,备GTM负责在主GTM故障时,升主继续提供服务。主备GTM的数据都需要在本地落盘,其中主GTM在达到阈值后写本地数据并同时保证在备GTM中也落盘,这样保证备GTM升主后不会分配重复的数据。
3.1 GTM 数据同步
- GTM 同步流程
主 GTM 在xid、sequence 达到阈值时刷新本地和备GTM的数据,在上一次阈值是写入数据后的第一次分配的xid、sequence 的xid的基础上 + 一个值(20w) 作为一个阈值,在 xid、sequnce分配到这个点时,触发写本地和同步备GTM,此时备GTM接收到消息后创建一个服务线程,并将事务xid写入本地文件,回复消息,主机的一次同步便完成。GTM在内存中xid每加20w时会向备机同步一次。如果GTM主机永久故障,GTM备机升主后,只需要重新初始化一个GTM实例出来然后和主机同步xid即可。
- GTM 同步模式
- sync auto:异步同步模式。GTM以pending模式启动后,所呈现的初始同步模式。
- sync on:强同步模式。当GTM主备启动后,CM_Server接收到CM_Agent上报的主备GTM连接正常的消息时,会将GTM主备的同步状态从sync auto置为sync on。
- sync off:GTM主备不同步并且主GTM也不与ETCD同步。Sync off 默认不使用。
注:
- 在主备从无ETCD集群中,如果主备连接异常,主GTM的同步状态会变为most available。而在有ETCD的集群中,无论主备是否连接异常或挂掉,ETCD是否挂掉,都不会切换最大可用模式。
- 只有GTM处于sync on模式下,failover和switchover操作才可进行。
3.2 GTM 状态转换
GTM 的角色与 DN 类似,也是有primary, standby, pending 三种,并且通过外部命令switchover/failover/notify进行角色间的转换。当然这种转换是由CM层自动完成,CM拉起的GTM状态初始都是Pending状态,然后通过比较xid决定主备,xid大的为主GTM,xid小的为备GTM。当主备连接异常且无ETCD时,主GTM的同步状态会变为most_available。当主GTM出现问题时,CM会仲裁备GTM,通过failover升主GTM,如果无ETCD,那么同步状态变为most available。也可以通过switchover进行主备GTM转换,此时同步状态不会变化。GTM的状态转换图如图2所示。
4. 总结
本文主要对DWS中CN高可用以及GTM高可用的原理进行了介绍。后续会增加DN高可用中switchover、failover、catchup等流程的原理解析,并对关键日志进行解读。GaussDB(DWS) 经过若干版本的演进,从最初pgxc组件间没有任何高可用能力,到现在已经具备完整的高可用能力。后续高可用的能力还是围绕单点故障快速恢复,业务不中断进行构筑。
- 点赞
- 收藏
- 关注作者
评论(0)