转载

GaussDB 野生教程：GaussDB T 上生产整体规划

本文由 dbaplus 社群授权转载。

前言

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

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

“说人话。”

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

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

GaussDB T 方面资料有限，目前仅有官方教材、产品文档、开发指南等十份左右的文档，部分内容语焉不详甚至相互矛盾；
Oracle 等传统数据库的思维限制；
作为发展中的国产数据库，产品确有不足；
项目经历有限。

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

整体规划（即本文） ：着重介绍 GaussDB T 的软件架构并给出规划建议。
资源申请 ：以提升沟通效率为出发点，探讨 GaussDB T 在搭建前的环境准备要素，此外笔者还总结了一份“系统变更汇总”，分享了部分学习环境虚拟机使用经验。
软件部署 ：除了 GaussDB T、Database Manager 的基本安装命令以外，笔者还附带了大量“过于真实”的补充说明和建议。
简要测试 ：介绍了如何使用 zql、gs_om、gs_gucZenith 工具，并附带了几个实验案例，供读者更好地理解 GaussDB T。
常规变更 ：探讨了真实生产环境中安装 GaussDB T 后常见且必须的各种操作，如数据库参数调整、表空间管理、黑白名单管理等。

如何理解单机、主备、分布式三种架构

共性和差异

GaussDB 野生教程：GaussDB T 上生产整体规划

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

ETCD、DN、CM 是三种软件架构共有的组件；
GTS、CN 则是分布式架构独有的组件；
各种架构均可接入运维工具 DM 以及开发工具 Data Studio。

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

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

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

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

各种组件 / 术语的描述

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

GaussDB 野生教程：GaussDB T 上生产整体规划

理解分布式环境中的 CN 和 DN

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

GaussDB 野生教程：GaussDB T 上生产整体规划

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

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

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

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

GaussDB 野生教程：GaussDB T 上生产整体规划

在把这八条数据存储到数据库之前，我们首先得创建一个数据库表。与在 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，这是正常现象。

单机架构规划例子如下：

GaussDB 野生教程：GaussDB T 上生产整体规划

主备架构（一主一备）规划例子如下：

GaussDB 野生教程：GaussDB T 上生产整体规划

如何规划分布式架构

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

1）是否需要 GTS

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

2）是否需要 GBP

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

3）CN 要多少个

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

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

手动重建，需要人工保证掉线的 CN 与其余 CN 之间的数据字典一致性，同时还得手工执行十来个步骤；
自动重建，需要重建当前 CN，而且这个重建是不完整的（笔者实测重建后在原有 CN 上基于 clsmgr 的授权操作将丢失，从技术原理来说可以理解。问题来了，运维规范得跟上，类似系统视图授权之类操作需要加入到重建步骤里面）。

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 协议）规划例子如下：

GaussDB 野生教程：GaussDB T 上生产整体规划

一起来打脸

对于本文内容有什么疑问或点赞或吐槽，又或者你在学习和使用 GaussDB 过程中有什么心得体会，都欢迎大家在评论区留言，一起探讨交流。笔者先自问自答起个头：

Q：GaussDB T 如何下载？

A：介质方面 GaussDB T 软件只能从华为官方渠道通过相应的项目去申请。官方文档倒是可以从官方的 support 网站上下载。GaussDB T 的最新版文档，大家可以经常关注下： https://support.huawei.com/carrier/productNewOffering?col=product&path=PBI1-21430725/PBI1-21430757/PBI1-21431665/PBI1-250430182/PBI1-250399837

下篇内容预告

“GaussDB 野生教程”系列的下一篇内容将针对“资源申请”展开，以提升沟通效率为出发点，探讨 GaussDB T 在搭建前的环境准备要素。此外，笔者还总结了一份“系统变更汇总”，分享部分学习环境虚拟机的使用经验。敬请持续关注。

作者介绍：

黎君原，新炬网络服役 10+ 年的老鸟，期间打过杂、搬过砖、挖过坑（运维、割接、系统建设），目前对于国产数据库来说只是个新兵。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650786678&idx=1&sn=1252eb529230bfac2f16226ab4485394&chksm=f3f97ee3c48ef7f5e20a11d532b4ca27477190a8b01d2b0757b0291f3355a0446d9e398b94b7&scene=27#wechat_redirect

原文 https://www.infoq.cn/article/L0pKGGNQNpEWLUse1sKI

正文到此结束