“学习GaussDB是一种什么体验？”

“路漫漫其修远兮，吾将上下而求索！”

“说人话。”

“打脸，打脸，再打脸……”

上面就是笔者写这个系列文章的原因了，笔者学习GaussDB的过程中被“打脸”太多，现在想稍稍停步，做个总结。而为了掩饰自己个人能力不足，笔者还补充了下面几个学习困难的原因：

笔者写这个系列文章的契机为GaussDB T 1.0.2刚发布不久，想借着“安装数据库”这种最基础的操作，以加固对GaussDB T的理解。与着重展示搭建步骤的文章不同，本文是奔着生产部署以及后续运维而去的，安装只是过程，理解才是关键，而实际运维怎么办才是重中之重。这个系列的文章将由五部分组成：

1. 整体规划（即本文）：着重介绍GaussDB T的软件架构并给出规划建议。

2. 资源申请：以提升沟通效率为出发点，探讨GaussDB T在搭建前的环境准备要素，此外笔者还总结了一份“系统变更汇总”，分享了部分学习环境虚拟机使用经验。

3. 软件部署：除了GaussDB T、Database Manager的基本安装命令以外，笔者还附带了大量“过于真实”的补充说明和建议。

4. 简要测试：介绍了如何使用zql、gs_om、gs_gucZenith工具，并附带了几个实验案例，供读者更好地理解GaussDB T。

5. 常规变更：探讨了真实生产环境中安装GaussDB T后常见且必须的各种操作，如数据库参数调整、表空间管理、黑白名单管理等。

上面是从官方产品文档中摘录出来的三种软件架构图，从图中我们可以看到：

对于单机、主备两种架构来说，值得商榷的一点是，到底ETCD以及CM需不需要安装。根据官方教材中所描述的“数据库安装”以及官方培训，单机和主备的安装步骤均为上传一个不到10MB的安装包，然后执行几条简单的命令，即可完成安装步骤，此处的安装对应的是DN，至于ETCD和CM是不涉及其中的。

而笔者所实际接触的某个架构为主备的项目中是完整部署ETCD以及CM的，由此，笔者偏向于实际生产是需要安装ETCD和CM的。而从理论而言，CM可以在主备架构中承担“主备倒换”的功能从而实现故障自动切换，ETCD则为CM运行的基础，故而应当在主备环境中部署这两个组件；至于单机模块，基本仅会在测试环境中涉及，who care?本系列文章以完整安装CM、ETCD的前提下进行。装与不装这两类实例对于生产而言最大的差异在于运维的命令都得改变，这点会在后续软件部署的章节中探讨。

单机和主备两种架构和传统的关系型数据库在使用上没有太大的区别，就某个角度而言，甚至可以说是“简化版”。至于分布式，在理解上则复杂一些，笔者将通过一个实际的例子读者理解。

Database Manager（简称DM，下同）是官方的运维工具，实际效果一般，而其内存消耗更是让虚拟机吃不消，然而考虑到实际生产中，此工具可用于数据库升级。因此笔者还是建议就学习而言，还是带上此工具。

下面的表格是笔者结合官方文档、官方教材以及个人理解，总结出的各种组件的要素，理解这部分内容是规划实例分布情况的前提。

下面是笔者的其中一个分布式测试环境（注：GTS仅单实例是错误示范，笔者仅是方便测试GTS实例所在主机宕机的影响才这么做的）。

这是一个由3CN3DN组成的5节点分布式环境，具体描述如下：

1）DN组共三个，每组均为两副本，主DN分布在主机1、主机2、主机3上，备DN则分布在主机3、主机4、主机5，此环境的“分片数”为3。

2）CN共三个，客户可以通过连接主机1、主机2或者主机4访问业务数据。

假设这里有八条业务数据，其中ID为主键，（NUM业务上也可以保证唯一且非空）详情如下：

在把这八条数据存储到数据库之前，我们首先得创建一个数据库表。与在Oracle等传统关系型数据库上建表不同的是，我们需要考虑额外一个问题是，数据怎么在这三个DN组里面分配呢？这就是GaussDB里面的“水平分表”，具体包括HASH、RANGE、LIST、Replication实在方式，具体可以参考产品文档相应描述，笔者这里选择使用ID字段做HASH分布。

选定水平分表方式之后，笔者需要做的就是创建表并插入数据，问题来了，在哪里操作呢？作为业务数据，我们可以在主机1、主机2和主机4上随机选择一个执行操作即可，此处笔者选择主机1并完成相应执行。

至此，表创建好，数据也导入好了，为了验证CN之间的平等性，我们可以连接分别主机2、主机4上验证确定相应表和数据均可被访问。这里引申出一个实际问题，生产环境中，应用程序该连哪个CN。官方给了F5硬负载均衡以及GaussDB软负载均衡两种方式，具体可以参考官方产品文档工作负载管理部分。

接下去我们还可以分别连接到DN中，查看数据的分布情况，笔者实测的结果为三个DN里面分布含有5、2、1条记录。数据量实在太少，这也可以理解。

最后，回到表里面，我们最初的描述里面，NUM字段是唯一且非空的，那我们能不能直接基于NUM字段创建一个唯一索引呢？答案是否定的，创建索引语句直接遇到"GS-00101, Capability: table's distribute columns list not the subset of unique index columns list not supported"这个报错，好吧，不带DISTRIBUTE BY的字段玩是不行的。这也对应了官方开发者指南里面的一句话“不支持跨DN节点的唯一性约束；如果需要支持唯一性约束，唯一性约束列必须包含所有分片列。”

通过上面的例子，我们可以大概了解CN和DN的作用了，也大概能看到分布式架构的难处：每个表都得考虑水平分布策略，而水平分表策略还可能和唯一性约束等常规项目相抵触。

单机架构的规划一句话带过即可，集群包括三个ETCD、一个CM、一个DN，均部署在一台主机上。

主备架构的规划方面可以说的有如下几点：

1）建议配置浮动IP共业务使用

如上文所述，这可以减少主备切换对业务的影响。

2）重点关注高可用部分

高可用是一个可以展开慢慢研究的项目。

对于“一主一备”这种简单环境，其实仅需要设置一个QUORUM_ANY = 1即可，此配置默认关联“最大可用”，有备机时相当于最大保护，没主机时相当于最佳性能，可是说是最合理的选项了。

3）“一主一备”环境中ETCD分布并不均匀

“一主一备”环境包含两台机器，那必然会导致一台主机上2个ETCD，另一台主机上1个ETCD，这是正常现象。

单机架构规划例子如下：

分布式架构的规划涉及如下几点：

1）是否需要GTS

GTS涉及分布式事务中的ACID，这个具体看业务需求而定了。笔者需要提醒的是，目前GTS只能一主一备，要是都凉了，集群的状态也会变成不可用。

2）是否需要GBP

GBP总不能有TCP协议作死吧，还是得有RDMA协议支持，笔者暂时还没研究这块。

3）CN要多少个

CN目前只能一台主机上部署一个，而且DN是没有主备同步的，只能多部署几个当买个保险了。要是CN都凉了，集群状态同样会变成不可用。此外，官方的建议是CN数少于10个。

当然，CN多了也会带来运维上的麻烦，例如CN所在的主机掉线了，默认的5分钟(通过coordinatorheartbeattimeout控制)内不恢复的话，CN就出于DELETED状态，接下去就是两杯毒酒挑一杯的事了。

4）DN同步协议怎么选

DN的同步协议通过配置文件的clusterconfig.xml的datanodeType参数控制，可选择有DN_ZENITH_ZPAXO、DN_ZENITH_HA。

DN_ZENITH_ZPAXOS：DN主备同步协议使用GS-Paxos，适合对可靠性要求较高的系统。集群部署时，最少必须部署2台备机，最多支持8台备机。

DN_ZENITH_HA：DN主备同步协议使用Quorum，适合对灵活性要求较高的系统。集群部署时，最少可部署1台备机，最多支持9台备机。

如上文所述，DN组是一个都不能少的，哪怕多个DN组中仅一个存在异常，整个集群均会变成不可用状态，因此请慎重配置DN。

分布式架构（2CN3DN，采用ZPAXOS协议）规划例子如下：