干我们这行的人几乎都遇到过这种局面应用要上线数据库要装但服务器在客户机房里整个内网跟外网之间是物理隔离的U盘拷个安装包进去容易难的是装到一半发现缺这个依赖、少那个库报错信息翻来覆去就那几行英文可你连个查找资料的入口都没有。PostgreSQL 14 的离线安装就是这么一件“看起来不难做起来扎心”的活儿。这篇文章就是来解决这个问题的。我会把整个流程拆成一条完整可执行的路径从在有网机器上怎么把安装包和依赖一次性收齐到内网服务器上怎么通过本地 yum 源干净利落地装好再到 postgresql.conf 和 pg_hba.conf 这两个核心配置文件的改法最后把我在生产环境里真正踩过的坑按“现象—原因—解法”列出来。无论你是第一次碰 PostgreSQL 的开发者还是被交付项目逼着写离线部署方案的运维照着这篇走能少走很多弯路。文章以 RHEL/CentOS/Rocky Linux 这一系的操作系统为例因为这种环境在离线部署里出现频率最高Debian/Ubuntu 系我会在对应位置单独提示差异。PG 版本以 14.x 为主但不影响你迁移思路到其他版本。1. 离线部署的整体思路与环境准备1.1 为什么非得离线装 PG14PostgreSQL 14 不是一个新版本但它是一个非常稳定的生产版本。相比更早的 11、1214 在 VACUUM 性能、逻辑复制稳定性、JSONB 路径查询、并行查询能力这些方面都有明显改进。很多还在用老版本的项目趁着离线迁移的机会直接切到 14是很常见的操作。离线安装的难点从来不是“装不上”而是“依赖闭环”。PostgreSQL 编译和运行依赖很多底层的库比如 readline、zlib、libicu 这些。在线环境一条yum install就能把所有东西自动拉下来但在内网里yum 源是死的依赖一旦缺一个安装就卡死在那里。所以离线部署的核心就是在有网的环境里把目标机器需要的东西提前准备好打包带进去再在离线机器上构建一个本地源模拟出“在线安装”的效果。这次选择的路线是“RPM 包 本地 yum 源”我不推荐在内网生产环境里用源码编译 PostgreSQL原因后面会说清楚。1.2 装之前先回答五个问题启动任何安装操作之前先花十分钟搞清楚环境信息这一步能省下之后数小时的排查时间。操作系统和版本执行cat /etc/os-release或者cat /etc/centos-release。确认是 EL7 还是 EL8 还是 EL9不同大版本的仓库地址和配置方式不一样。硬件架构执行uname -m。常见的 x86_64 和 aarch64 对应的 RPM 包不相同下载时候别选错。内存和磁盘执行free -h和df -h。内存大小直接决定后面 shared_buffers 这些参数怎么设。数据目录所在分区要单独评估建议按未来两到三年的数据增长量来预留空间别把数据目录跟根分区挤在一起。端口和残留版本执行rpm -qa | grep postgres和ss -lnpt | grep 5432。如果机器上已经装过别的 PostgreSQL 版本或者 5432 端口被占用那要么卸载旧的要么后面配置时换端口。locale 和字符集执行echo $LANG和locale -a。数据库的字符集在初始化时就要定型后面再改非常痛苦。还有一个忠告如果是在虚拟化环境里做第一次部署建议先做一个虚拟机快照。离线安装一旦把系统搞坏了没有外网意味着你连很多修复工具都装不了快照是唯一的后悔药。2. 有网机器上的三件事下载、整理、校验2.1 先选定安装方式RPM、二进制与源码怎么选离线安装 PostgreSQL 有三种主流方式很多人一上来就选源码编译其实是掉进了“看起来可控、实际最麻烦”的坑。安装方式适合场景优点缺点RPM 包 本地 yum 源生产环境主流选择系统版本相对标准安装速度快、依赖关系由 yum 自动处理、卸载干净、后续小版本升级方便需要提前把依赖 RPM 包准备齐全源码编译需要定制安装路径、定制编译参数定制性最强、不依赖系统包管理器耗时长、依赖 GCC 等工具链、升级时还得重新编译官方二进制包不想碰 RPM 依赖、只需要解压即用部署简单、目录可控对 glibc 版本敏感、目录管理不便、升级路径不清晰如果你面对的是 CentOS 7、Rocky Linux 8 这类常见系统我的建议非常明确用 RPM 方式。你在有网机器上把 postgresql14-server 和它的所有依赖用工具一次性拉下来传到内网之后配合 createrepo 构建本地源后面一台机器装完其他机器还能复用同一个源这是最省心的路径。2.2 在能上网的机器上下载全套 RPM这一步在有外网的跳板机或者测试机上进行。先把 PostgreSQL 官方的 yum 仓库配置好。以 EL8 为例执行yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm装完仓库之后确认yum能看到 PostgreSQL 14 的包yum list available | grep postgresql14然后安装yum-utils这个工具包里包含yumdownloader它能帮我们把所有依赖一次性拉全yum install -y yum-utils创建目录并下载。核心包是服务端和扩展包我建议把客户端和开发包也一起下下来后面装扩展的时候就不用再跑一趟mkdir -p /opt/pg14-rpms yumdownloader --resolve --destdir/opt/pg14-rpms \ postgresql14-server \ postgresql14-contrib \ postgresql14 \ postgresql14-libs \ postgresql14-devel--resolve参数的作用是分析所有依赖并一并下载。下载完成后检查一下目录里有没有这些关键 RPMpostgresql14-server、postgresql14、postgresql14-libs、postgresql14-contrib、postgresql14-devel。这些是主力包如果少了任何一个后面都会出问题。Debian/Ubuntu 系的读者注意了你们对应的做法是apt-get download配合apt-rdepends去递归收集.deb包然后把目录做成本地源用apt install ./xxx.deb的方式安装思路完全一致就是命令体系不同。2.3 构建本地 yum 源并上传校验把/opt/pg14-rpms整个目录传到内网服务器之后先别急着安装。内网机器上执行md5sum对关键包做一次校验确认传输过程中没有损坏md5sum /opt/pg14-rpms/*.rpm | less把输出结果和下载时的校验值比对。这一步很多人跳过但离线环境里传输工具五花八门U盘、ftp、内网文件服务器万一拷贝出来一个损坏的 RPM安装时就会报出莫名其妙的错误排查起来极其痛苦。接下来用createrepo把这个目录变成一个 yum 源。先安装工具yum install -y createrepo如果内网机器上连createrepo都装不了那就在有网机器上把这个包也下载下来带进去。执行createrepo /opt/pg14-rpms这个命令会自动生成repodata目录里面存放仓库的元数据。然后写一个 repo 文件vi /etc/yum.repos.d/pg14-local.repo内容如下[pg14-local] namePostgreSQL 14 Local Repository baseurlfile:///opt/pg14-rpms gpgcheck0 enabled1然后刷新缓存yum clean all yum makecache yum repolist看到pg14-local出现在仓库列表里就说明本地源已经生效。这里解释一下为什么要费劲构建本地源而不是直接rpm -ivh手动安装RPM 包之间存在依赖顺序手动安装时顺序不对就会报依赖错误而通过 yum 安装可以让系统自动判断依赖关系另外以后如果 PG 出了新的小版本补丁你只需要把新版 RPM 下载回来替换到目录里重新执行createrepo就能用统一的yum update完成升级。3. 服务器上的正式安装与初始化3.1 通过本地 yum 源一键安装本地源配置好之后安装命令非常简单yum install -y postgresql14-server postgresql14-contribyum 会自动从本地源里找到 postgresql14-server 以及它的所有依赖并完成安装。装完之后用下面几条命令验证rpm -qa | grep postgresql14 psql --version输出里应该能看到postgresql14-server、postgresql14-libs等包以及psql (PostgreSQL) 14.x的版本信息。接下来确认安装路径。RPM 方式安装后核心文件分布在几个固定位置可执行文件目录/usr/pgsql-14/bin/数据目录/var/lib/pgsql/14/data/配置文件目录/var/lib/pgsql/14/data/postgresql.conf、pg_hba.conf 都在这里日志目录/var/log/postgresql/某些发行版略有差异其中最容易忽略的是/var/lib/pgsql/14/data这个目录所有核心配置和数据库文件都在这下面后面所有的改配置、看日志、做备份几乎都绕不开它。3.2 初始化数据库目录为什么用官方脚本而不是手动 initdbRPM 安装完成后系统会创建postgres这个系统用户但数据目录还没有初始化。此时你需要执行官方提供的初始化脚本/usr/pgsql-14/bin/postgresql-14-setup initdb脚本执行成功后会提示数据目录已经创建好。等价的底层命令是这样一条su - postgres -c /usr/pgsql-14/bin/initdb -D /var/lib/pgsql/14/data --encodingUTF8 --localeC为什么不建议直接用initdb我在生产环境踩过一次真实的坑手动用 root 用户去执行 initdb初始化出来的文件属主全是 root启动时 PG 进程以 postgres 用户身份运行根本读不了这些文件然后 systemd 服务就一直报Permission denied。而官方脚本会提前把目录属主和权限处理好省掉这些低级错误。如果你的业务场景需要中文排序或者中文文本处理初始化时的 locale 可以选zh_CN.UTF-8前提是系统里已经用locale -a确认过这个 locale 存在。如果对排序规则没有特殊要求统一用--localeC或者--localeen_US.UTF-8最稳性能也更好。初始化完成后看一眼数据目录结构里面有几个关键文件postgresql.conf服务配置、pg_hba.conf访问认证配置、PG_VERSION版本标识文件、base/目录数据库物理文件。确认这些文件存在属主是 postgres再往后走。3.3 启动服务并创建业务账号初始化之后先别急着配远程先把服务拉起来确认本地能连。systemctl enable --now postgresql-14 systemctl status postgresql-14如果状态是active (running)服务就起来了。切换成 postgres 用户进入数据库命令行su - postgres psql先给默认的超级用户设置一个强密码这一步在刚初始化完、还没暴露外网端口的时候做最安全ALTER USER postgres PASSWORD 在这里填一个强密码;然后创建业务账号和业务数据库。生产环境的原则是不要让业务应用直接使用超级用户 postgres而是单独建一个权限受限的账号CREATE USER app_user WITH PASSWORD 在这里填业务密码; CREATE DATABASE app_db OWNER app_user;如果业务代码里用到了gen_random_uuid()这类函数还需要在数据库里启用扩展\c app_db CREATE EXTENSION IF NOT EXISTS pgcrypto;PG14 里gen_random_uuid()默认在 pgcrypto 扩展里虽然 PG13 以后核心库已经内置了这个函数但很多旧代码还是依赖 pgcrypto提前装上没坏处。前面这些操作都在本地完成接下来才进入最关键的配置环节。4. 配置文件详解与实践建议4.1 postgresql.conf 三个必改参数/var/lib/pgsql/14/data/postgresql.conf是 PG 的主配置文件。安装后的默认配置非常保守只能本机访问内存参数也偏小。生产环境至少要改下面几个参数。第一是监听地址。默认值是localhost这会导致外部机器无论怎么配都连不上。改成listen_addresses *有些人只改这一处还连不上那是因为忘了它还受防火墙和 pg_hba.conf 的双重约束。第二是端口。默认 5432如果这台机器已经有其他服务占了 5432可以改成 5433、55432 这种不常用的端口。修改端口之后需要重启 PG 才能生效。第三是最大连接数。max_connections默认值是 100如果应用侧的连接池配置了更高的连接数这里就要同步调大。注意这个参数不是越大越好每个连接都会占用内存盲目调到 1000 以上很容易把服务器内存吃光。内存参数这里单独说一下。PostgreSQL 的内存体系里shared_buffers是所有进程共享的缓冲区work_mem是每个会话做排序、哈希操作时用的私有内存effective_cache_size是一个估算值帮助优化器判断系统有多少缓存可用于磁盘 IO。这三者不能凭感觉设我按一台 8G 内存的服务器给你一个参考参数建议值计算思路shared_buffers2GB物理内存的 25% 左右PG 官方建议的比例effective_cache_size6GB物理内存的 50% 到 75%供优化器做估算work_mem32MB默认 4MB 太小但单实例并发高时不能盲目调大否则内存爆炸计算work_mem的一个粗估公式是(可用内存 - shared_buffers) / (max_connections × 2)。8G 内存、100 连接的情况下大约是(8-2)×1024/(100×2)≈30MB所以上面取 32MB 是有依据的。如果连接数更大优先控制业务侧的连接池而不是无脑调大 work_mem。修改配置之后不一定要立即重启。postgresql.conf里的参数分两类一类支持reload热加载比如listen_addresses、max_connections之外的很多参数另一类必须重启比如max_connections。用下面命令热加载su - postgres -c psql -c SELECT pg_reload_conf();或者直接执行systemctl reload postgresql-14另外PG14 之后可以用ALTER SYSTEM SET来修改参数它会把配置写入postgresql.auto.conf文件并覆盖主配置文件的对应项。用这种方式做临时调整很方便但新手容易忘记这个文件的存在最后排查问题时看到主配置文件没问题、实际参数不对就会一头雾水。我建议还是直接改主配置文件。4.2 pg_hba.conf 认证规则详解如果说 postgresql.conf 决定了 PG“能不能提供服务”那 pg_hba.conf 就决定了“谁能来访问”。文件路径是/var/lib/pgsql/14/data/pg_hba.conf。每一行的格式是type database user address auth-method一条典型的生产环境配置长这样host app_db app_user 192.168.1.0/24 scram-sha-256含义是允许来自192.168.1.0/24网段的客户端以app_user账号访问app_db数据库认证方式用scram-sha-256。常见的认证方式有几种trust完全不校验密码只要网络可达就能连。只适合本地测试生产环境谁用谁出事。md5老版本客户端常用不安全PG14 官方默认已经不推荐。scram-sha-256PG14 默认的密码加密方式安全性最高新项目一律用它。连接不上的时候最容易出问题的地方就是数据库账号密码是用scram-sha-256加密的但 pg_hba.conf 里对应行写的是md5两边算法对不上认证直接失败。改完 pg_hba.conf 之后同样执行systemctl reload postgresql-14让新规则生效。这里还有个容易忽略的细节同时扩展监听地址后你要确认防火墙放行了端口。很多内网环境防火墙策略很严不配置好客户端连数据库就会一直卡在超时。常见做法firewall-cmd --permanent --add-port5432/tcp firewall-cmd --reload如果是老式 iptables 环境iptables -I INPUT -p tcp --dport 5432 -j ACCEPT不要以为内网就可以不开防火墙很多离线环境的安全策略反而更严。4.3 WAL 与归档为备份留一条后路很多人刚把 PG 跑起来就以为完事了等到要备份恢复的时候才发现当初没配置 WAL 归档然后追悔莫及。WAL 是 PostgreSQL 的预写日志它记录了所有数据变更。基于 WAL 归档可以实现数据库恢复到任意时间点PITR这是生产环境最重要的兜底能力。在 postgresql.conf 里做如下设置wal_level replica max_wal_senders 10 archive_mode on archive_command test ! -f /backup/pg_wal_archive/%f cp %p /backup/pg_wal_archive/%fwal_level replica是 PG14 的默认值已经是生产可用级别支持流复制和归档。max_wal_senders是为了以后做主从复制预留的10 已经比较宽裕。archive_command的含义是如果归档目录里不存在同名文件就把 WAL 文件复制过去不带覆盖。有几个提醒要写在这里归档目录绝不能放在数据目录所在的同一块磁盘上否则磁盘一坏数据和归档一起没备份就形同虚设如果归档目录的磁盘空间满了PG 会直接把数据库卡死写入会阻塞所以要有监控告警有些简单场景只靠pg_basebackup做全量备份也能凑合但没有归档支持恢复到某个时间点就是奢望。5. 启动、验证与常见问题排查5.1 用 systemd 管理服务检查运行状态PG14 的 RPM 包自带 systemd 服务单元服务名称是postgresql-14。常见的操作systemctl enable --now postgresql-14 # 设置开机自启并立即启动 systemctl is-enabled postgresql-14 # 确认自启状态输出 enabled systemctl is-active postgresql-14 # 确认运行状态输出 active systemctl status postgresql-14 # 查看详细状态服务起来之后检查端口监听ss -lntp | grep 5432正常情况下会看到LISTEN状态的对外地址。然后用一台客户端机器做远程连接测试这一步很重要千万别省psql -h 服务器IP -p 5432 -U app_user -d app_db能连上说明监听、认证、防火墙整条链路都通了。连不上就按下一节的排查思路逐层检查。5.2 高频故障与排查思路离线环境里最常见的故障我把它们按“现象—原因—解法”整理成了一张速查表现象可能原因排查与解决initdb执行报错提示 locale 不支持系统没有对应的 locale执行locale -a确认改用--localeC或--encodingUTF8 --localeen_US.UTF-8systemctl start失败日志显示Permission denied数据目录属主不是 postgreschown -R postgres:postgres /var/lib/pgsql/14/data客户端连不上卡在超时防火墙没放行或者listen_addresses未改检查ss -lntp监听地址检查防火墙规则报错password authentication failed密码错误或 pg_hba.conf 认证方式与账号加密方式不一致核对密码确认scram-sha-256与账号加密一致报错database does not exist连接命令里写了不存在的数据库\l查看数据库列表确认库名拼写服务启动后很快退出配置参数不合法或者数据文件损坏查看日志文件/var/lib/pgsql/14/data/log/*.log或执行journalctl -u postgresql-14重启后连接失败防火墙规则没持久化用firewall-cmd --runtime-to-permanent固化规则这里重点说一下日志的位置。RPM 安装的 PG日志可能同时出现在两个地方systemd 的日志journalctl -u postgresql-14和 PG 数据目录下的log/子目录如果配置过logging_collector on。排查时两个都看一下报错信息往往直接告诉你是哪儿的问题。SELinux 的问题也提一下。在 CentOS/Rocky 这类系统上如果关闭 SELinux 不合理PG 的数据目录又放在了非默认路径比如/data/pgsqlSELinux 会拦截进程读写表现就是服务起不来或者写入报错。快速排查方法是执行getenforce如果是 Enforcing 状态先查一下ausearch -m avc -ts recent看有没有 AVC 拦截日志再根据日志设置正确的上下文。时间紧的时候可以临时执行setenforce 0验证是不是 SELinux 的问题但长期运行不建议直接关掉。5.3 小版本升级与后续维护建议PostgreSQL 14 的小版本更新很频繁官方会持续推送安全修复和 bug 修复。离线环境下的升级流程本质上跟安装一致在有网上下载新版的 RPM 包传给内网机器替换到本地 yum 源目录然后执行yum update postgresql14*升级前强烈建议先做一次备份。实务中比较稳妥的操作是用pg_dump把业务数据导出作为逻辑备份或者用pg_basebackup做物理备份。如果磁盘条件允许两者都做最稳。关于 PostgreSQL 14 的生命周期这里要给长期运行的系统提个醒从 2021 年发布算起它的社区支持周期是五年左右。如果你的系统规划要运行到生命周期结束之后建议提前规划升级到更高版本的路线。离线环境下版本跨度越大升级步骤越复杂不要等到 EOL 之后再火急火燎地处理。最后再分享几点实操心得离线安装 PG 的次数多了我有几个固定的习惯每次都能帮我省大量时间。第一个习惯是把下载好的 RPM 包按照“服务端、客户端、依赖、扩展”四类分开放到不同子目录构建本地源的时候方便排查哪个包缺失。第二个习惯是每台机器装完之后马上把psql --version、systemctl status、远程连接测试三条命令的输出保存下来写进交付文档一目了然。第三个习惯最容易被忽略把/opt/pg14-rpms这个目录保留下来不要以为装完就没用了。后面补装扩展、升级小版本全都要靠它。我已经不止一次收到同事的求助“机器上要装个插件但 yum 源没了原目录也删了怎么办”这种情况只能重新找有网环境打包再传一遍非常浪费时间。最后如果条件允许建议用一台有网的虚拟机把整个流程从头到尾在通用系统里跑一遍留意每个报错信息再去客户的离线环境里部署。PG 的离线安装本身并不复杂复杂的是你永远不知道对方机器的系统环境里藏了多少跟标准环境不一样的细节。提前演练一遍心里有底现场才不会慌。