简介这是一份华为GaussDB 100 1.0.1版本的64位数据库安装压缩包面向需要在EulerOS 20SP8环境部署分布式数据库的开发者、运维人员及数据库学习者用于解决高性能、高可用且可横向扩展的数据存储与处理需求。该系列具备分布式架构、高可用性、强一致性、高性能与安全可靠等核心特性适合中大规模业务场景和数据分析类负载。压缩包内共6个文件约7.39MB其中包含4个Python脚本如install.py、upgrade.py等便于自动化安装和升级另有SHA256校验文件确保完整性核心数据库tar.gz包用于实际安装部署。已有1313人学习/下载资源还提供了sshexkey.py等辅助脚本帮助用户完成环境配置与密钥处理整体适合需要快速上手GaussDB 100或进行本地实验的读者可在实践中深入理解安装流程与基础运维并借此了解华为分布式数据库的部署要点。1. GaussDB 100 1.0.1 离线包不联网也能装的企业级单机 OLTP 库GaussDB 100 1.0.1-DATABASE-EULER20SP8-64bit.tar.gz 这个安装包解决的是内网环境里最尴尬的问题机器上不了外网、没有可用的 yum 源、还要快速支起一个能跑业务 SQL 的关系型数据库。它把服务端 zengine、客户端 zsql、管理脚本 zctl、导入导出工具 exp/imp 以及 JDBC 驱动打进了同一个包目标系统就是文件名里的 EULER20SP8 对应的 64 位环境。适用人群很明确做国产化替代验证、手里只有离线 CentOS/Euler 系服务器、想用一套 Oracle 风格语法库做单机 OLTP 业务的开发者或运维。它不适合当分布式集群用定位就是单机或主备场景但如果你要的就是「解压、初始化、跑起来」这个包几乎是同类里最省事的路线。2. 装之前的活先干完校验、账号、内核参数三件事安装数据库最忌讳拿到包就解压执行GaussDB 100 对运行环境有硬性要求前置检查没做后面报错全是玄学现场。我一般会把安装前的工作拆成三块包本身对不对、以什么身份装、操作系统给不给面子。这三件事花不了五分钟但能挡掉后面八成的问题。2.1 先校 md5 再解压文件不对一切都是白干内网环境下载大文件最容易出半截包tar 包如果在中途断掉解压的时候不会立刻报错而是会在某个深层文件上突然失败那会儿你根本分不清是包的问题还是环境的问题。所以我的习惯是第一步永远先校验。# 先算校验值和发布页给出的 md5 比对不一致直接重下 md5sum GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz # 不解压先看包内容确认内层结构完整中途报错说明包损坏 tar -tzf GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz | head -40 # 确认完整后解压到独立目录不要直接解压在 root 家目录 tar -xzf GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz -C /opt/gaussdb_pkg第一行是验身份md5 比对通过才谈后续第二行tar -tzf不解压直接列目录树能提前发现坏块head -40主要是看典型结构——正常情况下你会看到install.py、bin/zengine、bin/zsql、tools/exp、tools/imp、jdbc目录和文档目录看到这些才说明包是完整的。第三行解压到/opt/gaussdb_pkg是为了把安装物和后续数据目录分开后面维护起来路径清爽。提示校验值对不上别硬装。内网传包经过多层中转校验失败大概率是传输损坏直接重新拉一次别赌。2.2 专用账号和目录拒绝 root 裸跑GaussDB 100 的初始化脚本和 zengine 进程都明确要求不能以 root 身份运行。这不仅是习惯问题是安全底线数据库进程一旦以 root 跑SQL 层面的漏洞被利用就等于把整台机器交出去了。所以安装前必须建一个专用账号。# 建组、建用户用户只属于 gaussdba 组 groupadd gaussdba useradd -g gaussdba -d /home/gaussdba -m gaussdba # 程序、数据、备份三个目录分开后续备份和升级都好处理 mkdir -p /opt/gaussdb/app /opt/gaussdb/data /opt/gaussdb/backup chown -R gaussdba:gaussdba /opt/gaussdb # 确认属主别急着往下走 ls -ld /opt/gaussdb这里的目录规划是有讲究的app放解压出来的程序文件data放数据文件和日志backup放备份产物。三块分开之后做冷备只需要打包data升级只需要换app互不干扰。chown -R gaussdba:gaussdba是把整个目录树交给专用账号后面所有操作都切到这个用户下做。常见翻车点是有人用 root 先执行了install.py的一部分再切到 gaussdba 用户重跑结果半成品目录权限全乱这时候只能清空重来。2.3 内核参数与依赖库装之前把环境体检一遍数据库对操作系统的信号量、共享内存、文件句柄限制极其敏感。GaussDB 100 初始化脚本里自带检查项但与其等它报错不如先手动看一遍尤其是kernel.sem十个环境里有六个会挂在这里。# 查看当前信号量限制四个值是 SEMMSL/SEMMNS/SEMOPM/SEMMNI cat /proc/sys/kernel/sem # 临时调大重启后失效 sysctl -w kernel.sem250 256000 100 1024 # 写入配置持久化重启服务器后依然生效 echo kernel.sem250 256000 100 1024 /etc/sysctl.conf # 检查 zengine 的动态库依赖是否有缺失输出 not found 就是要补库 ldd /opt/gaussdb_pkg/bin/zengine | grep not found || echo deps ok # 顺手确认文件句柄上限太小会莫名其妙断连接 ulimit -n四个信号量参数的含义分别是SEMMSL 每组信号量最大数量、SEMMNS 系统总信号量数、SEMOPM 每次操作最大信号量数、SEMMNI 系统允许的信号量组数量。数据库进程按连接和后台线程申请信号量默认的32000总容量在并发上来之后会直接触顶初始化或启动时报check the OS configuration基本就是它。ldd检查如果出现not found常见缺的是libaio、libnuma、libstdc离线环境没有 yum 源就找对应版本的 rpm 包本地安装硬跑的结果是进程起来就崩。3. 初始化、启停与首次登录从安装包到能用前置检查做完接下来就是把安装包变成实例的过程。GaussDB 100 的初始化逻辑和 Oracle 类似一条命令做数据字典初始化、生成配置文件、拉起进程。但这条命令的参数选择会直接影响后续能不能连、能不能被远程访问所以值得逐项说清楚。3.1 install.py 初始化数据目录、端口、监听地址一次定死切到 gaussdba 用户之后用包内的install.py做初始化。这里的关键是-D、-P、-L三个参数它们决定数据放哪、端口是多少、允许谁连进来。# 切换到专用账号不要在 root 下执行 su - gaussdba # 进入解压目录 cd /opt/gaussdb_pkg # -D 指定数据目录-P 指定数据端口-L 指定监听地址 # 默认端口 1888如果被占就换高位端口 python install.py -D /opt/gaussdb/data -P 1888 -L 127.0.0.1-D指定数据目录后zengine 会把控制文件、日志、数据字典全部写在这里后续zsql连接和zctl启停都依赖这个目录。-P 1888是数据端口GaussDB 100 的惯例是 1888但如果你机器上已经有别的服务占了这个端口初始化不会立刻报错启动时才报bind port failed所以提前netstat -tlnp | grep 1888看一眼值得。-L 127.0.0.1表示只允许本机连接这是最安全的配置如果后续要接应用服务器初始化时就改成应用网段 IP或者初始化后改配置文件里的监听参数再重启。install.py的精确参数名在不同小版本里略有差异拿不准就先跑python install.py --help对照一下别照抄网上其他版本的命令硬上。初始化成功的标志是最后打印出实例信息并且-D目录下出现zengine.ini配置文件和log子目录。注意初始化失败后数据目录里会留下半成品文件。重跑之前把-D目录清空再执行直接覆盖跑容易出现权限和残留配置的叠加问题。3.2 zctl 启停和状态检查启动不是一条命令的事GaussDB 100 的启停统一走zctl.py它负责拉起 zengine 后台进程、做恢复、注册实例。很多新手以为启动就是进程起来但数据库启动有一个 redo 恢复过程命令返回了不等于能连。# 启动实例zctl 会拉起 zengine 并等待恢复完成 python /opt/gaussdb/app/bin/zctl.py -t start # 查看状态确认实例已注册、端口在监听 python /opt/gaussdb/app/bin/zctl.py -t status # 正常关闭会先刷脏数据再归档不要用 kill -9 python /opt/gaussdb/app/bin/zctl.py -t stopzctl.py -t start会把 zengine 作为后台进程拉起然后进入恢复阶段前一次异常退出留下的 redo 日志会被重放数据量大的实例可能要好几十秒到几分钟。这时候status里如果还在恢复中就继续等别反复 start。stop同理正常停止会走完整的刷脏和归档流程强杀进程虽然也能停但下次启动的恢复时间会成倍增加。日志是排障的第一现场位置在-D目录下的log/run/文件名类似zengine_*.log启动报错、连接拒绝、恢复进度都在这里。任何启动异常先看这个日志再看配置比瞎猜强得多。3.3 首次登录与改密sys 账号和默认密码初始化完成后用包内自带的zsql客户端登录。GaussDB 100 的超级管理员是sys初始密码为change_on_install语法上非常接近 Oracle 的 sqlplus。# 登录本机实例格式是 用户/密码IP:端口 zsql sys/change_on_install127.0.0.1:1888 # 登录成功后立刻改密默认密码必须换掉 ALTER USER sys IDENTIFIED BY NewPass#2026;zsql默认在安装包的bin目录下把它加进 PATH 或者用全路径执行都行。连接串格式sys/密码IP:端口里的 IP 和端口必须和初始化时的-L、-P一致否则就会connection refused。改密语句执行完就生效别等下次重启。部分安全加固版本会在日志里给出首次登录的临时密码规则如果change_on_install登录失败去log/run/下翻一下初始化日志里面通常有提示。4. 安装与启动常见问题五个高频坑的现场记录这一章全是现场踩过的坑按「现象 → 原因 → 解决」的格式记录每一条都能对上号。遇到类似报错的时候直接对照这里处理比翻文档快。4.1 初始化秒退报错停在 OS parameter check现象执行install.py一两秒就退出终端提示check the OS configuration: kernel.sem之类的参数不通过有时候还附带shared memory字样。原因操作系统信号量参数太低。GaussDB 100 初始化时会动态申请信号量集做资源管理默认内核参数在低配云主机或精简系统上经常不够。解决按 2.3 节的命令先把kernel.sem调到250 256000 100 1024并写入/etc/sysctl.conf持久化。调完不用重启sysctl -p重载配置后重新跑初始化一次就过。4.2 用 root 解压和初始化后面所有目录权限错乱现象初始化过程部分成功但启动时 zengine 报权限类错误或者data目录下的文件属主混杂 root 和 gaussdba删也删不掉、改也改不了。原因install.py在 root 下执行时创建了一批 root 属主的文件之后切到 gaussdba 用户再操作进程没有写权限启动直接失败。解决把整个安装目录和数据目录全部归回 gaussdbachown -R gaussdba:gaussdba /opt/gaussdb_pkg /opt/gaussdb/data然后重新执行初始化。如果数据目录已经写入了半成品先清空再重来。4.3 启动报 bind port failed端口被占现象zctl.py -t start执行后日志里出现bind port failed或address already in use实例反复拉起又退出。原因初始化指定的-P 1888端口已经被其他进程占用可能是另一个数据库实例也可能是业务服务。解决先netstat -tlnp | grep 1888确认占用方要么停掉对方要么换端口。换端口要同步改两处数据目录下zengine.ini里的监听端口参数以及后续所有zsql、JDBC 连接串里的端口号。4.4 本机能连、远程连不上连接请求直接超时现象服务器上zsql本机登录正常但从应用服务器或另一台机器连接报connection timed out或no route to host。原因初始化时-L指定了127.0.0.1zengine 只监听回环地址外部网络根本到不了这个端口另一种可能是系统防火墙没有放行。解决检查zengine.ini里的监听地址改成应用网段 IP 或0.0.0.0后重启实例同时确认防火墙规则放行对应端口firewall-cmd --add-port1888/tcp --permanent firewall-cmd --reload云主机还要检查安全组规则。4.5 启动后长时间处于恢复状态像卡死一样现象zctl.py -t start返回了但status一直显示恢复中zsql连接报instance is starting等几分钟还是这样。原因上一次停库是强杀进程脏页没有刷盘redo 日志累积需要重放或者磁盘 IO 性能太差恢复速度被拖慢。解决先看log/run/下的日志文件体积确认恢复进度。多数情况下只需要耐心等待不要反复执行 start。恢复完成后手动做一次正常 stop 再 start确认后续启动时间回归正常。如果每次启动都异常慢检查数据盘是不是网络盘或共享存储本地 SSD 的恢复速度要快一个数量级。5. 跑通业务闭环建表空间、导入导出与 JDBC 连接装起来只是第一步真正让库「能用」得跑通一条完整链路建表空间、建用户建表、数据导进导出、应用接进来。GaussDB 100 的语法风格贴近 Oracle做存量迁移时有天然优势这一章把四个动作一次走完。5.1 建表空间、用户和测试表Oracle 风格语法先在 sys 下建一个独立的表空间和业务用户避免业务对象全堆在系统表空间里后续维护和备份才能分得清。-- 建业务表空间数据文件放数据目录下允许自动扩展 CREATE TABLESPACE tbs_app DATAFILE /opt/gaussdb/data/tbs_app.dbf SIZE 4G AUTOEXTEND ON NEXT 128M MAXSIZE 32G; -- 建业务用户默认表空间指向业务表空间 CREATE USER app IDENTIFIED BY App#2026 DEFAULT TABLESPACE tbs_app; -- 授权CONNECT 是登录权限RESOURCE 是建表权限 GRANT CONNECT, RESOURCE TO app;SIZE 4G指定初始大小AUTOEXTEND ON NEXT 128M是每次自动扩 128MMAXSIZE 32G是上限。这三个参数是线上环境的高频配置扩得太小会导致频繁等待设成NEXT 128M能减少分配次数。建完表空间和用户后切到 app 用户建一张测试表-- 切到业务用户 CONNECT app/App#2026127.0.0.1:1888; -- 建订单表语法和 Oracle 高度一致 CREATE TABLE t_order ( id NUMBER PRIMARY KEY, uid NUMBER NOT NULL, amount NUMBER(18,2), crt_time DATE DEFAULT SYSDATE );NUMBER(18,2)是 18 位精度带 2 位小数金额场景够用DEFAULT SYSDATE让插入时自动打时间戳。这张表建出来一个最简业务闭环就通了。5.2 exp/imp 逻辑导出导入小库迁移够用GaussDB 100 自带exp和imp两个逻辑备份工具语法同样贴近 Oracle。中小数据量场景用它做迁移前置、临时导出都很方便。# 导出单张表文件落到本地 exp app/App#2026127.0.0.1:1888 \ file/home/gaussdba/app.dmp \ tablest_order # 导入到目标库fully 表示按文件内容整体导入 imp app/App#2026127.0.0.1:1888 \ file/home/gaussdba/app.dmp \ fully导出参数里tablest_order指定表级导出去掉就是全库导出file指定导出的 dmp 文件路径注意目录要有写权限。imp侧fully是典型恢复用法目标库里同名对象已存在时会报错或覆盖迁移前先确认目标库是干净的。这套逻辑工具对大库不友好几百 GB 以上的数据量建议走物理备份逻辑导出会慢到怀疑人生。5.3 应用接入JDBC 驱动与连接串包内的 jdbc 目录里带驱动 jar接入 Java 应用时直接引用连接串前缀是jdbc:gaussdb://和 PostgreSQL 系风格不同别混。// 驱动加载jar 从安装包 jdbc 目录获取 Class.forName(com.gaussdb.jdbc.Driver); // 连接串jdbc:gaussdb://IP:端口/库名 String url jdbc:gaussdb://127.0.0.1:1888/edb; String user app; String pass App#2026; Connection conn DriverManager.getConnection(url, user, pass);连接串里的/edb对应逻辑库名新增业务库时在初始化创建的库名下规划即可。JDBC 连接参数里建议加connectTimeout5000和socketTimeout300000前者避免应用在数据库不可达时长时间卡死后者避免长事务被网络异常静默掐断。驱动 jar 版本要和服务端大版本匹配1.0.1 的实例就别拿其他大版本的驱动硬接兼容性上容易翻车。6. 把部署固化一条命令装库再演练一次恢复环境装多了之后我习惯把整个流程固化成脚本新机器拿到手跑一遍就出实例。顺带把恢复演练也固化进去因为没有任何备份是「备份了就一定有效」只有真正恢复过一次的备份才算数。#!/bin/bash # 一键部署 GaussDB 100重复执行可复现 set -e PKG/root/GaussDB_100_1.0.1-DATABASE-EULER20SP8-64bit.tar.gz DATADIR/opt/gaussdb/data PORT1888 # 1. 建用户、建目录 id gaussdba /dev/null 21 || { groupadd gaussdba useradd -g gaussdba -d /home/gaussdba -m gaussdba } mkdir -p /opt/gaussdb/app /opt/gaussdb/backup $DATADIR # 2. 调内核信号量 sysctl -w kernel.sem250 256000 100 1024 /dev/null grep -q kernel.sem250 256000 100 1024 /etc/sysctl.conf || \ echo kernel.sem250 256000 100 1024 /etc/sysctl.conf # 3. 解压并归权 tar -xzf $PKG -C /opt/gaussdb/app chown -R gaussdba:gaussdba /opt/gaussdb # 4. 初始化 su - gaussdba -c cd /opt/gaussdb/app python install.py -D $DATADIR -P $PORT -L 127.0.0.1 # 5. 启动并确认状态 su - gaussdba -c python /opt/gaussdb/app/bin/zctl.py -t start sleep 3 su - gaussdba -c python /opt/gaussdb/app/bin/zctl.py -t status echo deploy done, port $PORT脚本里每步都是前面章节做过的事set -e保证任一步失败就停不会带着半成品状态往下跑。真正值钱的是后面的恢复演练# 冷备演练停库、打包数据目录、起库 su - gaussdba -c python /opt/gaussdb/app/bin/zctl.py -t stop tar -czf /opt/gaussdb/backup/full_$(date %F).tar.gz /opt/gaussdb/data # 恢复演练把备份解到临时目录改配置指向新目录后起库 mkdir -p /opt/gaussdb/data_restore tar -xzf /opt/gaussdb/backup/full_$(date %F).tar.gz -C /opt/gaussdb/data_restore chown -R gaussdba:gaussdba /opt/gaussdb/data_restore恢复演练里最关键的动作是确认备份解压后的数据目录能否独立拉起实例而不是只验备份文件存在。每次演练要记下两点恢复后的实例能否正常zsql登录、能否查到演练前写入的标记表数据。从那以后我每接手一个新环境第一件事就是跑一遍部署脚本再强制做一次冷备恢复演练确认数据和日志都正常才敢往上迁业务。这个流程不复杂但能把「装好了」变成「确定能用了」。希望帮到你。本文还有配套的精品资源点击获取