GBase 8a MPP Cluster高可用、高可靠性优势

GBase 8a MPP Cluster通过冗余机制来保证集群的高可用特性：
1.可提供 1 个或 2 个副本数据冗余;
2.数据副本间数据自动同步;
3.复制引擎自动管理数据同步。
4. 灵活的数据副本分布方式。
 扁平/联邦架构下的无单点瓶颈架构
GBase 8a MPP Cluster无论采用扁平架构还是采用联邦架构，因为不存在单一的主节点结构，当某个节点宕机失效之后，系统仍然能够继续保持工作。对于扁平架构的情形，由于每个节点可以同时运行GCluster和GNode的两类服务，所以在整个系统之上加上负载均衡装置，即可以保证系统继续正常运转，不会出现单点失效的情况；而对于联邦架构，即将GCluster服务和GNode分别安装在不同的节点中，在多台安装GCluster的节点上如部署负载均衡策略，同扁平架构，可以实现单点故障的问题回避。
副本保存技术
根据集群的副本机制，用户可以根据需要对副本分片进行灵活配置，可根据需要配置1个副本或两个副本（即包括主分片原本，可最大实现3份数据存储），可配置副本分片到集群的任意一个节点上，这样就可以根据主机配置，灵活地在主机性能高和存储空间大的节点分配更多的主本和副本，当服务器出现异常时可以将负载均匀分布在正常的服务器上。以上的集群副本配置策略，通过根据机器能力的灵活配置，可以将1台节点上的各个实例数据的副本分配到多个物理节点上，也可以在1个物理节点上放置多个其他节点上实例的副本，这样就最大限度防止由于故障切换后木筒效应而引起的显著的性能抖动。一个集群的性能稳定性依存于副本的配置策略和1个实例所对应分片的数据大小和粒度。
基于以上机制，当单节点故障发生时，系统自动启用故障节点在多个节点上的所有副本，由于其副本分布于多个节点上，这样就最大限度防止由于故障切换后木筒效应而引起的显著的性能抖动。一个集群的性能稳定性依存于副本的配置策略和1个实例所对应分片的数据大小和粒度，根据副本的分布策略，故障后负载可以切换到放置副本的多个节点上，保证故障切换后性能不会发生显著下降。
其它冗余措施
有关存储高可用，产品部署时，推荐使用磁盘RAID5方式保证底层数据安全，防止当单块磁盘损坏后的数迅速恢复。有关网络高可用，推荐使用网卡双活及基于交换机级联方式的主备交换机构成实现网络冗余，其中任意节点上的网络故障，集群管理组件GCware可以及时监测到其发生，通过故障转移机制自动请求重发，并通过底层网络控制协议自动转发到另一网卡的网络连接上，从而实现在网络层面的自动故障检测和切换，达到业务不中断的效果。
故障转移(Failover)的实现
在集群中某一协调节点发生节点故障时（包括进程死的软件故障或者系统宕机的硬件故障），GCware首先会检测到该节点上的故障，并将这一故障状态通知给集群内其他协调节点，此时GCware会协调这个节点从集群成员中离开并调整集群构成的元数据信息更新。当协调节点故障发生后，如果对集群的某节点的GCluster（分布式任务执行调度器）发出加载和增、删、改和查询任务时，GCware会根据集群内的协调节点间的负载均衡机制，将本来分配给故障节点的任务转移到在其他协调节点来执行，这样就完成了对协调节点故障的故障转移(Failover)。
对于数据节点（计算节点）的故障转移，由于与故障节点持有同一副本数据的其他节点保持有和故障节点相同的数据副本，所以当故障后任务转移至其他数据节点时，查询处理仍能返回与故障节点同样的查询结果集合。其中对于加载或DML操作等的故障转移，由于协调节点可以根据协调节点与数据节点的心跳将任务执行切换到与故障的数据节点持有同一副本数据的其他活动数据节点上执行，所以更新后的最新数据状态会在这个活动节点的数据上反映，同时GCware会将在故障的数据节点上丢失的更新操作通过日志形式在集群内的其他节点内保存，已备故障恢复后对故障恢复节点恢复数据时使用。
GBase 8a MPP Cluster可以保证数据库故障时的数据一致性，即用户任务因为网络闪断等原因在多个节点的commit阶段，如果有部分节点提交失败，支持提交反悔（revert）机制，将其恢复到commit之前的状态（类似于一种回滚机制），也支持提交重跑（redo）机制，自动重新执行失败的用户任务（失败操作的对应日志会作为redo依据存储在系统中，这部分日志也会永久性保存到日志文件中），反悔和重做机制视故障恢复时间而定，如果恢复时间短，用户会话未丢失，则采用重跑机制。如果集群事务的发起节点故障，集群也会选出一个新的协调节点完成剩余的提交动作或者回滚动作从而保持数据的一致性。
数据节点（计算节点）故障恢复的实现
当故障数据节点完成修复，对该节点执行自动重启操作后，GCware会重新发现该节点，并使节点重新加入集群，此时该节点被标记为Locked状态，并由GCware任务调度器自动启动recovery进程（数据恢复进程为gcdatarecover）对重新回到集群的故障恢复节点进行数据恢复，即开始通过持有同一副本数据的其他节点对故障恢复节点执行数据同步，执行过程中会参照恢复日志内存储的曾处理失败的操作信息。当以上数据自动恢复同步完成后，GCware将该节点的Locked状态解除，这之后节点的状态完全恢复正常。
协调节点故障恢复的实现
协调节点不负责运算，但需要保证集群内元数据的一致性，在GCluster内部设计了一个组件来保证数据的一致性，集群中GCware记录了DDL的日志和版本，当故障恢复后，Gcware会调用元数据恢复相关组件（gcmetarecover进程），根据DDL日志和版本来保证集群中协调节点内的元数据的一致性。
GCluster集群中的节点作为协调节点对外提供访问入口，通过应用（应用程序或者负载均衡硬件）和GCluster服务提供的接口驱动的高可用机制（配置多个GCluster节点的IP，接口驱动内部自动选择可用的节点），可保证GCluster集群内协调节点的高可用。
集群灾备保障
提供虚拟集群技术可平滑解决集群级灾备问题，GBase 8a MPP Cluster虚拟集群提供统一的访问入口（能够实现对主库和备库的统一访问和调度），应用对主备集群间的访问和同步执行是透明的，对应用来说就是一个统一集群，但内部可以根据主备集群间的同步策略透明实现主备集群间的实时同步。
基于虚拟集群的灾备集群构成如下：
调度管理集群：作为虚拟集群的统一入口，调度管理集群节点的元数据系统表中存储了大集群中所有的database和table所对应的虚拟集群的信息。负责接收用户的SQL，负责SQL解析、SQL优化、分布式执行计划生成、执行调度。
distribution: 描述虚拟集群的元数据信息，描述了数据的主备分片和节点的对应关系。
作为主集群和灾备集群的虚拟子集群（运算及存储虚拟集群）：负责运算和存储的集群。负责从管理集群的节点接收SQL，基于分布在各个节点上的业务表进行数据存取和运算。
通过虚拟集群间透明的mirror table功能，实现真正的实时的集群间的数据同步：在主集群上执行基于ETL平台的DML操作时，数据会实时同步到灾备集群虚拟集群中调度集群将查询自动路由（可以根据用户群设定）到灾备集群。虚拟集群下各子集群正常运行时，可以通过负载均衡策略实现读写分离等，而当虚拟集群内任一子集群故障时可以实现跨集群的自动故障切换。
有关磁盘故障的策略
为有效应对磁盘故障，并综合考虑空间和性能代价,以及OLAP读写负载特征，建议对磁盘采用RAID5级别。对于RAID5构成的1个RAID5磁盘组,当只有1个磁盘发生故障时,通过RAID5可自行恢复此磁盘组上的数据。当1个RAID5磁盘组中存在2个以上磁盘发生故障,系统将会发生前面所叙述的介质故障(这里是用RAID5无法修复的故障情形)，需要通过基于物理备份的恢复方式来恢复集群上数据。
有关网络故障的策略
网络故障可以分成节点上网卡故障以及交换机故障的两种类型。
对于网卡故障，建议在各个节点上进行双万兆网卡的绑定(binding)，这样即使节点上1个网卡出现故障，仍能保证网卡切换后的网络通信畅通。此时GBase 8a内的GCware组件可以自动完成对故障节点上网卡故障的监视和连接重试，连接重试时可以通过底层机制自动连接备用网卡，从而使集群尽快恢复通信。
而对于交换机故障，建议配置交换机的HA构成，即使1台交换机出现掉电等故障，仍能通过向备份交换机通信切换保证集群内网络通信的畅通。对于交换机切换当中的瞬断，此时GBase 8a内的GCware组件可以自动完成对故障节点上网卡故障的监视和连接重试，连接重试时可以通过底层机制自动连接备用交换机，从而使集群尽快恢复通信。