简介这是面向 GaussDB 100 数据库管理员与运维工程师的部署资源基于 EulerOS 20 SP8 64 位环境用于快速完成分布式数据库的安装、升级或版本验证可减少手动配置带来的时间消耗。压缩包体积约 7.39MB共 6 个文件由 4 个 Python 脚本、1 个 SHA256 校验文件和 1 个数据运行包组成。脚本覆盖安装、升级、公共函数库及 SSH 密钥处理能够自动完成环境检查、参数写入与解压校验配套的 SHA256 文件可帮助核验下载完整性防止安装过程中因数据损坏出现异常。包内另附 GaussDB 100 运行包及校验值用户参照脚本执行即可获得可运行的数据库实例适合测试环境快速搭建、生产部署前预研或个人学习。当前已有 1313 人学习对于需要接触欧拉系统下 GaussDB 的运维与开发人员而言是一份能直接上手的实用工具包脚本保留了自动化逻辑便于后续二次调整和复用。1. 装 GaussDB 100 为什么总在第一步翻车版本和系统匹配是头号杀手拿到GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz这个包时很多人的第一反应是解压、执行安装脚本、等着收工。但实际部署过的同事应该都有印象GaussDB 100 在欧拉 20 SP8 上的安装真正劝退人的不是数据库本身而是装之前没人提醒你的那些前置条件。网上能找到的教程一大半基于麒麟或者 CentOS 写的直接照抄到欧拉上轻则缺依赖库重则初始化实例时直接报错退出连日志都看得一头雾水。这一篇就是把我自己在一套欧拉 20 SP8 x86_64 环境上装 GaussDB 100 单机版的完整过程记录下来从系统检查、依赖安装、用户创建到解压、静默安装、实例初始化、连接验证再到装完起不来的几个典型现场。如果你正卡在“装上了但起不来”或者“编译依赖缺这缺那”的阶段这篇文章应该能让你少走两三个小时的弯路。适合的读者是需要在国产化环境里部署 GaussDB 100 的开发者或运维尤其是第一次接触这个数据库、对欧拉系统也不够熟的人。2. 环境准备欧拉 20 SP8 的依赖库、用户权限和内核参数一次讲清2.1 检查系统版本与基础依赖先确认你是欧拉而不是 CentOS 套壳很多部署翻车都是从“拿 CentOS 的套路硬套欧拉”开始的。欧拉 20 SP8 虽然是 RPM 系但软件源的包名、默认仓库配置和 CentOS 有明显差异。拿到服务器第一步不是急着解压数据库包而是先确认操作系统发行版、内核版本、Python 版本和 GCC 版本。GaussDB 100 1.0.1 这个版本对系统的要求比较明确欧拉 20 SP8、x86_64 架构、glibc 版本不能太低。如果系统是 CentOS 7 强行改 hostname 冒充欧拉后面动态库加载阶段大概率会出问题。我一般会先跑这么几行命令摸底cat /etc/openEuler-release uname -m python3 --version gcc --version yum list installed | grep -E libaio|libaio-devel|flex|bison第一行确认是不是欧拉 20 SP8第二行确认架构是 x86_64 而不是 aarch64第三行和第四行确认 Python 和编译链是否就位最后一行看数据库运行所需的动态库有没有装。注意GaussDB 100 1.0.1 的安装脚本对 Python 版本没有特别苛刻的要求但系统里必须得有 python3因为 install.py 默认就是用它来解释执行的。GCC 也一样即使你不打算从源码编译安装脚本在某些步骤里也会调用 gcc 做环境探测缺了直接报错。还有一个比较容易忽略的欧拉 20 SP8 的 yum 源默认可能没有启用。刚装好的最小化系统如果不先yum makecache装依赖的时候会出现找不到软件包的假象。我的习惯是装完系统先跑一遍yum makecache yum update -y再动手装数据库。这一步不算多余因为后续安装 libaio-devel 这类包时仓库元数据是旧的很容易触发 404 或者“No package available”。2.2 创建 gaussdba 用户与目录规划用 root 跑数据库是给自己埋雷GaussDB 100 安装规范里明确要求用专用用户运行不能是 root。这里不仅是权限安全问题更是实际踩出来的教训用 root 初始化实例后数据库生成的日志文件、控制文件属主全是 root后面你要是想切换到普通用户做备份或者运维会发现一堆文件无权访问改属主又是一串连锁操作。所以从一开始就别嫌麻烦老老实实先建用户。groupadd gaussdb useradd -g gaussdb -d /home/gaussdba -m -s /bin/bash gaussdba echo Gauss2024abc | passwd --stdin gaussdba参数不多但各有用处-g指定主组-d指定家目录-m强制创建家目录-s把登录 shell 设为 bash。密码这里建议至少 8 位且包含大小写字母和数字因为 GaussDB 100 的 SYS 用户初始密码在安装时也有类似的复杂度校验先养成习惯后面少踩一个坑。用户建好之后规划两个核心目录安装目录/opt/gaussdb和数据目录/gaussdb/data。mkdir -p /opt/gaussdb /gaussdb/data chown -R gaussdba:gaussdb /opt/gaussdb /gaussdb/data chmod -R 755 /opt/gaussdb安装目录放二进制文件数据目录放实例文件两者分开是数据库运维的通用做法。以后如果要迁移或者扩容只需要把数据目录整个带走不用动安装目录。权限上注意安装目录给 755数据目录建议 750 就行不用全开。有些教程图省事直接chmod -R 777这个习惯不好数据库目录权限太松会让其他系统用户也能读到实例文件这在生产环境是大忌。2.3 内核参数和 ulimitmax_map_count 与 nofile 决定数据库能跑多稳数据库类软件对内核参数和进程资源限制都很敏感GaussDB 100 也不例外。常见的部署手册里会要求调整三个地方/etc/sysctl.conf里的内核参数、/etc/security/limits.conf里的用户资源限制、以及关闭防火墙和 SELinux在测试环境可以省但生产环境至少要确认端口放通。cat /etc/sysctl.conf EOF vm.max_map_count 262144 net.core.somaxconn 2048 fs.file-max 1000000 net.ipv4.ip_local_port_range 9000 65500 EOF sysctl -p这几个参数里vm.max_map_count是 GaussDB 100 初始化实例时最容易踩的坑。数据库启动会创建大量内存映射区域如果这个值保持系统默认的 65530实例内存稍微给大一点就会报 mmap 失败。net.core.somaxconn影响的是高并发连接下的 listen 队列长度fs.file-max是系统级文件句柄上限net.ipv4.ip_local_port_range保证数据库监听端口之外的客户端连接有足够的本地端口可用。数值上我习惯直接给到上面这组比文档推荐值留了余量避免后面调优时反复改。limits.conf 这边给 gaussdba 用户单独配置cat /etc/security/limits.conf EOF gaussdba soft nofile 65536 gaussdba hard nofile 65536 gaussdba soft nproc 131072 gaussdba hard nproc 131072 EOFnofile 是文件描述符上限nproc 是进程数上限。数据库连接一多每个连接都会占文件描述符默认的 1024 肯定不够。这里强调一下limits.conf 改完需要重新登录 gaussdba 用户才生效ulimit -n验证一下看到 65536 才算是真的生效。如果看到还是 1024别急着怀疑配置错了先检查/etc/security/limits.d/下面有没有别的配置文件覆盖了默认值这是欧拉系统里很常见的“配了没生效”的原因。3. 解压安装tar 包拿到手正确姿势是分三步走3.1 解压与校验文件完整性md5sum 这一步别跳从网上下载的安装包尤其是数据库这种几百 MB 的二进制包传输过程中损坏的概率比你想象的高。我见过有人解压时报gzip: invalid compressed data第一反应是重新下载结果白折腾两小时后来发现是下载工具断点续传导致的文件尾部缺失。所以验证文件完整性不是强迫症是基本的部署素养。md5sum GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz tar -xzvf GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz -C /opt/gaussdbmd5sum 算出来的值要和发布方提供的校验码比对官网下载页面一般都会给。如果没给至少确认一下文件大小和页面标注一致再执行解压。解压时用-C /opt/gaussdb指定目标目录不要解压到/tmp再复制大文件在 /tmp 和 /opt 之间搬动既耗时间又可能触发权限问题。解压完成后/opt/gaussdb下会看到 install.py、admin、bin、cfg、lib、share 这样的标准目录结构。这里提醒一句解压完先别急着执行 install.py先把整个安装目录的属主改回 gaussdba。虽然压缩包里的文件权限是预设好的但如果你是用 root 解压的部分目录的属主会变成 root后面以 gaussdba 用户执行安装脚本时可能会因为写不进去某些目录而报错。chown -R gaussdba:gaussdb /opt/gaussdb3.2 用 install.py 做静默安装-U、-P、--data-dir 这几个参数怎么配GaussDB 100 的安装脚本是install.py它同时承担了“环境检查 软件安装 初始化实例”三件事。这也是为什么很多人第一次跑这个脚本会觉得它特别慢——它不是在解压文件而是在做完整的实例初始化。执行之前切到 gaussdba 用户然后跑su - gaussdba cd /opt/gaussdb python3 install.py -U gaussdba -P Sys2024abc --data-dir/gaussdb/data --charsetUTF8参数说明拆开讲-U指定运行数据库的操作系统用户这里必须和前面创建的用户一致-P是数据库超级管理员 SYS 的初始密码注意不是操作系统密码是数据库内部的密码复杂度要求至少 8 位且包含大写、小写和数字密码里尽量别用用户名本身--data-dir指定数据目录也就是实例文件存放的位置--charset指定数据库字符集常用的是 UTF8如果你的业务是老系统迁移且历史数据是 GBK 编码可以改成 GBK但这个参数启动后就不能再改了选之前想清楚。静默安装的成功标志是最后一行输出类似Install successfully的信息。这个过程里我们看不到进度条但可以通过另一个窗口实时跟踪日志来确认进度。日志文件一般在/opt/gaussdb/log下名字类似install_DATE.log。tail -f /opt/gaussdb/log/install_$(date %Y%m%d).log如果安装脚本在某个步骤卡住不动多半是前面的系统检查没过。比如 libaio 缺失时日志里会直接找不到libaio.so.1的报错内存不足时会提示Failed to allocate memory。我在实际部署中遇到最多的不是单机安装失败而是安装脚本在初始化实例阶段因为vm.max_map_count不够而中断。如果你按上一章的参数改了 sysctl.conf这一步基本不会出问题。3.3 安装后的标准目录结构bin、admin、cfg、data 各管什么安装完成后/opt/gaussdb和/gaussdb/data的结构大概是这样目录作用运维关注点/opt/gaussdb/bin存放 zsql、zctl.py 等可执行文件PATH 里加上它日常操作能少打很多绝对路径/opt/gaussdb/admin存放环境变量脚本、配置文件模板切换用户后先 source 这里的环境脚本/opt/gaussdb/cfg实例配置文件 zengine.ini 的模板目录真正生效的配置在数据目录下/opt/gaussdb/lib动态链接库报 lib 相关错误时先检查这里/gaussdb/data实例数据文件、日志、控制文件备份和迁移只需要关注这个目录这里有个细节安装脚本生成的zengine.ini不在/opt/gaussdb/cfg里而在数据目录/gaussdb/data/cfg下。很多人找半天配置文件找不到就是因为被模板目录带偏了。bin 目录下有zsql数据库命令行客户端和zctl.py实例启停管理工具这两个是后续所有运维操作的核心工具。admin 目录下的环境脚本通常是gs_profile.sh名字可能因为版本微调略有差异找到后 source 一下source /opt/gaussdb/admin/gs_profile.sh这个脚本会帮你设置好 PATH、LD_LIBRARY_PATH 这些环境变量。不 source 的话直接敲 zql 会提示 command not found并不是没装上。建议把这行写进 gaussdba 用户的~/.bashrc每次登录自动加载省得总是手动敲。4. 实例初始化与连接配置让数据库真正转起来4.1 第一次调整 zengine.ini端口、字符集和内存参数怎么取舍GaussDB 100 的实例参数集中在zengine.ini里。安装脚本已经生成了一个默认配置但默认值往往面向“能跑起来”而不是面向“你的业务场景”。装完之后第一件事不是急着连数据库而是先打开配置文件把几个关键参数改成符合当前机器配置的值。vim /gaussdb/data/cfg/zengine.ini重点关注这一段PORT 1888 LSNR_ADDR 0.0.0.0 DATA_BUFFER_SIZE 512M LOG_BUFFER_SIZE 128M TEMP_BUFFER_SIZE 256M MAX_CONNECTIONS 200 ARCHIVE_MODE OFFPORT是数据库监听端口默认 1888如果和其他服务冲突可以改但要同步修改客户端连接串端口号。LSNR_ADDR监听地址本机测试用127.0.0.1就够了需要远程访问再改成0.0.0.0。DATA_BUFFER_SIZE是数据缓冲区直接影响 SQL 查询走缓存的能力机器内存有余量就多给点。注意这里单位是 M别写2G这种格式有的版本不认。ARCHIVE_MODE默认是 OFF也就是非归档模式。测试环境可以不管但如果有“数据库坏了能恢复”的需求建议装完就把它改成 ON同时设置归档目录ARCHIVE_MODE ON DB_RECOVERY_FILE_DIR /gaussdb/archive改归档模式需要重启实例生效所以最好在第一次启动前就把这些参数定好避免后面来回折腾。内存相关参数的分配原则是总内存的一半给DATA_BUFFER_SIZE四分之一给TEMP_BUFFER_SIZELOG_BUFFER_SIZE给个 128M 到 256M 就够。别把内存全部分给数据库操作系统本身和备份工具都要留资源。4.2 启动实例zctl.py start 流程与日志关注点配置改完后启动实例是验证整个安装是否成功的关键一步。启动命令本身很简单难的是启动失败时怎么定位问题。cd /opt/gaussdb/bin python3 zctl.py start启动成功后会看到类似Start successfully的输出同时可以再确认一下实例状态python3 zctl.py status如果启动失败第一件事是看实例日志日志位置在数据目录下的log子目录tail -n 50 /gaussdb/data/log/alert.logalert.log是实例运行的主日志启动失败的原因基本都能在这里找到。常见的几类日志内容Can not get memory说明内存参数给得太高和系统实际可用内存不匹配Can not open shared object说明依赖库缺失Address already in use说明端口被占。日志是英文的但关键词都很短扫一眼就知道问题在哪一块。另外要强调一点启动过程不要用 root 执行。zctl.py 会检测当前用户是不是安装时指定的用户用户不对会直接拒绝执行。如果你发现zctl.py status显示实例状态异常先别急着重启看看是不是数据目录权限被改动过。数据库在运行中会持续写日志和警告文件目录属主不对会导致写入失败进而引发实例自动退出这种问题在日志里往往不明显但ls -l /gaussdb/data一眼就能看出来。4.3 客户端连接与免密配置zsql 和 alias 的小技巧实例启动后用数据库自带的命令行客户端 zsql 来验证连接zsql sys/Sys2024abc127.0.0.1:1888注意这个连接串的格式是三段式用户名/密码IP:端口。首次连接建议按这个写法因为最直观出问题也好排查。连接成功后会看到 SQL 提示符这代表数据库实例真正能对外服务了。日常维护中每次敲那么长一串连接串很烦我习惯在 gaussdba 用户的~/.bashrc里加个 aliasalias zsql_connzsql sys/Sys2024abc127.0.0.1:1888 source ~/.bashrc以后敲zsql_conn就能直接进数据库。这里不推荐在命令行里长期明文暴露密码内网测试环境图方便可以生产环境建议用 zsql 的免密配置功能把用户名密码写到~/.zsql/config之类的配置文件里。不过每个小版本配置文件路径略有差异最稳的做法是用环境变量ZSQL_OPTS或直接看客户端 help 输出。5. GaussDB 100 安装避坑装完起不来的五个典型现场5.1 报错 cannot open shared object filelibaio 缺失还是软链失效现象执行 install.py 或启动实例时报错error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory。原因数据库在启动时要调用异步 I/O 库libaio.so.1这个动态库属于libaio包。最小化安装的欧拉系统默认不会带这个库而 GaussDB 100 的安装脚本不会自动帮你装系统依赖包所以这一步必须手动完成。解决yum install -y libaio libaio-devel ldconfig装完后最好确认一下动态库链接是否存在ls -l /usr/lib64/libaio.so.1如果文件存在但还是报错检查一下是不是 32 位和 64 位库混了。数据库是 64 位版本系统里必须存在 64 位的 libaio。某些服务器同时装了 32 位兼容库gcc 链接时解析到了错误路径也会出现类似问题。5.2 初始化实例时内存分配失败mmap 上限和 DATA_BUFFER_SIZE 打架现象安装过程走到初始化实例步骤日志里出现Failed to allocate memory或mmap: Cannot allocate memory然后安装脚本退出。原因两个因素叠加导致。一是vm.max_map_count太小数据库创建内存映射区域时撞到了上限二是zengine.ini里DATA_BUFFER_SIZE给的内存超过了系统实际可用内存。多数情况下前者是主因因为欧拉 20 SP8 默认的max_map_count是 65530GaussDB 100 启动单实例时映射数量很容易触顶。解决先把 sysctl.conf 里的vm.max_map_count调到 262144 以上并sysctl -p生效同时用free -g评估一下服务器可用内存实例总内存DATA_BUFFER_SIZETEMP_BUFFER_SIZELOG_BUFFER_SIZE控制在物理内存的 60% 以内。改完参数记得重启实例内存参数在实例运行中是改不了、也不建议动态调整的。5.3 端口被占用1888 不是你的专属数字现象启动实例时日志报Address already in use或者zctl.py status显示实例状态异常但 zsql 连接时提示 connection refused。原因1888 这个端口不是 GaussDB 100 独有的很多中间件和开发工具也爱用 1888。服务器上如果先装了其他监听 1888 的程序数据库启动时绑定端口就会失败。解决ss -lntp | grep 1888先看端口被谁占了。如果是无关程序改数据库端口是最省事的办法把zengine.ini的PORT改成比如 3888重启实例连接串同步改。如果是本机其他实例的端口那就规划好端口段避免冲突。这个问题的隐蔽性在于操作系统不会报错只有数据库日志里有记录等你去连数据库时才发现连不上。5.4 权限错乱chown 漏掉某个目录引发的连环报错现象实例启动后运行几分钟自动退出alert.log 里出现Permission denied或者备份工具执行时报无法创建文件但检查主目录权限时又看不出明显问题。原因安装过程中用 root 执行了解压或建目录操作但没有把新建目录的属主完整地递给 gaussdba 用户。典型场景是/gaussdb/archive归档目录是后来手工创建的创建时机不对导致属主是 root数据库进程写入归档日志时被权限拦截。数据库主进程还在运行但写不了归档日志最终触发实例自我保护退出。解决把数据目录及其子目录整体重新授权chown -R gaussdba:gaussdb /gaussdb chown -R gaussdba:gaussdb /opt/gaussdb这里有个习惯值得养成所有和数据库相关的目录无论创建时间先后统一在数据库启动前执行一遍 chown。不要纠结哪个目录是 root 创建的全部统一属主是最省心也最不容易漏的做法。5.5 中文乱码和时区错乱LANG 和 TZ 环境变量的教训现象zsql 查询结果里的中文显示成乱码或者数据库记录的时间与操作系统本地时间差了 8 个小时。原因数据库字符集与客户端终端字符集不一致。安装时指定了 UTF8但操作系统的 locale 是 POSIX 或 C终端没有吃透 UTF8 编码。时区问题则是数据库实例时区继承自启动进程的环境变量而zctl.py start如果是在一个时区未设置的环境里执行的实例就会按 UTC 记录时间。解决把 gaussdba 用户的环境变量固定下来在~/.bashrc里明确写入export LANGen_US.UTF-8 export TZAsia/Shanghai改完后重新登录 gaussdba 用户先zsql连接并执行SELECT SYSDATE FROM DUAL;确认时间正确再插入一条中文数据验证字符集。这个问题不算致命但一旦业务方发现数据时间不对追溯起来会非常痛苦因为它不会直接报错所有日志看起来都正常。6. 装完怎么验证一条 SQL 跑通数据库日子才算开始6.1 用 zsql 跑通建表、插入和查询实例状态正常只是第一步数据库能写入、能读取、能查询才是真的跑通。我的验证习惯是一套固定的三段式操作CREATE TABLE student (id NUMBER PRIMARY KEY, name VARCHAR2(64)); INSERT INTO student VALUES (1, 张三); SELECT * FROM student;这三条语句覆盖了表空间分配、数据写入、索引创建和 SQL 解析执行任何一个环节有问题都会在这里暴露。如果SELECT能返回1 张三至少说明存储引擎和 SQL 引擎都在正常工作。更进一步可以验证连接并发for i in $(seq 1 10); do zsql sys/Sys2024abc127.0.0.1:1888 -c SELECT COUNT(*) FROM student; done wait多条连接同时执行查询看是否有锁等待或连接超时。这一步在测试环境跑一次花不了两分钟但对发现隐藏的连接数限制问题很有帮助。6.2 重启场景验证kill 进程后能被守护机制拉起吗数据库跑通后你还要确认一件事实例被异常 kill 掉后能不能靠守护机制自动恢复。GaussDB 100 单机版的进程是相互守护的直接 kill 掉主进程守护进程会自动把它拉起来。ps -ef | grep zengine | grep -v grep kill -9 zengine主进程PID sleep 10 python3 zctl.py status十秒之后再看实例状态如果自动恢复了说明进程守护正常如果状态是异常说明要么是实例配置文件有问题要么是权限问题导致守护进程无法完成重启。这个验证的意义在于生产环境里数据库被 OOM killer 杀掉是常态如果守护机制本身有问题你再怎么优化 SQL 都白搭。6.3 备份与恢复的快速自检最后一项验证是备份能否成功。归档模式下直接用 zsql 触发一次全量备份BACKUP DATABASE;备份成功的标志是返回Backup successfully或者类似信息同时/gaussdb/archive目录下出现新的备份文件。轻量一点的验证是执行SPOOL导出把刚才建的 student 表导出成文件SPOOL /tmp/student_bak.sql SELECT * FROM student; SPOOL OFF导出成功后文件里应该有完整的 INSERT 语句或查询结果这至少证明数据能落盘、能读出来。从那以后我每次装完 GaussDB 100都会强制走一遍这三步连接执行三元组、kill 进程验证自动拉起、备份导出确认落盘。三分钟的事换来的是整个环境能不能用的明确结论。希望帮到你。本文还有配套的精品资源点击获取