VCSAvCenter Server Appliance用的是一套内嵌的 PostgreSQL 数据库这套数据库和咱们平时在 CentOS 上自己装的 PostgreSQL 还不完全是一回事。很多搞虚拟化的朋友第一次接触 VCSA 底层的时候都会卡在这个问题上明明知道数据在 postgres 里却不知道怎么登进去。这篇文章我就专门把这件事讲透。从为什么 VCSA 要用这个特殊的 postgres、它的认证机制是什么到三种不同的登录方式再到现在很多人踩过的“磁盘写满导致 vmware-invsvc 起不来”这类问题都给你捋一遍保证你看完能直接上手操作。1. 先把 VCSA 的 postgres 搞清楚再动手1.1 它和标准 PostgreSQL 有什么不一样VCSA 本质上是一个运行在 Photon OS 上的虚拟设备。它内部的数据库不是你自己部署的标准 PostgreSQL而是 VMware 定制过的 postgres 版本通常位于两个地方/storage/db/vpostgres这个是 vCenter 主要业务数据存放的位置包括 vCenter Server 的清单数据、任务事件、权限配置等等。/storage/db/pg_hba.conf以及相关配置文件认证规则、监听配置都在这里。平时我们通过 vSphere Client 看到的那些对象、报警、任务记录底层就是这些数据表。所以当你遇到 Web Client 卡顿、任务堆积、权限错乱之类的怪问题时UI 上看不到本质直接查库往往是最快的路径。另外VCSA 的 postgres 默认并没有开放远程 TCP 连接监听地址通常是本地回环地址认证方式以 peer 和 md5或 scram-sha-256为主。这意味着你想用 Navicat、DBeaver 这类图形化工具去连 VCSA 的 postgres大多数时候是行不通的除非你自己去改监听配置。1.2 哪些场景下必须进数据库不是所有问题都需要直接操作数据库但下面这些场景你就绕不开了服务起不来比如 vmware-invsvc、vpxd 服务异常需要检查数据库连接状态和数据表完整性。任务和事件堆积vCenter 的任务列表成千上万条导致 UI 查询缓慢需要手动清理数据。权限数据错乱某个用户或角色在 UI 里删不掉、改不了需要直接操作 vc_ldap、vpx_principal 等表。性能数据异常需要查看 performance 相关的表是否有阻塞锁。说白了登录 VCSA 的 postgres 是虚拟化运维里的“底层手段”关键时刻能救命但平时不要乱动。2. 登录前的准备工作和几个关键认知2.1 先确认服务状态和端口监听在动手登录之前先确认 postgres 服务本身是活着的。SSH 登录 VCSA 之后用下面的命令查看服务状态service-control --status --all | grep -i postgres # 或者更细致一点 service-control --status vmware-vpostgres如果看到VMware vPostgres is running说明数据库服务正常你可以按下面的方法登录。如果服务没起来那后面所有登录操作都会失败这时候得先把服务拉起来service-control --start vmware-vpostgres再啰嗦一句VCSA 6.7 及更高版本里postgres 组件的服务名是vmware-vpostgres这个服务名和你看到的 postgres 进程是对应关系别搞混。2.2 几个必须知道的路径和认证规则VCSA 的 postgres 相关文件位置很固定你得先摸清楚项目路径psql 客户端/opt/vmware/vpostgres/current/bin/psql数据库数据目录/storage/db/vpostgres/配置文件/storage/db/vpostgres/pg_hba.confpostgres 系统用户/home/vpostgres实际是 vpostgres 用户VCSA 上 postgres 数据库的超级用户是postgres但注意了这里的认证方式默认是peer也就是说操作系统用户名为postgres或者有权限切换到postgres系统用户的人才能直接登录。如果你当前 SSH 登录的是root直接执行psql -U postgres大概率会报错误因为没有匹配的系统用户名。所以登录的核心逻辑就一句话先切换到 postgres 系统用户再执行 psql。这一点是很多新手卡住的主要原因。3. 三种登录 VCSA postgres 数据库的方法3.1 方法一切到 postgres 系统用户本地 psql 直连这是最推荐、最不容易出错的方式也是 VMware 官方文档里最常提到的办法。打开 VCSA 的 SSH 终端先把自己变成 postgres 系统用户sudo su - postgres注意VCSA 里 postgres 用户的 shell 环境有特殊配置切换到它之后psql 的路径已经被加到 PATH 里了。你可以用which psql验证一下如果能输出路径说明环境变量没问题直接进入数据库psql -U postgres -d postgres如果提示找不到 psql那就用完整路径/opt/vmware/vpostgres/current/bin/psql -U postgres -d postgres大部分情况下执行完上面这步你就已经进入 postgres 的交互终端了命令行提示符会变成postgres#。这时候你随便跑一条命令验证一下SELECT version(); SELECT current_database();能看到版本信息就说明你已经成功登录了。为什么这种登录方式最稳因为 VCSA 默认的 pg_hba.conf 里本地 socket 连接使用的是 peer 认证也就是直接信任当前操作系统用户。你人已经变成 postgres 系统用户了数据库那边自然就认你。提示sudo su - postgres用的是横杠-目的是带完整环境变量切换。如果你只写sudo su postgres环境变量可能不完整PATH 里可能没有 psql后面还得手动找路径麻烦。3.2 方法二用 PGPASSWORD 环境变量加 psql 登录有些人的需求是我不用每次都切用户我只想快速登录进去查点东西那可以用密码认证方式。这种方式的前提是你得已经知道 postgres 用户的数据库密码。VCSA 在部署的时候其实会生成一个随机的 postgres 数据库密码一般在日志里可以找到或者在 vCenter 设备配置界面里重置过。知道密码之后用 root 身份执行export PGPASSWORD你的密码 /opt/vmware/vpostgres/current/bin/psql -U postgres -h localhost -d postgres注意这里加了-h localhost因为密码认证走的是 TCP 连接不是本地 socket必须指定主机名。如果你不写-hpsql 默认走本地 socket又会触发 peer 认证哪怕密码对了也没用照样报错。这个方法适合脚本化操作。比如你想写一个自动化脚本定期检查 VCSA 数据库里的某个表就不用每次切换用户了。但前提是你得妥善保存 postgres 用户密码。如果你忘了密码怎么办看方法三。3.3 方法三单用户模式重置 postgres 密码这个方法是最后的手段属于“救急专用”。适合场景你完全不知道 postgres 数据库密码而且上面的 sudo su 切换方式因为某些原因也不行比如密码认证被改成 md5 了、peer 认证被注释掉了或者你怀疑 postgres 用户密码和系统行为不一致。记住重置密码的唯一可靠方式是单用户模式不是直接改 pg_hba.conf 改回 trust 就行虽然改 trust 也是一种办法但它更危险。完整步骤如下全程需要 root 权限第一步SSH 登录 VCSA切到 root停止 vpostgres 服务service-control --stop vmware-vpostgres第二步用 postgres 系统用户启动单用户模式sudo su - postgres /opt/vmware/vpostgres/current/bin/pg_ctl -D /storage/db/vpostgres -o -p 5432 -j single -l /tmp/pg_single.log start如果上面这条命令执行成功你会看到类似PostgreSQL stand-alone backend的提示实际上你已经被丢到一个单用户的后端进程里可以直接执行 SQL。第三步重置 postgres 用户密码ALTER USER postgres WITH PASSWORD 新密码;第四步退出单用户模式重启 vpostgres 服务-- 在单用户模式下没法直接输入 \q直接按 CtrlD 退出 exit然后回到 root启动服务service-control --start vmware-vpostgres重置之后你就可以用方法二通过 PGPASSWORD 和新密码连接数据库了。注意单用户模式下进行的操作是没有经过完整 MVCC 机制的所以除了 ALTER USER 这种简单的账户密码操作不要干别的。千万别在单用户模式下去改业务表数据风险极大这也是我从实践中得到的教训。3.4 不同版本 VCSA 的差异点VCSA 6.0、6.5、6.7、7.0、8.0 的 postgres 登录方式大同小异但有几个细节变化你得知道VCSA 6.0 / 6.5服务名是vmware-vpostgrespsql 路径同样是/opt/vmware/vpostgres/current/bin/psql切换用户后 PATH 一般没问题。VCSA 6.7postgres 升级到了 PostgreSQL 9.x登录方式没变但多了vmon-cli服务管理方式建议用service-control统一管理。VCSA 7.0 / 8.0引入了基于 vCLSvCenter Lifecycle Manager的服务协调机制postgres 服务依赖的组件更多启动顺序更敏感但单用户模式的操作方式仍然适用。另外要特别提醒一点VCSA 6.0 时代很多人在磁盘满后执行了日志清理但服务仍然起不来这就是因为 postgres 的数据文件或者 WAL 日志所在目录没有清理干净或者 postgres 进程由于初始化异常产生了残留锁文件。遇到这种情况光清理磁盘还不够你可能需要手动删掉 postmaster.pid 文件再启动服务。4. 实操记录磁盘写满导致 vmware-invsvc 起不来的完整处理4.1 问题现象我印象很深的一次是帮朋友处理一台 VCSA 6.0 U3版本号 6.0.0.30400现象是vCenter Web Client 打不开SSH 能登上去但service-control --start vmware-invsvc启动后过几秒钟服务就自动退出日志里报数据库连接错误。更蹊跷的是他明明已经清理过磁盘看磁盘占用率不到 60%但服务就是起不来。这种问题单看 UI 根本找不到原因必须进数据库和服务日志排查。4.2 排查思路和实际操作我先检查了 postgres 服务状态service-control --status vmware-vpostgres结果显示 postgres 也没在运行。接着我尝试手动启动 postgresservice-control --start vmware-vpostgres结果报错错误信息类似Failed to start service vmware-vpostgres这时候不要慌去翻日志tail -100 /var/log/vmware/vpostgres/serverlog_*.log日志里写着类似 “could not write to file pg_wal/...: No space left on device” 的字样。这就是典型的数据目录所在分区磁盘满的痕迹。表象上你可能看根分区空闲但 postgres 的数据目录如果单独占用一个分区那个分区满才是真凶。4.3 清理思路和操作遇到这种关键是先定位哪个分区满。df -h看看/storage/db或者/storage/archive这类目录所在分区的使用率。VCSA 的数据库和日志目录经常是独立分区的df 一看就知道。清理的方向有几个/storage/log下的 vCenter 日志尤其是 vmware 相关日志可以压缩或备份后删除。/storage/db/vpostgres/pg_wal或pg_xlog目录下的 WAL 日志确认没有 standby 节点依赖后可以手动清理一部分。/storage/archive目录下的老爷日志。但注意别直接用rm -rf删 WAL 目录里的东西最好是先备份再删而且只删 checkpoint 之前的 WAL 文件否则可能造成数据恢复问题。另外一个关键点是启动 postgres 前先确认没有残留的 postmaster.pid 文件否则启动会报 “lock file already exists” 错误ls -l /storage/db/vpostgres/postmaster.pid # 如果存在且进程确实已死删掉它 rm -f /storage/db/vpostgres/postmaster.pid清理完磁盘、删掉残留 pid 文件之后再按顺序启动服务service-control --start vmware-vpostgres service-control --start vmware-invsvc这次就正常了。这也说明了一个道理日志和数据目录用的同一个分区的场景脏日志是导致服务起不来的最大元凶清理一定要看分区不能觉得 “我清了根分区就够了”。4.4 服务启动顺序和依赖关系VCSA 的整套服务有强依赖顺序postgres 是底层的核心服务。如果 postgres 没有完全起来vmware-vpxd、vmware-invsvc 这些上层服务无论如何都起不来。所以排查服务问题先看 postgres 的状态永远是最优先的。有一个踩坑点值得一提在 VCSA 6.0 里如果你通过service-control --start --all一次拉起所有服务而 postgres 因为磁盘满或者其他原因没起来VMware 服务管理器不会自动重试后续所有服务都会进入失败状态。这时候千万别一个个去 start 上层服务正确做法是先修复 postgres然后按依赖顺序从底层往上层启动。5. 登录后的常用排查 SQL 和实用技巧5.1 查看当前连接和数据库大小成功登录 postgres 之后下面几条 SQL 是我最常用的-- 查看当前有哪些数据库 \l -- 查看 vCenter 主要业务库的大小 SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size FROM pg_database ORDER BY pg_database_size(datname) DESC; -- 查看当前连接情况 SELECT pid, usename, datname, state, wait_event_type, query FROM pg_stat_activity WHERE datname IS NOT NULL;当 vCenter 卡死、任务堆积、很多会话处于 active 或者 idle in transaction 状态时这些查询能帮你快速定位是不是数据库层面出了问题。5.2 清理任务和事件表vCenter 的任务和事件数据主要存在vpx_task和vpx_event这两张表里。如果 UI 操作太卡或者任务列表积累了几十万条历史数据你可以直接删掉旧数据-- 先看数据量 SELECT count(*) FROM vpx_task; SELECT count(*) FROM vpx_event; -- 删除 180 天之前的任务记录 DELETE FROM vpx_task WHERE create_time now() - interval 180 days;执行之前一定要先看数据量、先评估影响。不过这种 delete 操作如果数据量很大会产生大量 WAL 日志反而加重磁盘压力建议在业务低峰期执行并且可以先VACUUM一下VACUUM (VERBOSE, ANALYZE) vpx_task;5.3 常用连接排查有时候你登录之后可能发现执行 select 很慢这时候可以先看看有没有锁SELECT pid, usename, datname, wait_event_type, wait_event, left(query, 80) AS query FROM pg_stat_activity WHERE wait_event IS NOT NULL;找到异常会话后可以选择性终止SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state idle in transaction AND pid pg_backend_pid();但注意不要随便 kill active 状态的会话尤其那种正在执行关键任务的 session宁可先观察一段时间看看 wait_event 是什么也不要盲目终止。6. 常见问题速查表问题现象可能原因处理方式sudo su - postgres 后 psql 找不到命令环境变量没加载全用完整路径/opt/vmware/vpostgres/current/bin/psqlpsql 报 peer authentication failed当前系统用户不是 postgres先sudo su - postgres再执行 psql用 PGPASSWORD 方式但没加 -h localhost走了 local socket 触发 peer 认证加-h localhost或-h 127.0.0.1强制走 TCPpostgres 服务起不来日志提示 No space left on device数据分区满不只是根分区满df -h查看/storage/*各分区清理 WAL 和日志启动提示 postmaster.pid 已存在postgres 非正常关闭确认进程确实消失后删除 pid 文件再启动登录后执行 select 卡住存在锁等待或事务未提交查看 pg_stat_activity 的 wait_event 字段按需 terminate 空闲事务想用 Navicat / DBeaver 连 VCSA 的 postgresVCSA 默认只监听本机不建议改监听真要连需改 pg_hba.conf 和 postgresql.conf风险高重置 postgres 密码后 vpxd 服务连不上vCenter 内部配置仍然用旧密码同时检查和更新 vCenter 配置中的数据库密码或通过 vpxd 证书/配置工具同步7. 实操心得这件事别贪方便最后分享一点我自己的经验。VCSA 的 postgres 数据库本质上是一个可以绕过 UI 做“深度手术”的入口但能力越大责任越大。我在实际操作中有几个体会第一能用 UI 解决的事情千万不要进数据库改。UI 层有完整的校验和缓存同步机制你直接改库绕过了这套机制改完很容易出现 UI 显示和数据库内容不一致的情况反而更麻烦。第二登录数据库后最安全的第一条 SQL 永远是SELECT先拿数据而不是先改数据。哪怕是删除任务记录这种看起来人畜无害的操作也建议先做一次备份或者确认当前有 vCenter 备份。第三单用户模式只用于救急。不光是重置密码这类场景如果数据库本身数据损坏了单用户模式也帮不上大忙正确的思路是检查备份、走恢复流程而不是在单用户模式里面强行修复业务数据那样做风险非常大。第四磁盘清理这件事永远要看分区而不是看总览。VCSA 内部好几个分区各自独立/storage/db、/storage/log、/storage/archive都可能单独成区你别看总磁盘利用率还有 40%却不知道/storage/db已经爆了。实际排查的时候df -h列出来每个挂载点一一检查确认每个分区的使用率都低于 80% 再启动服务这个习惯值得保持。以上这些就是我处理 VCSA postgres 登录和相关服务故障时的主要经验和套路你照着操作能少走不少弯路。