从"会用"到"会装"：南大通用GCDW培训与部署实战笔记

关于这次培训
今年夏天，我参加了南大通用组织的第一期GCDW培训。说实话，作为一名数据库从业者，我对南大通用的产品并不陌生——在此之前已经接触过GBase 8a，也参加过8a的相关培训，日常工作中两个产品都在用。但"用"和"装"之间的差距，只有真正动手部署过的人才会懂。

培训结束后有一周的实战操作任务：独立完成一套GCDW集群的部署。当时觉得应该不算太难——毕竟文档写得挺详细，而且培训的时候老师也演示过。但真正上手之后才发现，文档上的每一步都那么简单，可每一步都可能因为环境差异而出问题。这篇笔记记录的就是这一周里踩过的坑和爬出来的过程，也算是给自己一个交代。

为什么参加这次培训？
说说我的背景吧。工作以来一直在和数据库打交道，GBase 8a用了挺长时间，从查询优化到性能调优都有过实战积累，GCDW在项目上也开始逐步使用。但坦白讲，我之前所有的经验都集中在"使用"层面——怎么建表、怎么写SQL、怎么调优查询。至于这东西是怎么部署起来的、底层架构是怎么回事、出了问题该怎么从系统层面排查，几乎是空白。这种感觉就像你会开车，但从来没打开过引擎盖。平时上路没问题，一旦车子出了故障，你只能打电话求救。所以看到GCDW第一期培训的通知时，我几乎是毫不犹豫就报了名。一方面是想补上部署这块短板，另一方面也是觉得，云原生数据仓库是未来的方向，早点摸透总没坏处。

培训期间的感受
培训本身安排得挺紧凑，先是理论讲解，再是上机实操。GCDW的架构——存算分离、FoundationDB做元数据管理、S3做持久化存储——之前多少了解一些，但听老师系统讲一遍之后，很多原来模糊的概念变得清晰了。培训期间也做了一些练习，但环境和材料都是准备好的，照着步骤走基本都能成。真正的问题，都是回到自己机器上部署的时候才出现的。

部署实战：从零到一的七十四小时
如果算总时间，可能也就两三天的工作量，但因为中间总是卡住，实际跨度拉长到了一周。下面记录的是我遇到的几类主要问题和解决思路，不是完整的操作手册，只是一些印象深刻的片段。

网络这一关，第一道坎就没过去
最先折腾的是虚拟机的网络。三台CentOS 7跑在VMware上，NAT模式。按照教程配置完IP和网关之后，从宿主机ping虚拟机能通，但虚拟机本身访问不了外网。检查了网卡配置、网关、DNS，都没问题。最后发现是VMware的NAT服务压根没启动。在Windows的服务列表里把VMware NAT Service启动之后，网络通了。后来回头看，这个问题其实特别基础，但当时确实卡了一阵子。教训是：别想当然地以为虚拟机网络就是通的，先确认最底层的服务是否在运行。

SSH连接不上，虚惊一场
网络通了之后，Xshell连不上22端口。排查思路其实比较直接：先看防火墙，再看sshd服务状态，最后看配置文件里有没有禁止root登录。关闭防火墙之后立刻就通了。

yum源失效，一上来就遇到
CentOS 7官方源已经停止维护了，这事我知道，但没想到影响这么大。连基础依赖都装不上，更别说后面的组件了。解决办法也算常规操作：换阿里云的源，清理缓存重新生成。步骤不复杂，但如果没有提前准备，临时去找解决方案还是会耽误时间。经历过这次之后，我给自己定了个规矩：以后不管装什么，先把软件源换成国内可用的版本。

FDB部署：RPM包名不一致导致失败
FoundationDB的部署用的是南大提供的自动化脚本。第一次执行失败，回滚信息只有一句"failed to install"，具体原因完全不知道。后来通过调整Ansible的日志级别，才看到报错是因为RPM包名和脚本里配置的文件名不一致。改了参数重新跑，顺利通过。这件事给我的感触是：自动化脚本确实省事，但出问题的时候你得有办法深入到它内部去排查，否则会被卡死。

MinIO启动：一个兼容性问题
MinIO的前台启动完全正常，但是systemd后台启动就超时。排查发现是service文件里有一行ProtectProc——这是CentOS 7的系统版本不支持的选项，注释掉就好了。这种问题属于"你不遇到就永远不会知道"的类型。没有特别的技巧，就是遇到了，看日志，然后解决。

demo.options：噩梦级别的配置文件
如果说前面那些问题还属于"常规排障"范畴，那GCDW安装阶段的demo.options配置就是真正的噩梦。前前后后改了不下十次。参数不能用引号包裹，等号两边不能有空格，dbaPwd要么说未知参数要么说必须二选一，最后只能用dbaUserPwdFile的方式。

GCDW_JAVA_HOME更折磨人。一开始报找不到JAVA_HOME，以为是路径问题，换了几个都无效。后来才发现是OpenJDK只装了JRE版本，bin/java根本不存在。装了完整的java-1.8.0-openjdk-devel之后才通过检查。
最无语的是安装完之后的目录路径。我到处找/opt/gcdw/gcluster，结果根本没这个目录。仔细排查才发现，多实例部署模式下，实际安装路径是/opt/192.168.100.100/gcluster这样的，每个节点以IP命名独立目录。这个设计在文档里只有一行注释，如果没有仔细看，很容易被误导。。

服务启动：最后的软链接问题
所有组件都装好了，gcadmin showcluster一看，只有第一个节点是OPEN，另外两个是CLOSE。登录到对应节点手动启动服务，又报了/bin/gcmonit.sh找不到。
查了一下脚本内容，发现gcluster_services里硬编码了$GCLUSTER_HOME/bin/gcmonit.sh，但实际文件在server/bin/下面。建了一个软链接，再启动就成功了。这个问题的本质是脚本路径和实际目录结构不一致。算不上什么技术难题，但如果没有定位到这一层，很容易被绕进去。

一点感想
一周时间，说长不长说短不短。回头翻看自己的笔记，从网络配置到GCDW启动，大大小小记录了二十多个问题。有些现在看起来很简单，当时却耗了不少时间。如果说这次部署让我学到了什么，大概有三点：
第一，文档是起点，不是终点。
培训发的文档很详细，但没有任何一份文档能够覆盖你实际环境中可能遇到的所有问题。操作系统差异、网络配置、软件版本、依赖包——任何一个变量变了，结果就可能不一样。所以看文档的时候要带着"这可能会出错"的预期，而不是"照着做就能成"的幻想。
第二，工具的本质是效率，不是万能药。
自动化脚本确实节省了大量重复劳动，但它也把真实的执行过程封装起来了。一旦出问题，你面对的是抽象的报错信息，根本不知道问题在哪一层。这时候就需要深入到工具的日志里、生成的临时文件里，甚至去看它调用的底层命令。工具是帮你的，不能完全依赖它。
第三，使用经验和部署经验是两回事。
这句话听起来像废话，但只有真正经历过的人才能理解。会写SQL、会调参数、会做查询优化，这些技能在部署面前几乎派不上用场。部署要求的是操作系统层面的理解、网络配置的熟练、排障思路的清晰，这些东西靠看书学不来，只能靠实战积累。

感谢
最后想说的是，这次培训收获很大。感谢南大通用的组织、老师们的专业讲解，还有培训群里一起讨论问题的同行们。很多时候自己卡了半天想不通的问题，在群里都能找到答案。未来工作中GCDW的应用会越来越多，这次攒下的经验和教训，应该能用得上。也希望这篇笔记能帮到其他还在摸索中的同行——不管你现在卡在哪一步，总会有办法过去的。