老紫竹的家

GBase 8a是通过副本来确保高可用，当某部分数据(分片)所在节点故障时，由副本节点继续提供服务。但如果发生一些意外故障，比如服务器断电，导致文件系统故障，出现过文件丢失，目录变文件等问题，此时主备分片是否一致？如果不一致如何处理？本文介绍此类问题的一个排查和处理方案。

GBase 8a通过show processlist得到当前节点的连接信息，本文介绍host列的信息，包括带%百分号，主机名，IP加端口的。其中显示百分号%是因为创建的存储过程的用户，是允许任意主机连接，而当前用户又不是创建者时才显示%。

GBase 8a在做非Hash列的group时，默认策略是将各个节点的数据先在本地group后，再将结果发到临时表做二次聚合。此方案在聚合列唯一值少，聚合结果行数相比原始数据行数有明显降低时是非常适合的，但如果聚合结果没有降低，比如1000万行聚合后999万行，汇总到临时表后二次聚合，结果还是在999万行，则第一次的本地聚合就出现了资源浪费。GBase 8a提供了一个可选参数，通过延迟聚合来提升性能。

在GBase 8a中，会将子查询保存到临时表里。 如果多个子查询是完全相同的，则会导致资源浪费。本文提供了CTE和参数共2个可行方案来优化这个场景。

GBase 8a是通过副本机制来提供高可用保障，但如果出现主副本数据均损坏且无法修复呢？按标准逻辑，有关的表将无法保障完整性，所有相关表查询将报错。本文提供一种在【允许数据丢失，查询结果不完整的前提下】，对现有表的剩余数据可以查询的方法，以及通过缩容，保证新建的表可以正常使用的方案，以及测试过程。

GBase 8a通过gcware集群维护集群状态，包括各个节点服务，数据一致性等。其中主动检查机制是gcware定时扫描各个节点，被动检查是同注册方式由各节点服务上报给gcware。本文介绍gcware主动检查机制。