第一次在内网服务器上部署 PostgreSQL 14 的时候我差点因为缺一个 libreadline 依赖把整个下午耗在反复装包上。后来摸清楚离线安装的完整链路才发现这件事的难点根本不在“安装”本身而在“打包”和“配置”这两个环节。很多团队的服务器都是在安全区里没法直接连外网 yum 源手里只有一台能联网的跳板机或者镜像机这时候你必须在有网机器上把 PostgreSQL 14 的安装包连同所有依赖一起备齐再搬到内网装好并调通。整个过程踩坑不少但只要你把版本选择、依赖准备、初始化、配置文件这几个关键环节理顺离线部署 PostgreSQL 14 完全可以一次成功。这篇文章我会从我在生产环境里的实操经验出发把离线安装 PostgreSQL 14 从下载到配置完完整整拆开讲覆盖官方 RPM 包的选择、依赖收集、本地 YUM 源制作、initdb 初始化、postgresql.conf 和 pg_hba.conf 配置以及离线环境里最常见的几类报错排查。无论你是刚接触 PostgreSQL 的小白还是被项目临时派去内网部署的运维这篇都能给你一套可以直接照做的流程。1. 离线部署前先想清楚这几件事版本确认与安装方式决策1.1 为什么我推荐 14 系列而不是最新大版本PostgreSQL 的大版本迭代速度很快每年基本都会出一个新的大版本但这不代表生产环境就要追新。PostgreSQL 14 发布于 2021 年到现在已经迭代了大量小版本稳定性和社区生态都到了非常成熟的阶段。很多企业内部基于 PostgreSQL 开发的应用最初就是按 11、12、13 写的 SQL迁移到 14 几乎不需要改代码而且 14 本身在性能上相比 12、13 有明显提升比如说 vacuum 机制更高效、逻辑复制支持更好的并行回放、正则表达式和 JSON 处理能力增强这些对常规业务系统来说都是实打实的收益。选 14 还有一层很现实的原因离线环境下你没法频繁升级大版本。数据库一旦跑起来数据文件和系统表结构就跟大版本绑定了跨大版本升级需要专门的 pg_upgrade 流程在不能联网下载新依赖包的内网环境里更麻烦。与其选一个太新、周边配套还没跟上的大版本不如选一个已经稳定运行了两三年的 14 系列。当然如果你所在企业在安全合规上要求必须使用较新版本那选 15、16 也是可行的但安装思路和我下面讲的基本一致只是 RPM 包名称里的版本号不同。1.2 选择 RPM 安装还是源码编译离线场景的现实对比接触过 PostgreSQL 的朋友应该知道部署方式无非两条路用官方 RPM/DEB 包安装或者下载源码编译安装。在离线场景下这个选择题会变得格外关键。对比项官方 RPM 包安装源码编译安装依赖处理有明确的依赖关系可通过提前收集 RPM 包解决依赖库大多需要系统已有缺失时要逐个源码编译部署速度拷包、建源、yum install 三步搞定需要 configure、make、make install时间以小时计服务管理自带 systemd unit 文件开箱即用通常要自己写 service 文件或使用 pg_ctl 手动管理路径规范默认安装到 /usr/pgsql-14数据目录在 /var/lib/pgsql/14可自定义路径但所有路径都要自己规划后续维护小版本升级方便替换 RPM 包即可升级要重新编译维护成本高我的建议非常明确只要能搞到匹配操作系统版本的官方 RPM 包优先走 RPM 方案。离线环境里最怕的就是“装的时候一时爽维护的时候火葬场”RPM 方式至少让服务管理、目录规范、卸载清理都跟在线安装保持一致。而且 PostgreSQL 官方 YUM 仓库里每个 RPM 包都有明确的版本和系统标识比如 postgresql14-server-14.11-1PGDG.rhel7.x86_64.rpm你一眼就能看出这是给 RHEL/CentOS 7 用的适合内网环境里严格管控软件版本的要求。除非你的服务器 CPU 架构比较特殊比如某些国产化环境里的 ARM 或 MIPS 架构官方仓库没有现成 RPM 包才考虑源码编译。源码编译最大的坑不是编译本身而是依赖库缺失内网环境装不了 readline-devel、zlib-devel 这些基础开发库的时候你会发现连 configure 这关都过不去。1.3 目标环境盘点清单去内网机房之前我建议你先花十分钟做一次环境盘点确认下面这几项操作系统版本和 CPU 架构执行cat /etc/redhat-release和uname -m搞清楚是 CentOS 7、RHEL 8 还是其他兼容系统是 x86_64 还是 aarch64这决定了你应该下载哪个后缀的 RPM 包。是否已经装过其他版本的 PostgreSQL 或者其他数据库避免端口冲突和 RPM 包冲突。服务器内存、磁盘空间情况PostgreSQL 跑生产至少要有 2GB 内存、20GB 以上空闲磁盘数据目录所在的挂载点需要重点确认。是否有 root 权限或 sudo 权限离线安装过程中要创建系统用户、修改/etc/yum.repos.d、操作 systemd没有 root 会非常被动。这些信息不需要什么高级工具几条命令就够。环境盘点做到位后面打包就不会出现“包拿错了”“架构不对”“依赖冲突”这种低级问题。2. 在一台能联网的机器上收集全套安装包依赖链不容出错2.1 下载入口官方 YUM 仓库结构说明PostgreSQL 官方提供了专门的 YUM 仓库地址是download.postgresql.org/pub/repos/yum/里面按大版本号、操作系统、CPU 架构分好了目录。以 14 版本为例针对 RHEL/CentOS 7 x86_64 的路径大致是https://download.postgresql.org/pub/repos/yum/14/redhat/rhel-7-x86_64你需要提前在自己的网络环境里确认能访问到这个仓库。如果公司网络有限制可以先在本地虚拟机或者公司允许联网的镜像机上一次性把所有包拉下来。直接在有网机器上配置临时 YUM 源是最便捷的做法在/etc/yum.repos.d/下新建一个pgdg14.repo文件[pgdg14] namePostgreSQL 14 for RHEL/CentOS 7 - x86_64 baseurlhttps://download.postgresql.org/pub/repos/yum/14/redhat/rhel-7-x86_64 enabled1 gpgcheck1 gpgkeyhttps://download.postgresql.org/pub/repos/yum/RPM-GPG-KEY-PGDG如果你的有网机器是 CentOS 7仓库配置好之后直接执行yum makecache fast就能把 PostgreSQL 14 的元数据拉下来。这里要注意仓库配置里的$releasever变量到了内网环境经常会因为系统版本识别问题导致 baseurl 对不上我后面会讲怎么处理。2.2 用 yumdownloader 自动拉取依赖手动一个个去官网下载 RPM 包很容易漏依赖因为 PostgreSQL 14 的安装包依赖了 libpq、readline、zlib 等一堆基础库。最稳妥的方式是使用yumdownloader工具它会根据当前系统的可用源自动解析依赖并下载所有需要的 RPM 包。首先在有网机器上安装 yum-utilsyum install -y yum-utils然后创建目录并下载mkdir -p /tmp/pg14_packages cd /tmp/pg14_packages yumdownloader --resolve --destdir/tmp/pg14_packages \ postgresql14-server postgresql14-contrib postgresql14--resolve参数是核心它会自动把所有运行时依赖一起下载下来这样你拿到内网之后只要按照依赖顺序安装就不会出现“装 server 时提示缺 libpq”这种问题。我建议把 postgresql14-contrib 也一起拉上因为 contrib 包里有很多实用扩展比如pg_stat_statements后面做性能监控会用到。另外如果将来打算用 PostgreSQL 做开发或编译扩展可以顺手把postgresql14-devel也下载了。这个包内网环境一般用不到但备着一个不占多少空间万一以后要装 TimescaleDB 这类扩展就有现成的头文件了。2.3 手动备齐依赖库的兜底方案yumdownloader 不是万能的。有些精简系统镜像在 base 源里就缺少个别依赖或者有网机器和目标服务器 yum 源里的基础包版本有差异导致下载列表里漏掉某些系统库。这时候你需要知道 PostgreSQL 14 的核心依赖到底有哪些手动兜底。我在 CentOS 7 上实测PostgreSQL 14 的主要 RPM 依赖包括postgresql14-libsPostgreSQL 客户端共享库几乎所有组件都依赖它libicu提供 Unicode 和字符集支持readlinepsql 交互式命令行依赖zlib数据压缩相关libxslt 和 libxml2XML 处理功能openssl-libsSSL 加密通信pam-libsPAM 认证支持systemd-libssystemd 服务集成如果 yumdownloader 没有把这些依赖全部拉下来你可以手动去 CentOS 基础镜像仓库对应目录下载或者更简单的方式是换一台带有完整 ISO 源或者阿里云镜像源的有网机器重新执行一次 yumdownloader。这里分享一个我常用的判断方法下载完所有包之后在目标服务器离线安装前先在有网机器上把包作为本地源执行一次yum install --downloadonly看有没有缺失的依赖被解析出来。把获取到的包和之前 yumdownloader 下载的合并基本就齐了。2.4 把安装包做成本地 YUM 源再拷走很多人习惯直接把 RPM 包带到内网后用rpm -ivh *.rpm一把梭我强烈不建议这么做。原因有两个一是安装顺序不对会报依赖错误你必须手动排序二是 RPM 包之间如果存在版本覆盖关系rpm -ivh处理起来很粗糙不会自动升级或替换。更规范的做法是把这些 RPM 包做成一个本地 YUM 源到内网后用 yum 安装让 yum 自己处理依赖顺序。在有网机器上安装 createrepoyum install -y createrepo cd /tmp/pg14_packages createrepo .执行完之后这个目录下会生成一个repodata子目录里面是仓库元数据。整个/tmp/pg14_packages目录打包拷贝到内网服务器任意目录比如/opt/pg14_rpmtar czf pg14_packages.tar.gz /tmp/pg14_packages到内网解压后在/etc/yum.repos.d/下新建一个本地源配置[local-pg14] nameLocal PostgreSQL 14 Repository baseurlfile:///opt/pg14_rpm enabled1 gpgcheck0注意我在本地源里关闭了 gpgcheck因为内网环境没有官方 GPG key而且包来源是有网机器上一手拉下来的可信度比较高。如果你想保留签名校验可以提前把官方RPM-GPG-KEY-PGDG拷贝到内网并配置好 key但这在离线环境里多一层管理负担不是必须。配置好后执行yum clean all yum makecache接下来直接yum install -y postgresql14-server postgresql14-contribyum 会自动解析/opt/pg14_rpm目录下所有 RPM 包的依赖关系你完全不用手动排序。这一步做对了离线安装可以说已经成功了 70%。3. 内网机器上的安装实战RPM 安装与数据库初始化3.1 上传与本地源配置到这一步你手里应该有了一个完整的压缩包或者一个目录的 RPM 文件。上传到内网服务器之后建议直接放到/opt/pg14_rpm这种固定路径避免后面机器重启或者目录清理导致源失效。上传方式根据内网环境来常见的包括 scp、U 盘拷贝、运维平台的文件分发功能。文件落地后先校验一下包数量ls -l /opt/pg14_rpm/*.rpm重点看有没有postgresql14-server、postgresql14-contrib、postgresql14-libs这几个关键包。确认无误后创建本地源配置文件内容我在上面已经给出这里不再重复。如果目标服务器是 CentOS 7还要注意把系统自带的 base 源、epel 源临时禁用否则 yum 会去外网找源离线环境里会卡住或者超时。最简单的方式是给这些外部源配置文件加.bak后缀或者把enabled1临时改成enabled0装上 PostgreSQL 17之后再恢复。这里我多说一句如果内网服务器本身有内网 YUM 源不要彻底删掉原配置只临时禁用就行因为 PostgreSQL 依赖的那些基础库可能还需要从内网源补。3.2 为什么装完 RPM 之后必须手动执行 initdb很多第一次装 PostgreSQL 的人会踩一个坑明明 RPM 包装完了、systemctl start postgresql-14却提示启动失败或者服务起来了连上去报错说找不到数据库。这是因为 RPM 安装只是把二进制程序、脚本和默认配置放到系统目录里它不会自动帮你创建数据目录和初始化数据库集群。PostgreSQL 里有个核心概念叫“数据库集群”它不是多台服务器的意思而是指一个由配置、数据文件、WAL 日志组成的完整数据目录集合。初始化这个数据目录的动作就叫 initdb。就像你把一套工具箱买回家工具箱本身不会自动把工具摆好你必须自己打开柜子把工具分类放进去。PostgreSQL 官方 RPM 包提供了初始化脚本直接执行/usr/pgsql-14/bin/postgresql-14-setup initdb这个脚本本质上是帮你以 postgres 用户身份调用 initdb并把数据目录指定为/var/lib/pgsql/14/data。如果你执行后看到类似“Data directory initialized”的输出就说明数据集群创建成功。如果你想手动执行 initdb 以便更精确地控制字符集和 locale可以这样操作su - postgres /usr/pgsql-14/bin/initdb -D /var/lib/pgsql/14/data \ --encodingUTF8 \ --localeen_US.UTF-8这里我强烈建议--encodingUTF8因为默认的 SQL_ASCII 字符集下中文存储和排序会出现意想不到的问题尤其在做中文全文检索的时候。--locale建议选en_US.UTF-8如果你的系统里没有安装 en_US 语言包可以换成C或zh_CN.UTF-8具体看目标服务器有没有对应 locale。3.3 首次启动与基础连接验证数据目录初始化完成之后就可以启动服务了systemctl start postgresql-14 systemctl status postgresql-14如果状态是 active (running)继续检查端口是否监听ss -lntp | grep 5432看到5432端口被postgres进程监听就说明服务正常。接下来登录数据库做一次基本验证。RPM 安装会自动创建名为postgres的系统用户我们需要切换到该用户执行 psqlsu - postgres psql -U postgres这里有一个细节需要注意本机直接psql -U postgres走的是本地 socket 连接认证方式默认是 peer也就是说系统用户叫postgres数据库用户叫postgres就能免密登录。如果你发现提示输入密码说明你的pg_hba.conf初始配置和默认不一样先不用急后面配置章节会讲清楚。进入 psql 后可以先执行几条基础命令验证SELECT version(); SHOW port; SHOW data_directory;能看到 PostgreSQL 14.x 版本号、端口 5432、数据目录/var/lib/pgsql/14/data就说明整个安装链路已经通了。3.4 目录权限和 SELinux 对安装的影响内网环境里经常见到初始化失败或者启动失败原因不是 PostgreSQL 本身的问题而是数据目录权限不对。RPM 安装默认会给/var/lib/pgsql/14/data设置成 postgres 用户所有但如果你手动执行过 initdb或者恢复过备份数据目录很容易把目录所有者搞成 root。检查权限ls -ld /var/lib/pgsql/14/data正常应该是drwx------. 3 postgres postgres。如果不是执行chown -R postgres:postgres /var/lib/pgsql/14/data chmod 700 /var/lib/pgsql/14/dataPostgreSQL 对数据目录权限很敏感如果权限设置成 755进程在启动时甚至会主动报错拒绝运行这是它的安全策略不是 bug。另外如果目标服务器开启了 SELinux即使端口监听正常远程连接也可能被 SELinux 拦截。快速判断方法getenforce如果输出是 Enforcing可以临时执行setenforce 0测试是不是 SELinux 拦截确认后再决定是放宽策略还是彻底关闭。部分安全要求严格的内网服务器要求 SELinux 保持 Enforcing这种情况下可以通过 audit2allow 生成自定义策略但一般企业内网环境稳妥起见我会先和运维确认安全基线再决定处理方式。我自己的经验是PostgreSQL 官方 RPM 自带了一个 SELinux compatibility 包postgresql14-contrib里的配套工具和策略但实际情况中配置起来还是有点绕所以如果安全基线允许直接把数据库所在端口加入 SELinux 放行列表是最省力的方案。4. 配置详解postgresql.conf 与 pg_hba.conf 才是部署重点4.1 监听地址和端口改完不生效的常见原因PostgreSQL 默认只监听localhost也就是说从其他机器访问你的 5432 端口连接会被直接拒绝。修改监听地址的方法是在postgresql.conf文件中设置listen_addresses * port 5432listen_addresses支持设置多个 IP比如127.0.0.1, 192.168.10.20只监听本机和内网 IP。如果你希望所有网卡都能接受连接就写*。改完之后很多同学发现远程还是连不上第一反应是systemctl restart postgresql-14重启服务但重启后依然不行。这时候你要先确认自己改的配置文件是不是 PostgreSQL 真正读取的那个。PostgreSQL 的配置文件路径可以通过 SQL 查询SHOW config_file; SHOW hba_file;我遇到过改了/etc/postgresql/14/main/postgresql.conf结果服务实际读取的是/var/lib/pgsql/14/data/postgresql.conf的情况两边配置文件不同步白白折腾半天。在 RPM 安装的标准环境下postgresql.conf就位于数据目录里也就是/var/lib/pgsql/14/data/postgresql.conf。不要凭记忆去改其他位置的同名文件先执行 SHOW 确认路径。修改配置后的生效规则也要清楚listen_addresses和port属于需要重启才能生效的参数。可以用systemctl reload postgresql-14平滑加载大部分参数但监听地址和端口这类参数必须重启。生产环境如果不想中断业务可以选择在维护窗口执行 restart或者用pg_ctlcluster之类的工具做优雅重启。4.2 内存参数怎么设才不至于拍脑袋PostgreSQL 的内存参数直接影响查询性能和并发能力很多离线部署的服务器专用于跑数据库所以这些参数值得认真设置。下面几个是我每次部署都会重点确认的参数默认值建议参考说明shared_buffers128MB物理内存的 25% 左右PostgreSQL 的共享缓存池所有连接共享使用work_mem4MB32MB 到 64MB单个排序、哈希操作可用的内存不宜盲目调大maintenance_work_mem64MB256MB 到 512MB用于 VACUUM、CREATE INDEX 等维护操作effective_cache_size4GB物理内存的 50% 到 75%让优化器估算操作系统文件缓存大小max_connections100按应用连接池实际需求每个连接都会消耗一定内存不是越大越好这里要解释一下 work_mem 的坑它和 shared_buffers 不一样是每个操作都可以分配的内存。比如一个查询里涉及 4 个排序操作那它最多可能占用 4 倍的 work_mem。如果服务 100 个连接同时各跑一个复杂排序work_mem 调到 1GB 就会瞬间把内存吃满触发 OOM。所以 work_mem 的正确调法是结合并发量宁可小一点让它落盘也不要大到把系统拖死。修改后检查是否生效SHOW shared_buffers; SHOW work_mem;如果行为准值没有变你可能会重新确认修改位置。有些参数也支持通过ALTER SYSTEM设置比如ALTER SYSTEM SET shared_buffers 512MB;这会把配置写到postgresql.auto.conf文件里优先级高于 postgresql.conf后续管理时要留意。4.3 pg_hba.conf 认证规则与 14 的 scram-sha-256 变化如果说 postgresql.conf 控制的是“数据库怎么跑”那 pg_hba.conf 控制的就是“谁能连、怎么认证”。这个文件的全称是 Host-Based Authentication每一行都是一条访问规则从上到下匹配一旦命中就不再继续往下走所以规则顺序很关键。离线部署时最常用的一套规则模板如下# TYPE DATABASE USER ADDRESS METHOD local all postgres peer local all all scram-sha-256 host all all 127.0.0.1/32 scram-sha-256 host all all 192.168.10.0/24 scram-sha-256逐行解释第一行本地 socket 连接且系统用户是 postgres 时用 peer 认证直接免密登录。这是管理员维护通道保持默认就好。第二行本地 socket 连接其他用户时要求输入密码认证方式 scram-sha-256。第三行允许本机 IP 通过 TCP 连接要求密码。第四行允许内网 192.168.10.0/24 网段的机器通过 TCP 连接要求密码。这里有个 PostgreSQL 14 带来的重要变化从 15 开始password_encryption默认值是scram-sha-256但很多从 11、12 迁移到 14 的人还在沿用旧的 md5 认证。如果你的 pg_hba.conf 里写的是md5而用户密码是以 scram-sha-256 方式存储的认证就会失败。反过来也一样。所以 14 环境里我建议统一使用scram-sha-256先把认证方式确定下来再设置用户密码。设置用户密码的命令ALTER USER postgres PASSWORD 强密码;为应用单独创建用户更安全CREATE USER appuser WITH PASSWORD app密码; GRANT CONNECT ON DATABASE appdb TO appuser;我见过很多团队直接用 postgres 超级用户当应用连接账号这在隔离的内网环境里可能问题不大但一旦应用被攻破数据库权限就是最高的风险很高。离线内网系统也一样要有权限最小化的意识。4.4 日志参数和中文环境设置离线环境下调试问题主要靠日志所以日志参数值得在部署时就配好。postgresql.conf 里建议打开这几个参数logging_collector on log_directory log log_filename postgresql-%a.log log_rotation_age 1d log_rotation_size 100MB log_min_duration_statement 1000log_min_duration_statement表示执行时间超过 1000 毫秒的 SQL 会被记录这对后续排查慢查询非常有用。日志文件会生成在数据目录下的log子目录里比如/var/lib/pgsql/14/data/log不是 Linux 系统日志目录这个容易搞混。关于中文环境内网服务器经常会出现locale不存在导致 initdb 失败或字符集异常的问题。我前面建议用en_US.UTF-8初始化数据集群因为大部分 Linux 系统默认带这个 locale。如果你确实要使用zh_CN.UTF-8先确认服务器的 locale 是否可用locale -a | grep zh_CN如果输出为空说明系统还没装中文语言包。在线环境可以装glibc-langpack-zh但离线环境里就得提前把语言包的 RPM 准备好。所以我通常选择用en_US.UTF-8初始化数据库里照样可以存中文完全不耽误业务功能又少了一层环境依赖。5. 服务自启动与日常运维命令速查5.1 用 systemd 托管 pg_ctl 生命周期PostgreSQL 官方 RPM 包自带 systemd 服务文件服务名是postgresql-14。安装并初始化数据库后执行systemctl enable postgresql-14 systemctl start postgresql-14enable的目的是让 PostgreSQL 开机自启动start是立即拉起服务。如果后续修改了端口或者数据库版本升级服务的 unit 文件一般不需要手动改官方 RPM 已经把环境变量和启动参数封装好了。有时候内网服务器在启动时网络服务还没就绪导致 PostgreSQL 启动后监听失败这时你可以检查 systemd 服务文件里的依赖关系。官方 unit 文件通常是这样的[Unit] DescriptionPostgreSQL 14 database server Afternetwork.target如果遇到开机启动顺序问题可以手动加一条依赖[Unit] Afternetwork-online.target Wantsnetwork-online.target改完之后执行systemctl daemon-reload再重启服务。不过这种情况在企业内网环境里比较少大多数时候网络服务启动比数据库快得多。5.2 日常常用操作清单部署完成后的日常运维操作我整理成一张速查表方便你需要时直接对照操作命令启动服务systemctl start postgresql-14停止服务systemctl stop postgresql-14重启服务systemctl restart postgresql-14重载配置systemctl reload postgresql-14查看状态systemctl status postgresql-14查看端口ss -lntp | grep 5432本地连接su - postgres -c psql -U postgres查看日志tail -f /var/lib/pgsql/14/data/log/postgresql-周六.log查看数据目录du -sh /var/lib/pgsql/14/data备份数据库pg_dump -U postgres -h 127.0.0.1 dbname db.sql恢复数据库psql -U postgres -h 127.0.0.1 dbname db.sql这里要特别提醒日志文件名里的%a是星期几如果周一排查问题日志文件可能是postgresql-Mon.log你直接ls /var/lib/pgsql/14/data/log/看看实际生成的文件名就行。不要凭记忆去 tail 一个不存在的日志文件。5.3 配置变更后的重载规则修改 PostgreSQL 配置有两种方式reload和restart。reload不会中断连接适合修改日志等级、work_mem、shared_buffers 之外的大多数动态参数restart会断开所有连接适合修改shared_buffers、max_connections、port这类 PostgreSQL 文档里明确标注为“需要重启才能生效”的参数。我的操作习惯是改完配置先执行systemctl reload再在 psql 里用SHOW命令看参数是否生效。如果该参数必须重启才生效SHOW出来的值还是旧的这时候再计划 restart。需要注意的是ALTER SYSTEM SET设置的参数和 postgresql.conf 里的参数会叠加生效优先级是 postgresql.auto.conf 高于 postgresql.conf。如果出现“改了 postgresql.conf 但参数没变”的情况检查一下是不是之前用过 ALTER SYSTEM 写入了同样的参数执行SELECT * FROM pg_file_settings WHERE sourcefile LIKE %auto%;看到具体配置来源后你就可以决定是清理 auto.conf 记录还是在 postgresql.conf 里直接改。6. 离线安装高频报错我把排查过程重新走了一遍6.1 依赖缺失rpm 安装顺序和报错解读离线安装最常见的报错就是“Requires: libreadline.so.6()(64bit)”。看到这种报错你的第一反应不应该是去网上搜这个库文件怎么下载而是回想一下你有没有用 yum 方式安装而是一开始就rpm -ivh *.rpm一把梭了。rpm -ivh *.rpm的方式需要手动排序装 postgresql14-server 之前必须先装 postgresql14-libs而 libs 又依赖系统的基础库比如 readline、zlib。如果这些基础库正好在系统里没有rpm 就会直接报错。最省心的办法就是我前面说的本地 YUM 源方案yum 会自动按依赖顺序装好并提示缺什么。如果系统提示缺少某个基础库而你的离线包里又没有那就只能回到有网机器上把对应的基础 RPM 包拉下来或者看目标系统的 ISO 镜像里有没有相关包。我在这里提一个取巧的办法找一台和目标服务器操作系统版本一致的有网机器执行yumdownloader --resolve --destdir 目标目录 readline zlib libicu再把拉下来的包补到离线包目录里。6.2 初始化失败权限和动态库问题初始化失败分两种一种是 initdb 执行时报权限错误比如initdb: error: could not change permissions of directory /var/lib/pgsql/14/data: Operation not permitted这种几乎都是数据目录的所有权不对。你如果不是用官方postgresql-14-setup脚本而是手动执行 initdb就会遇到这个问题。解决方式是把数据目录 chown 给 postgres 用户然后切换到 postgres 用户再跑 initdb。千万不要在 root 用户下强行执行 initdb即使初始化成功后续服务启动也会因为权限问题报错。另一种是动态库加载失败比如ERROR: could not load library /usr/pgsql-14/lib/plpgsql.so: libpq.so.5: cannot open shared object file这种通常出现在从源码编译或手动拷贝文件导致的环境变量不对。官方 RPM 安装时会在/etc/ld.so.conf.d/下写入 PostgreSQL 的库路径如果你发现动态库找不到检查一下有没有这个文件cat /etc/ld.so.conf.d/postgresql14*.conf正常应该有类似/usr/pgsql-14/lib的路径。如果没有手动创建并执行ldconfig刷新。6.3 远程连接超时防火墙、SELinux、postgresql.conf 三层排查远程机器连不上数据库我先说排查顺序这个顺序是我踩过无数次坑之后沉淀下来的看服务是否监听在所有网卡上使用ss -lntp | grep 5432如果看到的 IP 是127.0.0.1:5432那说明listen_addresses没有生效。看防火墙是否放行 5432 端口执行firewall-cmd --list-all或iptables -L -n。看 SELinux 是否拦截执行getenforceEnforcing 状态下尝试setenforce 0临时关闭后重试。看pg_hba.conf里有没有你客户端 IP 所在网段的规则。按照这个顺序排查基本能覆盖 90% 的远程连接问题。我曾经在一台 CentOS 7 服务器上排了半天最后发现是listen_addresses写成了127.0.0.1而不是*客户端来源 IP 直接不是本机当然连不上。6.4 认证失败遇到“password authentication failed”先看日志如果客户端报错FATAL: password authentication failed for user appuser第一反应不要急着去改密码而是先看数据库日志tail -100 /var/lib/pgsql/14/data/log/postgresql-周一.log日志里会明确告诉你认证类型和来源 IP。常见的几个认证失败原因密码加密方式不匹配pg_hba.conf 写 md5但用户密码是 SCRAM 存储。认证方式被 peer 规则拦截你从远程 TCP 连接但命中了一条local规则这通常是因为网络地址写成了本机路径。用户不存在PostgreSQL 的账号是独立于系统账号的你创建了系统用户不代表同时创建了数据库用户。检查用户当前认证方式SELECT rolname, rolcanlogin FROM pg_roles WHERE rolname appuser;如果用户没问题把 pg_hba.conf 里对应规则的 METHOD 改成scram-sha-256再用ALTER USER重新设置一次密码几乎都能解决。另外我提醒一下离线环境里容易出现的问题如果你是从别的机器拷贝了pg_hba.conf过来文件换行符和格式可能不对末尾多了\r会让 PostgreSQL 解析失败。用file命令看看再用vim打开确认每行结尾干净。7. 让我在实战中收获最大的几个习惯离线装了这么多次 PostgreSQL 14我养成了一个习惯每次安装完成之后把/opt/pg14_rpm这个目录打包留存一份标注好操作系统版本、CPU 架构、PostgreSQL 小版本号、依赖包清单。因为内网环境往往不止一套系统可能过两个月又冒出来一台同版本的服务器要装同样的数据库这时候直接把之前的包拿出来建源十分钟就能搞定不需要再跑到有网机器上重新拉一遍。再有一个习惯就是 deployments.md 一类的运维文档我坚持每次更新。PostgreSQL 离线安装最重要的记录不是“装好了”而是“改了哪些配置、为什么改”。比如shared_buffers是从 128MB 提到了 1GB原因是应用侧有大量的并发读请求pg_hba.conf 放行了哪个网段是给哪个应用系统提供的访问入口。这些信息如果不记下来等到半年后排查慢查询或者做安全审计的时候你会发现自己对着配置文件一脸茫然。还一个特别容易被忽略的小技巧在离线服务器上用psql -c SELECT version();输出结果前先su - postgres切换用户。很多人习惯直接在 root 下执行psql -U postgres然后遇到 peer 认证失败就蒙了。这个点我在前面提过一次但值得再强调一遍因为这是新手最容易卡住的地方。其实 PostgreSQL 的设计哲学一直都很清晰系统用户和数据库用户分开管理本地维护走 peer 认证远程访问走密码认证只要理解了这套逻辑很多看似奇怪的报错都能迎刃而解。最后留个建议离线环境里备份恢复方案一定提前做好。PostgreSQL 14 的在线备份和恢复工具链比较成熟建议把pg_dump、archive_command和定时备份脚本在部署当天就配好别等到数据出了问题时才开始研究。离线环境补救手段有限未雨绸缪比什么都重要。