企业官网建设流程全解析

简介：这份VASTDATA Vastbase G100 V2.2用户手册，是基于openGauss内核打造的国产信创数据库Vastbase G100的官方操作指南，适合数据库管理员、应用开发人员以及正在推进国产化替代的IT团队，用于解决数据库部署、连接与日常管理中的实际问题。手册从数据库逻辑结构图、数据查询请求处理过程、事务管理概念讲起，逐步深入到配置服务端远程连接、使用vsql工具连接、调用应用程序接口、使用sql语句或vb_ctl工具关闭数据库，以及创建和管理数据库、规划存储模型、利用列存数据压缩、管理表空间等关键操作，内容覆盖了从环境准备到日常管理的完整路径。资源包为单个PDF文件，体积约8.76MB，目录层级清晰，便于按需查阅对应章节。目前已有198人学习下载，对于需要快速上手Vastbase或评估其与现有系统兼容性的读者而言，是一份很实用的参考材料。

1. Vastbase G100 不是“拿来就装”的数据库：先看清版本和手册

Vastbase G100 是信创项目里点名率很高的国产数据库，很多团队以为它跟 PG 系开源库一样解压就能跑，结果装到一半连初始化工具都找不到。V2.2 的用户手册我前后翻了几遍，真正卡人的往往不是安装包本身，而是安装前的环境判断：内核版本、内存参数、目录归属，以及后面连接时的认证方式和备份恢复场景。这篇安装笔记按我给客户部署 Vastbase G100 V2.2 的实际流程写，从装什么版本、怎么初始化、怎么配远程连接，到建表、备份、安全策略，最后给一套 15 分钟的验证清单。适合正在做数据库替换、又不想被厂商文档牵着走的人。

2. 环境准备与安装：从系统参数到 vb_ctl 初始化

说实话，Vastbase G100 用户手册里并没有像开源软件那样一章“安装指南”，它默认你已经有了一套可运行的数据环境，然后才讲怎么连接、管理和备份。所以部署的第一步，是先把服务器系统调到一个 PG 系内核能舒服运行的状态。下面的每一步我在生产环境都踩过坑，照着做能省掉后面的玄学报错。

2.1 硬件、操作系统、用户与目录：先定基线

我一般先确认服务器配置：CPU 按 4 核起步，内存建议 16GB 以上，磁盘优先 SSD，且数据目录和备份目录分开。Vastbase G100 V2.2 对操作系统没有特别死板的限制，我部署过的环境包括内核 3.10 以上的主流 Linux 服务器发行版，都没问题。需要留意的是千万别在 tmpfs 或者 NFS 上放数据目录，数据库文件锁和持久化行为会变得很不可靠。

在动手之前，先把用户和目录建好。数据库不能用 root 跑，这是数据库部署的铁律：

# 创建专用的系统用户 groupadd vastbase useradd -g vastbase -d /home/vastbase -m vastbase # 规划安装目录、数据目录、备份目录和表空间目录 mkdir -p /opt/vastbase /vdb/data /vdb/backup /vdb/tablespace chown -R vastbase:vastbase /opt/vastbase /vdb

参数说明：useradd -g指定主用户组，-d设置家目录，-m强制创建家目录。/vdb/data是将来vb_ctl要初始化的数据目录，/vdb/backup留给vb_basebackup，/vdb/tablespace用于存放业务表空间。把所有目录一次性 chown 给 vastbase 用户，避免后面安装脚本或初始化时遭遇权限拒绝。

顺带检查一下磁盘布局。用df -h /vdb确认剩余空间，建议至少给数据目录预留 100GB 以上，用iostat看看磁盘是否在跑高负载。如果发现系统里还有没卸载的旧版数据库包，先停掉并清理干净，否则端口和目录会冲突。

2.2 内核参数与资源限制：不调这两个文件后面全是坑

数据库进程对共享内存、信号量和文件描述符都很敏感。很多同学装完启动失败，日志里报semget或者shmget异常，根源就在内核参数没调。修改/etc/sysctl.conf：

# 共享内存上限，64G内存建议至少设置为一半以上（单位字节） kernel.shmmax = 68719476736 kernel.shminfo.shmall = 4294967296 # 信号量参数：并发连接多时不够调大 kernel.sem = 501000 128256 501000 1024 vm.overcommit_memory = 0 vm.swappiness = 10 net.ipv4.ip_local_port_range = 5000 65535 fs.file-max = 1000000

参数说明：shmmax建议设为物理内存的一半以上，单位字节，我这里写的是 64G 内存场景的推荐值；sem四个数字分别控制信号量数组最大值、系统级最大信号量数、单次操作最大值和信号量集数量，并发连接多的时候不够调大就会报错。vm.swappiness=10让系统尽量少地把数据库内存换出到 swap。ip_local_port_range扩大客户端可用的临时端口范围，高并发下避免Cannot assign requested address。修改后用sysctl -p重载，确认没有报错。

然后再改/etc/security/limits.conf：

# vastbase 用户文件描述符、线程数和内存锁定限制 vastbase soft nofile 65535 vastbase hard nofile 65535 vastbase soft nproc 65535 vastbase hard nproc 65535 vastbase soft memlock unlimited vastbase hard memlock unlimited

说明：nofile是单个进程能打开的文件数上限，数据库连接多时每个连接都要占用文件描述符，不调大会在连接数几百时就提前报“too many open files”。nproc限制进程/线程数，数据库后台进程和连接线程较多时需要放宽。memlock unlimited让数据库可以在需要时锁定内存页，避免大页被换出。注意这些限制是针对 vastbase 用户的，必须退出 root 会话、重新用该用户登录后才会生效。可以用ulimit -n验证：

su - vastbase ulimit -n

如果返回的不是 65535，检查是不是有几行被注释，或者登录 shell 没加载 limits.conf。

2.3 解压安装、初始化和启动：vb_ctl 是核心

安装包解压前先确认下载的文件名和校验值。V2.2 的安装包通常是一个 tar.gz，我会先把它放到/opt下再解压，避免路径太长：

tar -zxvf VastbaseG100-V2.2.tar.gz -C /opt cd /opt/VastbaseG100-V2.2

解压后先看目录结构，一般会有install.sh或者 rpm 包。我用install.sh比较顺：

# 按实际包内的安装脚本参数为准，常见做法是 prefix/data/user ./install.sh --prefix=/opt/vastbase --data=/vdb/data --user=vastbase

参数说明：--prefix指定二进制和库的安装位置，--data指定数据文件目录，--user指定运行用户。如果厂商包提供的是 rpm，则rpm -ivh安装后再手工创建数据目录。执行安装脚本时注意当前用户，建议先在 root 下跑，把文件放到/opt/vastbase，然后 chown 给 vastbase。安装完成后验证关键工具存在：

ls -l /opt/vastbase/bin/{vsql,vb_ctl,vb_basebackup}

这三个工具一个是 SQL 交互客户端，一个是实例控制命令，一个是物理备份工具，后面全都会用到。缺了任何一个，说明安装目录或 PATH 不对。

接下来初始化数据目录。这一步相当于常见 PG 系里的 initdb 流程，在 Vastbase 里用vb_ctl init：

# 配置环境变量 export PATH=/opt/vastbase/bin:$PATH export LD_LIBRARY_PATH=/opt/vastbase/lib:$LD_LIBRARY_PATH # 初始化数据目录 vb_ctl init -D /vdb/data -U vastbase --encoding=UTF8

说明：-D指定数据目录，-U指定启动实例的系统用户，--encoding=UTF8保证数据库字符集是 UTF8，否则后面导入中文数据会乱码。初始化的过程会在/vdb/data下生成postgresql.conf、pg_hba.conf、pg_log等文件。如果遇到 “Permission denied”，百分之九十九是/vdb/data权限没给对，重新chown -R vastbase:vastbase /vdb再试。

初始化完先别连，直接用 vb_ctl 启动：

vb_ctl start -D /vdb/data

等待几秒后看控制台是否出现 “server started”。反复失败的话，打开日志：

tail -n 80 /vdb/data/log/vastbase.log

常见问题集中在磁盘空间不足、权限不对、端口被占用三类。日志里基本都会写清楚路径，按着提示改就行。启动后用 ps 确认进程：

ps -ef | grep vastbase | grep -v grep

现在数据库已经在本地跑起来了，下一步是让其他机器能连进来。

3. 连接配置与排查：vsql 远程连接最常见的 5 个坑

数据库启动成功只代表本地通了。实际业务场景里，客户端和应用服务器都在别的机器上，这时候连接配置就成了第一个拦路虎。手册里“配置服务端远程连接”“使用 vsql 连接”这两节内容不多，但坑却不少。我按真实部署中踩过的顺序，把配置过程和排查清单一起列出来。

3.1 修改监听地址与端口：服务端先开口

默认情况下，Vastbase 和大多数 PG 系数据库一样只监听本机的 socket，远程连接必须改listen_addresses。用 vastbase 用户编辑/vdb/data/postgresql.conf：

# 监听所有IPv4地址，如果只允许特定网卡，写具体IP listen_addresses = '0.0.0.0' port = 5432

参数说明：listen_addresses设成0.0.0.0表示监听所有 IPv4 地址，监听所有网卡。如果你只需要某个业务网卡被访问，就写具体 IP，比如192.168.1.10，减少无关网络的暴露面。port保持 5432，这是 PG 系默认端口，很多客户端工具不用带-p就能连。改完后必须重启或 reload 才生效：

vb_ctl restart -D /vdb/data

注意：vb_ctl reload能动态加载部分参数，但listen_addresses属于需要重启的参数，不要只依赖 reload。重启后用netstat -tlnp | grep 5432确认监听地址是0.0.0.0。

3.2 配置 pg_hba.conf：认证规则的顺序决定死活

监听打开之后，另一处配置是pg_hba.conf，它控制谁能从哪来、用什么方式认证。每行是一条规则：

# 类型 数据库 用户 来源网段 认证方式 host all all 192.168.1.0/24 sha256

字段从左到右分别是：连接类型、数据库名、用户名、来源地址、认证方法。连接类型常见的有local（Unix socket）、host（TCP/IP）、hostssl（强制 SSL 的 TCP/IP）。认证方法按安全等级从低到高有trust、md5、sha256、cert等。生产环境至少用sha256，绝对不要开trust，否则任何知道 IP 的人都能空密码进库。

配置完用vb_ctl reload -D /vdb/data热加载，不用重启。注意pg_hba.conf是自顶向下匹配的，第一条匹配到的规则立刻生效。所以具体的业务网段规则要写在0.0.0.0/0之前，否则全放行规则会先拦截，后面的限制就形同虚设。想看当前配置里哪些行生效，执行：

grep -v '^#' /vdb/data/pg_hba.conf

3.3 使用 vsql 连接：命令行参数和连接串两种姿势

服务端配置完，客户端就能连接了。最简单的形式：

vsql -h 192.168.1.10 -p 5432 -U testuser -d vastbase

参数说明：-h是服务器 IP，-p服务端口，-U用户名，-d数据库名。本地 socket 连接时可以省略-h，但远程连接必须给-h。如果数据库启用了 SSL，需要指定连接参数，更推荐用连接串：

vsql "host=192.168.1.10 port=5432 dbname=vastbase user=testuser sslmode=require"

连接串里的sslmode=require告诉客户端必须加密连接，服务端没开 SSL 或证书不对时，会直接报错而不是降级，这能避免密码走明文。连接上之后用\q退出。

3.4 远程连接常见问题：现象、原因、解决

以下问题我每次部署 Vastbase 基本都会遇到，整理成清单，按现象排查很快。

1. 现象：远程连接超时，卡在登录界面没反应。
   原因：防火墙或安全组没放行 5432 端口，也可能是listen_addresses没生效。
   解决：先在服务器本机执行vsql -h 127.0.0.1 -p 5432判断本地是否正常；再用netstat -tlnp | grep 5432查看监听地址是不是0.0.0.0；最后检查防火墙，这类系统下临时执行systemctl stop firewalld测试，如果通了再按需配置白名单。

2. 现象：远程连接报 “FATAL: no pg_hba.conf entry for host ...”。
   原因：来源 IP 网段在pg_hba.conf里没有匹配规则。
   解决：在 3.2 节添加对应的host all all 网段 sha256行，记住把更具体的网段放在0.0.0.0/0前面。加完 reload 即可。

3. 现象：认证时提示 “password authentication failed for user”。
   原因：密码输错，或者认证方式与加密存储不一致。
   解决：用超级用户在 vsql 里执行ALTER USER testuser IDENTIFIED BY '新密码';重置密码。同时确认postgresql.conf里的password_encryption参数和pg_hba.conf中的认证方法一致，V2.2 默认支持 sha256，如果 hba 里写 md5 而密码是按 sha256 存的，也会失败。

4. 现象：连接成功后过一会儿提示 “too many connections”。
   原因：数据库连接数被max_connections限制打满。
   解决：在postgresql.conf中调大max_connections，并同步调整shared_buffers。如果业务并发确实高，就用连接池，手册 4.2.9 节讲了 Vastbase JDBC 连接池用法，应用侧集中管理连接。

5. 现象：客户端指定sslmode=require后报 SSL 错误。
   原因：服务端没有启用 SSL，或者pg_hba.conf里没有hostssl规则。
   解决：按第 5 章生成证书并在postgresql.conf设置ssl = on，然后把对应规则改成hostssl开头。若只是测试，可以暂时去掉客户端sslmode=require，但生产环境不建议。

排查清单能覆盖九成连接问题。如果以上都不奏效，把日志打开：

tail -n 200 /vdb/data/log/vastbase.log

服务端每一次认证失败都会记录原因，比猜高效得多。

4. 建库建表落地：表空间、列存压缩、分区表参数怎么给

连接通了，接下来就是把业务对象建出来。Vastbase G100 的表结构语法沿用了 PG 系开源生态，但多出的列存压缩和 default 分区这两个特性，如果不按手册用，后面数据膨胀和分析性能都会很难看。这一章把建库建表需要决定的事捋一遍。

4.1 规划存储模型：表空间先定目录

手册 3.5 节讲存储模型，本质上回答“数据往哪块磁盘放”。在 Vastbase 里，表空间就是物理目录的抽象。创建表空间的语法：

-- 创建表空间，目录需提前创建并授权给vastbase用户 CREATE TABLESPACE ts_data LOCATION '/vdb/tablespace/data';

注意：/vdb/tablespace/data这个目录必须预先创建，并且属主是 vastbase 用户。如果目录不存在，会报 “directory does not exist”；如果权限不对，会报 permission denied。创建后用：

-- 查看表空间列表和对应物理位置 SELECT spcname, pg_tablespace_location(oid) FROM pg_tablespace;

确认表空间落位正确。建议把大表、索引和临时数据分表空间放，方便做磁盘空间配额和冷热分层。表空间不影响表结构，只是物理存储位置，后续磁盘不够时还可以新增表空间并迁移业务表。

4.2 普通表和列存表：ORIENTATION 和 COMPRESSION 怎么选

Vastbase 允许在建表时指定存储模型。默认是行存，适合 OLTP；列存适合分析统计类负载。手册 3.6 节专门讲列存压缩，我建的表一般这样写：

-- 列存表，采用高压缩比，适合分析型场景 CREATE TABLE t_analytics ( log_id BIGINT, channel VARCHAR(32), visit_time TIMESTAMP, amount NUMERIC(12,2) ) WITH (ORIENTATION=COLUMN, COMPRESSION=HIGH);

参数说明：ORIENTATION=COLUMN表示列存，COMPRESSION=HIGH选择高压缩等级。列存表按列组织，相同类型的数据聚在一起，压缩比能到行存的数倍，尤其在字符串和数字混合的表上明显。但列存表不适合频繁点查单行和大量 UPDATE，这类场景还是用行存表，省略 WITH 子句即可。

压缩等级除了HIGH，还有LOW、MIDDLE。选 HIGH 会增加 CPU 开销，写入变慢，但查询扫描的数据量变小。如果是日志事件类追加写入的表，HIGH 很划算；如果是高频写入的订单表，建议用 MIDDLE 或行存。判断标准很简单：读多写少、字段多、按列聚合，选列存；事务更新多、按行访问明细，选行存。

4.3 分区表和 default 分区：兜底数据不乱丢

手册 3.8.8 列出支持 default 分区，这是很多 DBA 期待的功能。范围分区示例：

-- 范围分区，末尾的default分区用于兜底 CREATE TABLE orders ( order_id BIGINT, order_date DATE, total_amt NUMERIC(12,2) ) PARTITION BY RANGE(order_date) ( PARTITION p2021 VALUES LESS THAN ('2021-01-01'), PARTITION p2022 VALUES LESS THAN ('2022-01-01'), PARTITION p_default DEFAULT );

说明：插一条'2022-06-01'的记录时，如果没有 default 分区，会被拒绝；有 default 分区，数据会掉进兜底分区，不会因为新月份没建分区而中断业务。注意 default 分区必须放在所有 partition 定义的末尾，否则后续分区不会按预期工作。列表分区类似，把PARTITION BY RANGE换成PARTITION BY LIST(region)，每个分区用VALUES ('华东', '华南')等枚举值。

分区表的好处不仅是查询裁剪，还有删除旧数据方便：直接DROP PARTITION p2021比DELETE FROM orders WHERE order_date < '2021-01-01'高效得多，这是生产环境很实用的运维手段。建分区前先评估数据分布：按时间增长的日志、订单表用范围分区；按地区、状态枚举的值用列表分区。

4.4 schema、索引、视图与序列：对象管理的骨架

手册 3.11 节包含 schema、索引、视图、序列。开发阶段建议一开始就规划好 schema，避免所有表挤在 public 里。创建 schema 并设置搜索路径：

-- 创建业务schema并指定属主 CREATE SCHEMA app1 AUTHORIZATION appuser; SET search_path TO app1;

说明：AUTHORIZATION appuser指定 schema 属主，SET search_path会让后续建表默认进入 app1，表名不用加前缀。索引：

CREATE INDEX idx_orders_order_date ON orders(order_date);

视图：

CREATE VIEW v_order_daily AS SELECT order_date, SUM(total_amt) AS total FROM orders GROUP BY order_date;

序列：

CREATE SEQUENCE seq_order_id START WITH 10000 INCREMENT BY 1;

说明：序列常配合nextval生成业务主键，也可以在建表时指定DEFAULT nextval('seq_order_id')。这几个对象语法与 PG 系开源库一致，从其他 PG 系数据库迁移过来基本没有学习成本。需要注意视图本身不占额外存储，但复杂视图的权限要单独授予，开发同学有时候会因为视图权限缺失而误以为 SQL 写错。

5. 数据安全与备份：vb_basebackup 与 SSL 证书落到现场

数据库能连、能建表还不够，上线前必须把认证加固和备份链路跑通。手册第 5 章的安全内容很多，我挑三块最容易被忽略但出了事最被动的讲：接入认证规则、SSL 加密连接、备份恢复。这三块也是故障高发区，我会把踩过的坑也放在里面。

5.1 接入认证：pg_hba.conf 的四种类型和匹配顺序

现在把 3.2 的认证规则再深入一点。Vastbase 的 pg_hba.conf 支持local、host、hostssl、hostnossl四种连接类型。按安全要求由高到低的典型配置：

# 本机socket连接走peer认证 local all all peer # 内网IP段走sha256 host all all 10.10.0.0/16 sha256 # 外网全部强制SSL hostssl all all 0.0.0.0/0 sha256

说明：local用于本机 socket 连接，用peer让操作系统用户和数据库用户名一致，安全可靠；内网10.10.0.0/16用sha256普通加密；外网全部强制hostssl，非 SSL 连接一概拒绝。规则顺序很重要，如果把这些颠倒，可能内网也被要求 SSL，或者外网走了非 SSL 通道。改完 reload 生效，别忘。

5.2 SSL 证书生成：openssl 怎么生成不报错

手册 5.1.3 讲证书生成，生产环境证书应由 CA 签发，测试环境自签足够。自签名证书两条命令：

# 生成2048位私钥，不带加密口令，避免启动时输入密码 openssl genrsa -out server.key 2048 # 生成自签名证书，CN尽量和主机名或IP保持一致 openssl req -new -x509 -key server.key -out server.crt -days 365 -subj "/CN=vastbase-server"

参数说明：第一条生成 2048 位 RSA 私钥，没有加-aes128这类加密选项，免得服务启动时还要输入密码。第二行的-new -x509表示生成自签名证书，-days是有效期，-subj里的CN尽量和服务器主机名或 IP 对应，否则客户端校验时会警告域名不匹配。

然后把证书放到数据目录：

# 证书和私钥放入数据目录，并严格收紧私钥权限 cp server.crt /vdb/data/server.crt cp server.key /vdb/data/server.key chmod 600 /vdb/data/server.key chown vastbase:vastbase /vdb/data/server.key

说明：私钥权限必须为 600，属主为数据库运行用户。如果私钥可被其他用户读取，Vastbase 启动时会拒绝加载 SSL 配置。随后在postgresql.conf里打开开关：

# 启用SSL并指定证书路径 ssl = on ssl_cert_file = 'server.crt' ssl_key_file = 'server.key'

重启数据库后，用vsql "host=127.0.0.1 port=5432 sslmode=require"验证是否强制走 SSL。也可以 reload 后看日志有没有 “SSL enabled” 的字样。

5.3 用户权限和行级访问控制：别让应用直连超级用户

手册 5.2 节有大篇幅讲权限。很多团队偷懒，让应用直接使用系统管理员账号，这是安全大忌。我的常规做法是创建业务用户并授予最小权限：

-- 创建业务用户并只授予最小必要权限 CREATE USER appuser WITH PASSWORD 'App@2024'; GRANT CONNECT ON DATABASE vastbase TO appuser; GRANT USAGE ON SCHEMA app1 TO appuser; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app1 TO appuser;

说明：先给连接库权限，再给 schema 使用权限，最后给表操作权限。表权限不要给到 public 或 all tables beyond schema，避免新表出现权限失控。手册 5.2.3 提到的三权分立，适合对审计要求严格的单位，把系统管理、安全管理、审计管理拆开。

行级访问控制（RLS）适合多租户场景：

-- 行级访问控制：每个用户只能看到自己行 CREATE POLICY rls_tenant ON app1.orders USING (tenant_id = current_user); ALTER TABLE app1.orders ENABLE ROW LEVEL SECURITY;

说明：启用了 RLS，普通用户查表只能看到tenant_id等于自己用户名的行，相当于把权限控到行这一格。注意超级用户和管理员默认不受 RLS 限制，这点手册也强调过。

5.4 物理备份：vb_basebackup 的 tar 格式

手册 3.11.6 讲的就是vb_basebackup，它在使用上和 PG 系开源库的 basebackup 工具很接近。先准备备份用户：

-- 创建具有物理复制权限的备份账号 CREATE USER backup WITH PASSWORD 'Backup@2024' REPLICATION;

说明：REPLICATION权限是vb_basebackup启动物理复制流所必需的，没有这个权限会报 “permission denied for replication”。备份整个实例的命令：

# 打包备份到指定目录，并流式同步WAL日志 vb_basebackup -Ft -D /vdb/backup/tar -p 5432 -U backup -X stream

参数说明：-F指定输出格式，t代表 tar；-D指定备份文件输出目录；-X stream表示在备份过程中以流方式同步 WAL 日志，保证备份的一致性。备份完成后，/vdb/backup/tar下会有 base.tar 和若干 wal.tar 文件。

如果实例里有自定义表空间，需要把表空间也带出来：

# -T 参数指定需要额外打包的表空间目录 vb_basebackup -Ft -D /vdb/backup/tar -p 5432 -U backup -T /vdb/tablespace/ts_data

-T参数指定表空间目录，备份时会额外生成对应表空间的 tar 文件。恢复时，把 base.tar 解包到新的空数据目录，再把表空间 tar 解包到目标位置，修改配置文件中的路径，最后用vb_ctl start -D /vdb/data拉起。具体步骤手册只给了标题，我一般按这套流程走：先tar -xf base.tar -C /vdb/data，再tar -xf ts_data.tar -C /vdb/tablespace/ts_data，然后chown -R vastbase:vastbase /vdb，最后启动。备份前记得清理过期备份，防止备份盘被写满。

5.5 备份和 SSL 的常见坑

这里再补三条真实遇到过的问题。

1. 现象：备份时提示 “could not open file /vdb/backup/tar” 或 permission denied。
   原因：备份目录属主不是 vastbase。
   解决：chown vastbase:vastbase /vdb/backup，或者用 root 创建后立即移交。备份命令必须以数据库用户或 authorized 用户执行。

2. 现象：恢复后启动失败，日志报表空间目录不存在。
   原因：备份包含表空间，但新环境的表空间目录忘了创建。
   解决：启动前先mkdir -p表空间目录并 chown。表空间在 postgresql.conf 或pg_tblspc里都有链接记录，目录不存在就会中断启动。

3. 现象：SSL 连接提示 “root certificate file not found”。
   原因：使用了自签名证书，但服务端缺少 root.crt。
   解决：把 server.crt 复制一份为 root.crt 放在数据目录，或者在客户端连接串中把sslmode降为verify-ca。生产环境建议申请正规证书。

6. 装完怎么验证：一套 15 分钟的健康检查

装完不是能启动就算成功，我见过太多部署后一个月才发现连接数上限不够、备份链路是坏的案例。现在我把验证做成固定动作，每次装完 Vastbase G100 V2.2 都强制走一遍，15 分钟内能把主要隐患过完。

6.1 功能与连接验证

先验证基础功能和建表能力：

# 查看版本信息 vsql -h 127.0.0.1 -p 5432 -U appuser -d vastbase -c "SELECT version();" # 创建临时表并用完再删，排除权限和临时表空间问题 vsql -h 127.0.0.1 -p 5432 -U appuser -d vastbase -c "CREATE TABLE v_check(id int); DROP TABLE v_check;"

预期能返回 Vastbase V2.2 版本信息，第二条建表删表无报错。这一步排除权限配置和临时表空间问题。

6.2 连接数、备份、SSL 专项检查

用表格做专项验证：

说明：SSL 检查用了一个技巧，pg_stat_ssl视图记录了当前后端进程的 SSL 状态，sslmode=require强制走加密，最后查该视图返回t说明服务端证书配置正确。如果返回空或f，检查ssl=on是否已生效。

快速检查连接数是否打满，可以执行：

# 查看连接上限参数 vsql -h 127.0.0.1 -p 5432 -U appuser -d vastbase -c "SHOW max_connections;"

同时看实际连接：SELECT count(*) FROM pg_stat_activity;如果两者接近，就要考虑调大或加连接池。

备份检查还可以更细一点，随机解包一个 tar 文件验证内容完整性：

# 只列出tar包前几行，确认备份可读 tar -tf /vdb/backup/tar/base.tar | head -n 10

能看到 backup_label 和目录结构，说明 tar 打包正常。

从那以后我每次给客户部署完 Vastbase，都会强制走一遍这套检查，特别是备份和 SSL 两项，早发现问题早处理，别等出故障才返工。希望帮到你。

本文还有配套的精品资源，点击获取