GaussDB集群管理组件
云原生数据库支持全球集群部署和区域集群部署，相应的，故障检测也分为全球集群故障检测和区域 集群内故障检测，全球集群故障主要检测区域集群网络故障、区域集群脑裂故障。区域集群内检测节点网络故障、租户节点分区、集群管理节点分区、DFV存储故障。不同的故障需要不同的心跳链路来检测，具体如下图所示。
-
DCHA网络心跳，DCHA全称为DeCentralized High Availability，即去中心化故障快速检测方案。DCHA本质是一种邻居故障检测方法，能够更好地适应大规模集群故障检测，但是当大规模集群故障时可能导致漏报问题，需要通过其他机制，比如租约心跳机制作为补充。
-
节点租约心跳。节点租约心跳故障检测是指节点向集群管理节点获取心跳租约，当集群管理节点检测节点长时间未申请租约，将会判断此节点故障，同时如果节点长时间无法从集群管理节点获取租约，将进行自杀重启。
-
租户节点间网络心跳和DFV心跳。租户节点间互发网络心跳、写入DFV磁盘心跳，通过Membership Voting Disk机制判断租户脑裂和租户节点故障，并进行租户视图变更和故障重启。
-
集群管理间心跳根据部署形态选择不同心跳机制。如果是共享存储部署，则选用Membership Voting Disk机制。如果是share nothing单机部署形态，则选择普通心跳，通过Raft协议避免分区。
-
区域集群间网络心跳。每个区域集群通过Membership Voting Disk的一致性视图选择一个节点或者通过Raft协议选择的主节点当做本区域集群的节点代表与其他区域集群进行通信。区域集群间选择普通网络心跳，通过Raft协议避免区域集群的分区。
-
如果集群管理服务整体失效，则租户进程不能继续提供服务。如果节点主进程失效，则租户进程也不能继续提供服务。
云原生数据库以OLTP为主，同时也支持基于OLTP数据的OLAP需求，如每日报表。在云原生数据库中，DBA可以选择为这部分表创建列存索引。创建完列存索引之后，执行器在做顺序扫描的时候，会自动选择列存索引进行数据的读取，实现快速扫描计算的能力。
云原生数据库以行存为基础，数据的增删改都先以行存的形式落到数据库中。事务、xlog等机制保障了行存的ACID特性。行存采用Inplace-update引擎，一个Tuple一旦被插入到表中，位置基本不会改变。每个Tuple可以用它的物理位置（文件页号+页内偏移，称为RowID），作为唯一标识。事务的多版本在回滚段中，可以根据RowID直接访问。
云原生数据库中的列存索引方案如下图所示：列存是根据行存构建的一个read-only的副本，每次对行存的更新操作会在元数据区域（In Memory Delta Unit，IMDU）增加一条RowID记录。列存扫描的时候会查看元数据区域，确定哪些Tuple已经失效，再去行存中根据RowID读相应的数据。后台线程会周期性地更新列存，回收元数据。如果列存索引和更新操作不在同一台机器上，使用batch模式，即把一个事务中产生的所有失效信息，统一打包到一个RPC请求中，发送给列存索引所在的实例上，从而减少对OLTP请求的影响。行存的block为8KB，列存需要较多的数据量才能实现更好的压缩、向量化操作等优化。所以一个IMCU对应多个行存的block，目前暂定为1024个，这样一个1024个block称为一个Super Block。
为了支持列存大小超过内存容量的场景，列存索引支持从内存中置换到磁盘上。但是列存本身在故障情况下并不能保证自身的一致性，故障重启之后列存需要根据行存的内容重新构建。所以这里的磁盘对于列存来说，是内存的延伸，用来缓存额外的数据。
因为DU容量小，且经常被修改，所以可以常驻内存。列存索引和行存完全是解耦开的。部署形态上，列存索引既可以与行存在一个实例中，节约物理资源；也可以与行存在不同的实例中，避免OLAP请求对OLTP请求产生影响。两种部署形态分别如下图所示：
