企业官网建设流程全解析

1. 安装前的准备：先把环境和“坑位”都摸清楚

Vastbase G100 这类企业级关系型数据库，说白了一套安装流程走下来，最花时间的往往不是敲命令那几分钟，而是前期那些看着不起眼的环境检查。我最早一次装的时候，就是觉得“反正有脚本，一路下一步就行”，结果卡在权限、内核参数和字符集上，来回折腾了大半天。这一节我先把最容易出问题的几个点列出来，你在动手之前花二十分钟过一遍，后面能省下至少两小时。

1.1 硬件与操作系统要求

先明确一下最低配置。其实网上资料都有，但实际部署时，很多环境是虚拟机或者容器，规格卡得很紧张。Vastbase G100 官方文档写的是至少 2 核 CPU、4GB 内存、磁盘 50GB 以上。这个配置能装能跑，但你做完初始化、导入一批测试数据后，就会明显感觉到卡顿。我的建议是：如果只是学习验证，4核8GB是最舒服的；如果是要模拟生产压力测试，至少 8 核 16GB。磁盘方面，数据库数据目录和日志目录最好分开挂载，别都塞在根分区。

操作系统这块，常见支持的是 openEuler、CentOS 7/8、麒麟等基于 Linux 的发行版。我用的是 CentOS 7.9 的兼容环境，整体流程走下来比较顺畅。有一点必须提前确认：内核版本。Vastbase G100 对内核有最低版本要求，一般是 x86_64 架构下 3.10 以上，但如果你用的是带特殊安全加固的内核，可能会出现未知的系统调用问题，建议先用系统默认内核跑通安装流程，再做加固调整。

1.2 创建专用用户与目录规划

数据库服务绝对不能直接用 root 跑，这是行业常识。安装 Vastbase G100 前，需要创建专用的操作系统用户，官方一般建议创建名为vastbase或vb的用户，但这看个人习惯，我用的用户名是vbuser，只要保证安装和后续运维都用这个用户就行。

创建用户和用户组：

groupadd -g 1001 vbuser useradd -u 1001 -g vbuser -m -d /home/vbuser -s /bin/bash vbuser

规划目录时，我习惯把安装目录、数据目录、归档目录分开。比如：

• /opt/vastbase：软件安装目录
• /data/vastbase/data：数据目录
• /data/vastbase/archive：归档日志目录
• /data/vastbase/backup：备份目录

这样分开的好处很明显，数据目录单独一个挂载点，后续做扩容、迁移、备份，都不会影响软件目录。而且如果系统盘坏了，数据盘还能保命。创建好目录后，把所有权交给vbuser：

mkdir -p /data/vastbase/{data,archive,backup} chown -R vbuser:vbuser /data/vastbase

1.3 内核参数与资源限制调整

这一步是最容易被忽略的，但恰恰是数据库运行稳定性的根基。Vastbase G100 基于共享内存和多进程架构，对信号量、共享内存上限、文件句柄数量都有要求。如果不开调优，安装过程可能没问题，但并发一上来就会出现 “could not resize shared memory” 或者无法创建新进程的报错。

编辑/etc/sysctl.conf，追加以下配置：

kernel.sem = 4096 32000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 17179869184 kernel.shmmni = 4096 fs.aio-max-nr = 1048576 fs.file-max = 6815744 net.core.somaxconn = 65535 net.ipv4.ip_local_port_range = 9000 65535

注意shmmax的单位是字节，上面这个值是 16GB，如果机器物理内存只有 8GB，这个值建议改成8589934592（8GB），否则系统会报Invalid argument。比较保守的算法是把物理内存的 70%-80% 分配给共享内存。

改完之后执行：

sysctl -p

接着修改vbuser的资源限制。编辑/etc/security/limits.conf：

vbuser soft nofile 65536 vbuser hard nofile 65536 vbuser soft nproc 65536 vbuser hard nproc 65536 vbuser soft stack unlimited vbuser hard stack unlimited

这里特别提醒一下：nproc的 soft/hard 上限经常被改错，你要检查一下/etc/security/limits.d/下有没有更高优先级的配置文件，比如20-nproc.conf，如果里面有* - nproc 4096这种，会覆盖 limits.conf 里的设置。你需要要么修改那个文件，要么把对应用户的配置写进去。

1.4 字符集与语言环境

Vastbase G100 默认字符集建议使用UTF-8，如果操作系统是英文环境但有中文数据需求，最好在安装前把 locale 设为en_US.UTF-8或zh_CN.UTF-8。有次我在一个只有POSIXlocale 的极简系统上执行初始化，结果数据模板报编码错误。最简单的方法：

localedef -i en_US -f UTF-8 en_US.UTF-8 export LC_ALL=en_US.UTF-8 export LANG=en_US.UTF-8

确保/etc/locale.conf也写入了对应配置，然后 source 一下环境变量。

2. 安装包获取与一键脚本的核心逻辑

Vastbase G100 的安装包一般是一个压缩包，里面有安装脚本、安装介质、校验文件等。这一节我讲一下安装脚本的执行流程，以及它背后到底做了什么，这样你在遇到报错时不会一头雾水。

2.1 安装包解压与目录结构

拿到安装包后，比如vastbase_installer_2.2.tar.gz，先解压到/opt下。解压后的目录结构大概是这样：

base_install/ ├── install.sh ├── bin/ ├── lib/ ├── share/ ├── etc/ ├── initdb.sh └── verification.properties

其中install.sh是一键安装脚本，initdb.sh是初始化独立脚本，verification.properties存放了校验配置。官方手册会让直接执行./install.sh，但我建议先看一下脚本内容，尤其是在生产环境，至少要明白它会往哪些路径写文件。用less install.sh浏览脚本，你会发现核心步骤其实就是：解压介质到目标目录、复制配置文件、设置环境变量、创建数据目录骨架。

2.2 执行安装脚本时常用的参数

直接跑./install.sh -h能看到帮助信息。关键参数包括：

• -d：指定安装目录
• -D：指定数据目录，注意大小写区分
• -U：指定操作系统用户
• -g：指定用户组
• -p：设置数据库超级用户密码
• --locale：指定初始化字符集

一个例子：

./install.sh -d /opt/vastbase -D /data/vastbase/data -U vbuser -g vbuser -p 'YourPass123' --locale=zh_CN.UTF-8

执行前确认脚本有执行权限，如果没有就chmod +x install.sh。另外，必须在vbuser用户下执行，而不是 root。如果你用 root 执行，脚本会直接拒绝，因为数据库进程禁止以 root 启动。

2.3 一键安装脚本执行时，我遇到的第一个坎：磁盘空间误判

有一次执行到一半，脚本报 “insufficient disk space for installation”。我明明用df -h看到/opt和/data都还有 30GB 以上空间，怎么会不够？后来发现是脚本里的一个 bug（也可能是有意设计）：它检查的是临时目录/tmp的可用空间，而我的/tmp挂载在一个只有 1GB 的小分区上，解压和大文件复制把临时空间撑爆了。

解决方案很简单：把临时目录指到大分区再执行：

mkdir -p /data/vastbase/tmp export TMPDIR=/data/vastbase/tmp ./install.sh ...

如果你的系统/tmp空间足够，一般不会遇到这个问题。但提前加这一步也不亏，反正不影响正常安装。

2.4 安装后环境变量的设置

安装完成后，脚本会自动生成一个环境变量文件，一般位于安装目录下的etc/env.sh或~/.vastbaserc。你需要把它 source 到当前 shell，并写入~/.bash_profile，否则下次登录时找不到vsql、vb_ctl这些命令。

source /opt/vastbase/etc/env.sh echo 'source /opt/vastbase/etc/env.sh' >> ~/.bash_profile

如果安装后立即执行vsql --version提示找不到命令，九成是环境变量没生效。这不算 bug，纯粹是 Linux 会话隔离导致的环境变量未导出。

3. 初始化数据库与日常启停操作

安装完成了，但数据库还没“出生”，需要初始化。这就像装好了房子的框架，但还没装修和通水通电。初始化过程会创建系统库、内置用户、默认表空间等。如果这里出错，后面基本没法用。

3.1 初始化数据库实例

手动初始化一般用initdb命令，但 Vastbase G100 的安装包里也带了一个initdb.sh，它封装了一些参数选择。我更推荐直接用原生的initdb，因为可控性更高。首先切到vbuser用户，确认数据目录是空的：

su - vbuser rm -rf /data/vastbase/data/* # 确认是全新目录再执行 initdb -D /data/vastbase/data --encoding=UTF8 --lc-collate=en_US.UTF-8 --lc-ctype=en_US.UTF-8 --auth=sha256

注意--auth=sha256，Vastbase 默认支持密码的加密方式包括 md5 和 sha256，但新装的系统建议用 sha256。如果你设置--auth=md5，老版本客户端可能连不上，但安全性稍弱。初始化完成后，数据目录下会出现postgresql.conf、pg_hba.conf、pg_ident.conf、global、base等文件和目录。

3.2 配置监听地址与访问控制

初始化完成后，默认监听的是本地 socket，外部客户端连接不上。你需要修改postgresql.conf里的监听配置：

listen_addresses = '*' port = 5432

如果你的机器有多个网卡，指定具体 IP 比'*'更安全。比如只有内网 IP192.168.1.10，就写listen_addresses = '192.168.1.10'。

接着修改pg_hba.conf，这是访问控制策略文件。默认只有本地认证。我一般会添加一行允许内网子网连接：

host all all 192.168.1.0/24 sha256

这里有个坑：如果你在pg_hba.conf里写的是trust，意味着那个网段不需要密码就能连接，这在生产环境非常危险。我见过有人图省事写trust，结果数据库被扫到后数据被删。教训很深刻，务必按照实际安全要求设置认证方式。

3.3 启动数据库实例

初始化好配置文件后，就可以启动了。启动命令是：

vb_ctl -D /data/vastbase/data start

如果环境变量没配置，可能需要用绝对路径/opt/vastbase/bin/vb_ctl。启动成功后，看到类似server started的日志。你可以用vb_ctl -D /data/vastbase/data status检查状态。

第一次启动时，系统会比较慢，因为它要加载大量系统表和扩展。如果等 30 秒还没起来，不要急着杀掉进程，先去日志目录看pg_log下的错误日志。常见的一种情况是postgresql.conf里的shared_buffers等参数设置过高，导致内存不足无法启动。如果你在安装时没有调优过，默认值通常很小，但如果你是从别的机器拷贝过来的配置文件，就很可能出现这种问题。

3.4 启动后必做的验证

启动成功后，用vsql连接本地库验证版本和基本功能：

vsql -U vbuser -d postgres -h 127.0.0.1 -p 5432

输入密码后进入交互界面，执行：

select version();

正常会输出 Vastbase G100 的版本信息。再执行：

create database testdb; \c testdb create table t1(id int, name varchar(20)); insert into t1 values (1, 'ming'); select * from t1;

如果这几条能顺利跑通，说明数据库已经可用了。我习惯把这个作为一个“验收脚本”，每装完一个环境都跑一遍，避免后面才发现基本功能有问题。

4. 我趟过的坎：实用排错手册与避坑技巧

这部分才是重点。前面讲的都是标准流程，但实际部署中你会碰到各种意想不到的问题，有些甚至跟程序逻辑无关，纯属环境或者操作习惯导致。我把最典型的几类整理成了表格式速查，方便你直接对号入座。

4.1 启动时报 Permission denied

这是权限问题最常见的一种。主要表现为数据目录下的文件或者 socket 文件无法创建。原因：你可能用 root 执行了initdb，然后想把数据目录交给vbuser，但目录内文件的属主仍然 root。或者，/data挂载点开启了noexec选项，导致二进制可执行文件无法运行。

排查思路：

ls -l /data/vastbase/data | head stat /data/vastbase/data

如果属主不对，递归修改：

chown -R vbuser:vbuser /data/vastbase

如果是挂载选项问题，修改/etc/fstab去掉noexec，然后重新挂载。注意，对于数据目录，noexec其实是可以保留的，因为数据库的数据文件不需要执行权限，但安装目录不能有noexec。

4.2 连接时报 FATAL: no pg_hba.conf entry for host

这个报错很直白，就是访问控制策略没放行。你需要在pg_hba.conf里添加对应主机和认证方式的记录。有个容易踩的坑：pg_hba.conf是逐行匹配的，如果前面有一条host all all 192.168.1.1/32 reject，你即使后面加了合法的allow也没用，因为 reject 优先级在先。修改完记得 reload 配置：

vb_ctl -D /data/vastbase/data reload

reload 不会中断现有连接，是平滑生效的。

4.3 密码认证失败，明明密码正确

这个问题多半是加密方式不一致导致的。Vastbase 兼容多种密码认证协议，客户端驱动和服务端pg_hba.conf必须能协商一致。比如客户端用的是老版本 libpq，默认尝试 md5，但服务端只启用了 sha256，就会报password authentication failed。解决办法：

• 修改pg_hba.conf，将对应主机的认证方法改为md5或者同时支持两种；
• 或者升级客户端驱动，让其支持 sha256。

我建议尽量用较新的客户端，别为了兼容老程序降低服务端安全标准。

4.4 初始化时报 “could not find suitable encoding”

这和操作系统的 locale 有关。当initdb指定的编码与系统 locale 不兼容时，会直接失败。比如系统只有Clocale，你指定--encoding=UTF8，可能有些版本不允许。解决方案是先用locale -a查看系统支持的 locale，没有的话用localedef生成，或者直接指定--locale=C并配合--encoding=UTF8，但这种方式容易导致排序规则不符合中文习惯。最好的办法还是先把系统 locale 设置成en_US.UTF-8或zh_CN.UTF-8再初始化。

4.5 数据库启动后无法创建连接：to many open files

这个属于文件句柄耗尽问题。虽然你已经修改了limits.conf，但因为sum之类的方式启动的进程，可能仍然使用的是默认ulimit。检查方式：

cat /proc/$(pgrep -x vastbase)/limits | grep "open files"

如果限制只有 1024，说明修改未生效。有些场景下/etc/security/limits.d/下有更高优先级的配置，或者你是通过 systemd 管理数据库进程，systemd 服务文件里指定了LimitNOFILE。这种情况下，需要在 service 文件里加：

LimitNOFILE=65536 LimitNPROC=65536

然后systemctl daemon-reload并重启服务。

4.6 磁盘 I/O 高导致的长期卡顿

数据库跑起来后续航问题才是重点。有一次我发现系统整体响应慢，iostat显示util接近 100%，但业务量并不大。最后定位到是archive目录和data目录在同一块磁盘上，归档日志频繁写入拖累了主数据。这也是我在第一章就强调目录分离的原因。另外，WAL 日志所在的pg_wal（原pg_xlog）也不能和普通表数据放在同一块性能一般的存储上，有条件的话建议使用独立 SSD。实际上，很多虚拟机的数据盘是共享存储，你没办法单独控制 I/O 优先级，但至少可以通过data_directory和archive_command把不同类型的数据分散到不同卷。

4.7 快速定位问题的日志文件

任何时候，第一反应都是看日志。Vastbase G100 的日志路径默认在数据目录下的pg_log子目录，文件名包含日期和时间，比如postgresql-Wed.log。查看最近的错误：

tail -n 100 /data/vastbase/data/pg_log/postgresql-$(date +%a).log

如果日志里出现segmentation fault或者core dump相关字样，多半是内存或硬件兼容性问题。排查时先看是不是频繁触发OOM，用dmesg | grep -i oom检查。如果是，调整数据库的shared_buffers和max_connections，并确保操作系统没有过度的内存超配。

5. 初始化后的运维常用操作：从备份到参数调整

数据库装好了、跑起来了，但这只是开始。日常运维中有几个高频操作，我顺手总结一下，包括参数查看、备份恢复、日志轮转。

5.1 动态修改数据库参数

Vastbase 很多参数是可以在线修改的，比如shared_buffers，但有些需要重启数据库才能生效。查看当前生效参数：

show shared_buffers; show max_connections;

修改一个运行时参数：

alter system set shared_buffers = '2GB';

注意alter system set是写入postgresql.conf.auto文件，它会在服务启动时自动加载。如果该参数属于context: postmaster，那么需要重启；如果属于context: user，则当前 session 也能生效。用pg_settings视图可以查到每个参数的上下文类型：

select name, context, setting from pg_settings where name = 'shared_buffers';

5.2 手动备份与恢复

备份最简单的方式是使用内置的vb_dump工具，逻辑备份导成 SQL 文件：

vb_dump -h 127.0.0.1 -U vbuser -d testdb -F p -f /data/vastbase/backup/testdb_$(date +%Y%m%d).sql

恢复：

vsql -h 127.0.0.1 -U vbuser -d testdb -f /data/vastbase/backup/testdb_20250601.sql

如果是大库，逻辑备份会很慢，推荐使用物理备份vb_basebackup工具，它直接复制数据目录，恢复速度更快。例子：

vb_basebackup -D /data/vastbase/backup/base_20250601 -Ft -z -P

恢复时，把备份目录下的 base.tar.gz 解压到新的数据目录，并启动服务即可。注意恢复后要检查目录权限，不能让 root 拥有这些文件。

5.3 日志轮转与清理

数据库运行一段时间后，日志和归档会膨胀。Vastbase 支持日志轮转参数，建议在postgresql.conf中设置：

logging_collector = on log_rotation_age = 1d log_rotation_size = 100MB log_truncate_on_rotation = on

这样每天一个日志文件，超过 100MB 也会提前切割。归档目录的清理则要谨慎，只能清理已经备份过的归档文件，否则 PITR 恢复链会断裂。

5.4 日常巡检脚本思路

我习惯每周末写一个定时任务，检查这些内容：

• 数据库实例是否启动
• 磁盘使用率（df -h，数据目录、归档目录）
• 最近日志中是否有 ERROR、FATAL
• 备份文件是否如期生成

一个简单的巡检脚本可以放在/home/vbuser/scripts/check.sh：

#!/bin/bash source /opt/vastbase/etc/env.sh echo "=== disk usage ===" df -h /data echo "=== db status ===" vb_ctl -D /data/vastbase/data status echo "=== recent errors ===" grep -E "ERROR|FATAL" /data/vastbase/data/pg_log/postgresql-$(date +%a).log | tail -20

配合 crontab 执行，每天早上 8 点发邮件给你，或者写到日志文件里。这套思路虽然简单，但能让你第一时间发现数据库的异常。

6. 最后说点大实话

装 Vastbase G100 这个事，说难不难，说简单也不是一路绿灯。机器环境干净、内核参数调好、权限归位，一键脚本十几分钟就跑完，后续验证也顺利；但如果你忽略那些基础检查，可能每一步都踩一个莫名其妙的坑，而且报错信息还不直观，往往要折腾好久才反应过来原来是 ulimit 或者 /tmp 空间的问题。

我在实际部署中最大的体会是：不要迷信“一键安装”。一键脚本能帮你省掉很多重复劳动，但它替代不了你的环境认知。你至少要知道脚本会往哪里写文件，数据落到哪个目录，进程用什么用户启动。数据库的本质就是一套进程管理一堆文件，你把它当作一个复杂的 Linux 服务应用来看待，很多问题就迎刃而解了。

最后再分享一个小技巧：装完数据库后，第一时间给vbuser用户配置一个免密 sudo 范围（只允许运行巡检脚本和重启服务的命令），然后写一个数据库状态看板脚本，定期把pg_stat_activity里的慢查询和连接数打出来。这比任何监控工具都更贴近你的实际环境。装好只是起点，让它稳稳地跑起来，才是这门手艺的价值所在。