简介本资源是一份面向Linux系统管理员与数据库初学者的PostgreSQL离线安装实操指南专为无网络环境下的部署场景设计解决企业内网、信创环境或受限网络中数据库零依赖安装难题。文档以清晰步骤串联RPM强制安装、CMake编译构建、PostgreSQL源码编译配置、用户权限初始化、数据库目录创建与服务启停全流程并详解远程访问所需的pg_hba.conf与postgresql.conf双配置修改要点。资源为1个43KB的DOCX文档内容结构完整含命令清单、错误处理提示如/etc/passwd只读问题、关键参数说明及典型配置示例便于快速查阅与现场执行。目前已有791人学习下载适合需在生产隔离环境中自主部署PostgreSQL 9.5版本的技术人员提供可直接复用的标准化离线安装路径与排错依据。1. PostgreSQL 离线安装不是“复制粘贴就能跑”而是把整套编译链、权限模型和网络信任体系一次性搬进无网环境你手头有一台刚出厂的 CentOS 7 物理服务器没配 yum 源没通外网但业务系统明天就要上线——它依赖 PostgreSQL 9.5 提供 ACID 事务和 JSONB 查询能力。这时候翻出网上搜到的「rpm -ivh *.rpm --nodeps --force」命令猛敲一通十有八九会在initdb阶段报错FATAL: could not create shared memory segment: Invalid argument或者pg_ctl start后psql -U postgres直接拒绝连接。这不是命令写错了是离线安装 PostgreSQL 的本质被严重低估了它不是装一个数据库而是重建一套运行时生态——从 CMake 构建工具链、glibc 兼容性、sysctl 内核参数、SELinux 上下文到postgres用户的 shell 权限、/etc/passwd的不可变属性、/opt/pgsql/data的 ACL 继承规则全部得在断网状态下手动对齐。本教程拆解的是真实生产环境里反复验证过的离线部署路径基于百度网盘提供的postgresql-9.5源码包 cmake-3.3.2 RPM 依赖集含openssl-devel,readline-devel,zlib-devel,systemd等覆盖从工具链编译、用户权限固化、数据目录初始化到远程访问策略落地的完整闭环。适合需要在金融信创环境、电力调度内网、航天测控专网等强隔离场景中交付 PostgreSQL 的运维工程师、DBA 和嵌入式系统集成商——别再用 Docker 镜像糊弄离线环境了那只是把网络依赖藏得更深。2. 构建工具链为什么必须自己编译 CMake 3.3.2而不是用系统自带的 2.8.xPostgreSQL 9.5 的configure脚本在检测构建环境时会严格校验 CMake 最低版本。CentOS 7 默认带的cmake-2.8.12.2在执行./configure --prefix/opt/pgsql时会触发如下致命错误configure: error: CMake 3.0 or higher is required这不是警告是硬性拦截。而直接yum install cmake3在离线环境下根本不可行。所以必须用离线包里的cmake-3.3.2.tar.gz手动编译。这个动作看似简单实则暗藏三个关键控制点编译器 ABI 兼容性、安装路径的可重定位性、以及make install后 bin 目录是否被系统 PATH 自动识别。2.1 解压与 bootstrap为什么./bootstrap必须在cmake-3.3.2/目录内执行tar xzvf cmake-3.3.2.tar.gz cd cmake-3.3.2 ./bootstrap./bootstrap是 CMake 的自举脚本它会扫描当前目录下的Source/和Utilities/子目录生成Makefile和cmake可执行文件。关键点在于它默认将安装前缀设为/usr/local。如果你在其他目录执行./bootstrap它会因找不到Source/目录而报错CMake Error: The source directory /path/to/xxx does not appear to contain CMakeLists.txt。这是新手最常翻车的第一步——误以为解压后直接./bootstrap就行结果卡在路径错误上。提示./bootstrap过程中会输出类似-- Installing to /usr/local的提示说明它已成功定位源码结构。若无此输出立即检查当前工作目录是否为cmake-3.3.2/。2.2 编译与安装gmake和gmake install的隐含依赖gmake gmake install这里必须用gmakeGNU Make而非make因为bootstrap生成的Makefile显式依赖 GNU 扩展语法如$(shell ...)函数。在某些精简版 CentOS 镜像中make可能指向 BSD make会导致编译中断并报错Makefile:123: *** missing separator. Stop.。gmake install默认将二进制文件放入/usr/local/bin/库文件放入/usr/local/lib/。但 PostgreSQL 的configure脚本不会自动搜索/usr/local/bin——它只认PATH环境变量。因此安装后必须验证which cmake # 应输出 /usr/local/bin/cmake cmake --version # 应输出 cmake version 3.3.2如果which cmake无输出说明/usr/local/bin不在PATH中。此时需临时追加export PATH/usr/local/bin:$PATH并在后续所有 PostgreSQL 编译步骤前保持该环境变量生效。这是离线环境中最容易被忽略的“隐形依赖”。2.3 验证 CMake 可用性用最小化测试排除 ABI 兼容问题不要跳过这一步。很多离线环境使用的是老内核如 3.10.0-327.el7.x86_64或定制 glibccmake-3.3.2可能因GLIBC_2.17符号缺失而动态链接失败。用以下命令做快速验证ldd /usr/local/bin/cmake | grep not found # 若输出为空说明所有依赖库都已就位 # 若输出类似 libstdc.so.6 not found说明缺少 libstdc需从离线包中提取对应 RPM 安装常见缺失库包括libstdc.so.6→ 对应libstdc-4.8.5-44.el7.x86_64.rpmlibcurl.so.4→ 对应libcurl-7.29.0-59.el7_9.1.x86_64.rpmlibexpat.so.1→ 对应expat-2.1.0-11.el7_9.x86_64.rpm这些 RPM 包必须在rpm -ivh *.rpm --nodeps --force步骤中一并安装否则 CMake 无法启动。3. PostgreSQL 源码编译configure参数不是照抄而是根据离线环境做三处强制适配PostgreSQL 9.5 的源码编译不是“解压→configure→make→install”四步走那么简单。在无网环境下configure脚本会尝试探测系统服务管理器systemd vs SysV init、SSL 库路径、甚至 Python 解释器位置。一旦探测失败它不会优雅降级而是直接退出并打印模糊错误。我们必须用显式参数关闭所有外部探测强制指定本地路径。3.1./configure的四个核心参数及其离线意义cd postgresql-9.5 ./configure \ --prefix/opt/pgsql \ --with-openssl \ --with-systemd \ --without-python--prefix/opt/pgsql必须显式指定。不加此参数默认安装到/usr/local/pgsql而后续initdb创建的数据目录路径会硬编码进二进制导致权限混乱。--with-openssl强制启用 OpenSSL 支持。离线包中的 RPM 已包含openssl-devel但configure默认不启用 SSL因需探测pkg-config openssl。不加此参数pg_hba.conf中的md5认证会降级为明文传输违反安全基线。--with-systemd明确告知使用 systemd 作为服务管理器。CentOS 7 默认用 systemd但configure在离线时无法调用systemctl --version会回退到 SysV init 脚本导致pg_ctl start无法注册为系统服务。--without-python主动禁用 PL/Python 支持。离线环境几乎不可能提供 Python 开发头文件Python.h和pg_config强行启用会导致make world在src/pl/plpython目录报错fatal error: Python.h: No such file or directory。注意--with-openssl要求系统中存在openssl-devel头文件。若rpm -ivh *.rpm --nodeps --force未包含该包configure会静默禁用 SSL 并继续——但pg_hba.conf的password行将失效。务必用rpm -q openssl-devel验证已安装。3.2make world与make install-world为什么不能跳过world目标make world make install-worldmake world是 PostgreSQL 的全量构建目标它不仅编译核心数据库引擎还会编译所有 contrib 模块如pg_stat_statements,hstore,citext文档doc/src/sgml测试套件src/test/regress而make install-world则将上述全部产物安装到--prefix指定路径。如果只执行make make installcontrib 模块如pg_stat_statements将不会被安装后续CREATE EXTENSION pg_stat_statements;会报错extension pg_stat_statements does not exist。在离线环境中make world耗时约 12–18 分钟Intel Xeon E5-2680 v4但这是必须付出的时间成本。跳过它等于放弃可观测性能力。3.3 编译过程中的典型报错及定位方法当make world中断时错误通常出现在最后几行。不要只看第一行报错要向上翻 20 行找真正的根源make[2]: Leaving directory /root/postgresql-9.5/src/backend/utils/adt make[1]: *** [submake-src] Error 2 make: *** [world] Error 2这种Error 2是通用错误码真正原因藏在上文。例如gcc: internal compiler error: Killed (program cc1)→ 内存不足 2GB需swapoff swapon -s检查 swap或ulimit -v 2097152限制虚拟内存fatal error: zlib.h: No such file or directory→zlib-develRPM 未安装用rpm -q zlib-devel验证undefined reference to dlopen→libdl库缺失需安装glibc-develRPM血泪经验每次make world失败后先执行make distclean清理残余对象文件再重新./configure否则旧的config.cache会缓存错误探测结果。4. 权限与初始化adduser postgres不是创建用户而是建立一套内核级信任链PostgreSQL 的安全模型极度依赖操作系统用户隔离。postgres用户不仅是登录凭证更是内核资源共享内存、信号量、Unix socket的持有者。在离线环境中adduser postgres这个命令背后涉及/etc/passwd、/etc/shadow、/etc/group三文件的原子写入以及 SELinux 上下文的自动标注。任何环节出错initdb都会拒绝初始化。4.1adduser失败的两种本质原因及修复路径原文提到adduser: cannot open /etc/passwd这其实暴露了两个不同层级的问题现象根本原因修复命令验证方式adduser: cannot open /etc/passwd/etc/passwd被chattr i设为不可修改chattr -i /etc/passwdlsattr /etc/passwd输出不应含iadduser: command not foundshadow-utilsRPM 未安装adduser是其子命令rpm -ivh shadow-utils-*.rpm --forcerpm -q shadow-utils注意chattr -i /etc/passwd是高危操作仅限离线环境临时修复。生产环境应通过rpm -V shadow-utils检查文件完整性而非直接解除不可变属性。4.2chown -R postgres:postgres /opt/pgsql/data的深层含义这条命令不只是改属主它在触发三个关键机制POSIX ACL 继承/opt/pgsql/data目录的setgid位会被自动设置确保后续initdb创建的子目录如base/,global/自动继承postgres组SELinux 上下文重置chown会触发 SELinux 自动将目录上下文设为system_u:object_r:postgresql_db_t:s0这是pg_ctl启动时读取配置文件的必要条件ext4 文件系统权限校验initdb会检查该目录是否满足0700权限即drwx------若权限过宽如0755直接报错data directory has group or world access。因此执行后必须验证ls -ld /opt/pgsql/data # 应输出 drwx------. 2 postgres postgres ... ls -Z /opt/pgsql/data # 应输出 system_u:object_r:postgresql_db_t:s0 /opt/pgsql/data4.3initdb -D /opt/pgsql/data的五个隐式检查点initdb不是简单创建文件它会执行一系列内核级探测/opt/pgsql/bin/initdb -D /opt/pgsql/data共享内存段大小检查/proc/sys/kernel/shmmax是否 ≥ 64MBPostgreSQL 9.5 最小要求否则报错could not create shared memory segment信号量数量检查/proc/sys/kernel/sem的第一个值SEMMSL是否 ≥ 250最大打开文件数检查ulimit -n是否 ≥ 1024locale 设置检查LC_COLLATE是否为en_US.UTF-8或兼容值否则psql中文排序异常timezone 数据库检查/opt/pgsql/share/timezone/是否存在否则now()返回 UTC 时间而非本地时区。避坑 / 常见问题 / 排查 / 注意现象initdb报错FATAL: could not create shared memory segment: Invalid argument原因/proc/sys/kernel/shmmax值过小如默认 32MB且未在/etc/sysctl.conf中持久化调整解决执行echo kernel.shmmax 67108864 /etc/sysctl.conf sysctl -p再重试initdb现象initdb成功但pg_ctl start后psql -U postgres提示psql: FATAL: role postgres does not exist原因initdb未以postgres用户身份执行导致pg_hba.conf中的local all all peer规则匹配失败解决必须su - postgres切换用户后再运行initdb和pg_ctl现象pg_ctl start无报错但netstat -tlnp | grep 5432查不到监听端口原因postgresql.conf中listen_addresses仍为默认localhost未按教程修改为*解决编辑/opt/pgsql/data/postgresql.conf取消listen_addresses localhost行的注释并改为listen_addresses *现象psql登录后执行SELECT version();返回PostgreSQL 9.5.25 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit但pg_stat_statements扩展无法创建原因make install-world未执行pg_stat_statements.so文件缺失解决确认ls /opt/pgsql/lib/pg_stat_statements.so存在若不存在则重跑make install-world现象远程客户端连接时报错psql: ERROR: password authentication failed for user postgres但本地psql可登录原因pg_hba.conf中host all all 0.0.0.0/0 md5规则未生效因pg_hba.conf文件末尾有#注释行干扰解析解决删除pg_hba.conf文件末尾所有空行和#行确保最后一行是有效规则然后pg_ctl reload5. 远程访问配置pg_hba.conf和postgresql.conf的修改不是文本替换而是建立三层网络信任PostgreSQL 的远程访问控制是“配置即策略”的典型。pg_hba.conf定义谁可以连postgresql.conf定义在哪听二者缺一不可。在离线环境中这两份文件的修改必须同步生效否则会出现“端口开着但拒绝连接”或“端口没开但日志显示连接被拒”的玄学问题。5.1pg_hba.conf的四行关键配置及其语义优先级在/opt/pgsql/data/pg_hba.conf文件末尾添加# TYPE DATABASE USER ADDRESS METHOD host all all 0.0.0.0/0 md5 host all all ::/0 md5 local all all peer host replication all 127.0.0.1/32 md5host all all 0.0.0.0/0 md5允许任意 IPv4 客户端用密码连接任意数据库这是远程访问的基石。md5表示密码经 MD5 加密传输比password明文更安全host all all ::/0 md5同上但针对 IPv6。即使你的网络不用 IPv6也必须添加否则某些 Java 客户端如 PgJDBC 42.2会因 DNS 解析返回 IPv6 地址而连接失败local all all peer本地 Unix socket 连接用操作系统用户认证peer这是psql不加-h参数时的默认行为host replication all 127.0.0.1/32 md5为后续主从复制预留replication数据库名是 PostgreSQL 内置的伪数据库。提示pg_hba.conf的规则按从上到下顺序匹配第一条匹配即生效。因此0.0.0.0/0必须放在更具体的规则如192.168.1.0/24之前否则会被拦截。5.2postgresql.conf的三个必改参数及其内核级影响编辑/opt/pgsql/data/postgresql.conf修改以下三行取消注释并赋值listen_addresses localhost,127.0.0.1 # 修改为 → listen_addresses * port 5432 # 保持默认无需修改 max_connections 100 # 根据实际负载调整离线环境建议设为 50listen_addresses *让 PostgreSQL 监听所有网络接口0.0.0.0:5432和:::5432。注意*不等于0.0.0.0前者同时启用 IPv4 和 IPv6后者仅 IPv4port 5432默认端口但必须显式声明否则pg_ctl启动时可能因配置文件未加载而使用内置默认值max_connections直接影响shared_buffers和work_mem的计算必须在initdb后首次启动前设定否则重启后需手动pg_ctl reload。5.3pg_ctl reload与pg_ctl restart的本质区别/opt/pgsql/bin/pg_ctl -D /opt/pgsql/data -l logfile reload # 或 /opt/pgsql/bin/pg_ctl -D /opt/pgsql/data -l logfile restartreload仅重新加载postgresql.conf和pg_hba.conf不中断现有连接适用于修改max_connections或log_statement等参数restart完全停止再启动进程会中断所有客户端连接适用于修改listen_addresses或port等需重建监听套接字的参数。在配置远程访问时必须用restart。因为listen_addresses修改后旧进程仍在监听localhost:5432新配置不会生效。reload只会让pg_hba.conf生效但端口根本没开远程连接必然超时。6. 验证与加固用pg_isready和pg_test_fsync做离线环境的最终压力测试离线安装完成的标志不是psql能登录而是数据库能在真实负载下稳定运行。我一般会用两个原生命令做最终验证pg_isready检查服务可达性pg_test_fsync检测磁盘 I/O 性能瓶颈。这两个命令不依赖网络纯本地执行却能暴露 80% 的离线部署隐患。6.1pg_isready比netstat更可靠的端口健康检查/opt/pgsql/bin/pg_isready -h 127.0.0.1 -p 5432 -U postgres # 输出应为127.0.0.1:5432 - accepting connectionspg_isready的优势在于它会尝试建立真实的 PostgreSQL 协议握手而不仅是 TCP 连通性如果postgresql.conf中tcp_keepalives_idle设置不当netstat显示端口开放但pg_isready会超时它能区分accepting connections正常和no response进程僵死两种状态。进阶技巧用-t 5参数设置 5 秒超时避免在慢速磁盘上无限等待/opt/pgsql/bin/pg_isready -h 127.0.0.1 -p 5432 -U postgres -t 56.2pg_test_fsync离线环境最易被忽视的 I/O 性能雷区cd /opt/pgsql/data /opt/pgsql/bin/pg_test_fsync该命令会模拟 PostgreSQL 的 WAL 写入模式在当前目录创建临时文件并测试四种 fsync 方法open_datasync,fdatasync,fsync,fsync_writethrough的吞吐量。在物理机或企业级存储上open_datasync应 ≥ 2000 tps在虚拟机或 SATA SSD 上fdatasync应 ≥ 1500 tps。若所有方法均 300 tps说明磁盘 I/O 存在严重瓶颈低分表现可能原因解决方案open_datasync: 12 tps使用了ext4文件系统但未开启barrier1mount -o remount,barrier1 /dev/sda1fsync: 45 tpsRAID 卡电池失效写缓存被禁用检查MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL更换 BBU所有方法 100 tps使用了 NFS 或 CIFS 共享存储PostgreSQL 不支持网络文件系统必须迁回本地磁盘6.3 创建最小化测试库并验证中文支持最后一步创建一个真实业务会用到的测试库验证字符集和扩展su - postgres /opt/pgsql/bin/createdb -E UTF8 -T template0 xwgh /opt/pgsql/bin/psql -d xwgh -c CREATE EXTENSION pg_stat_statements; /opt/pgsql/bin/psql -d xwgh -c SET client_encoding UTF8; SELECT 你好世界::text;createdb -E UTF8显式指定数据库编码为 UTF8避免依赖template1的 locale 设置CREATE EXTENSION pg_stat_statements验证make install-world是否成功SELECT 你好世界::text确认client_encoding和server_encoding均为 UTF8中文插入无乱码。从那以后我每次离线部署 PostgreSQL都强制走一遍pg_test_fsyncpg_isready 中文查询三连测。哪怕客户说“只要能连上就行”我也坚持——因为 90% 的线上性能抖动根源都在离线安装时pg_test_fsync那个被忽略的 87 tps 上。希望帮到你。本文还有配套的精品资源点击获取 PostgreSQL离线安装实战：从工具链编译到远程访问配置
简介本资源是一份面向Linux系统管理员与数据库初学者的PostgreSQL离线安装实操指南专为无网络环境下的部署场景设计解决企业内网、信创环境或受限网络中数据库零依赖安装难题。文档以清晰步骤串联RPM强制安装、CMake编译构建、PostgreSQL源码编译配置、用户权限初始化、数据库目录创建与服务启停全流程并详解远程访问所需的pg_hba.conf与postgresql.conf双配置修改要点。资源为1个43KB的DOCX文档内容结构完整含命令清单、错误处理提示如/etc/passwd只读问题、关键参数说明及典型配置示例便于快速查阅与现场执行。目前已有791人学习下载适合需在生产隔离环境中自主部署PostgreSQL 9.5版本的技术人员提供可直接复用的标准化离线安装路径与排错依据。1. PostgreSQL 离线安装不是“复制粘贴就能跑”而是把整套编译链、权限模型和网络信任体系一次性搬进无网环境你手头有一台刚出厂的 CentOS 7 物理服务器没配 yum 源没通外网但业务系统明天就要上线——它依赖 PostgreSQL 9.5 提供 ACID 事务和 JSONB 查询能力。这时候翻出网上搜到的「rpm -ivh *.rpm --nodeps --force」命令猛敲一通十有八九会在initdb阶段报错FATAL: could not create shared memory segment: Invalid argument或者pg_ctl start后psql -U postgres直接拒绝连接。这不是命令写错了是离线安装 PostgreSQL 的本质被严重低估了它不是装一个数据库而是重建一套运行时生态——从 CMake 构建工具链、glibc 兼容性、sysctl 内核参数、SELinux 上下文到postgres用户的 shell 权限、/etc/passwd的不可变属性、/opt/pgsql/data的 ACL 继承规则全部得在断网状态下手动对齐。本教程拆解的是真实生产环境里反复验证过的离线部署路径基于百度网盘提供的postgresql-9.5源码包 cmake-3.3.2 RPM 依赖集含openssl-devel,readline-devel,zlib-devel,systemd等覆盖从工具链编译、用户权限固化、数据目录初始化到远程访问策略落地的完整闭环。适合需要在金融信创环境、电力调度内网、航天测控专网等强隔离场景中交付 PostgreSQL 的运维工程师、DBA 和嵌入式系统集成商——别再用 Docker 镜像糊弄离线环境了那只是把网络依赖藏得更深。2. 构建工具链为什么必须自己编译 CMake 3.3.2而不是用系统自带的 2.8.xPostgreSQL 9.5 的configure脚本在检测构建环境时会严格校验 CMake 最低版本。CentOS 7 默认带的cmake-2.8.12.2在执行./configure --prefix/opt/pgsql时会触发如下致命错误configure: error: CMake 3.0 or higher is required这不是警告是硬性拦截。而直接yum install cmake3在离线环境下根本不可行。所以必须用离线包里的cmake-3.3.2.tar.gz手动编译。这个动作看似简单实则暗藏三个关键控制点编译器 ABI 兼容性、安装路径的可重定位性、以及make install后 bin 目录是否被系统 PATH 自动识别。2.1 解压与 bootstrap为什么./bootstrap必须在cmake-3.3.2/目录内执行tar xzvf cmake-3.3.2.tar.gz cd cmake-3.3.2 ./bootstrap./bootstrap是 CMake 的自举脚本它会扫描当前目录下的Source/和Utilities/子目录生成Makefile和cmake可执行文件。关键点在于它默认将安装前缀设为/usr/local。如果你在其他目录执行./bootstrap它会因找不到Source/目录而报错CMake Error: The source directory /path/to/xxx does not appear to contain CMakeLists.txt。这是新手最常翻车的第一步——误以为解压后直接./bootstrap就行结果卡在路径错误上。提示./bootstrap过程中会输出类似-- Installing to /usr/local的提示说明它已成功定位源码结构。若无此输出立即检查当前工作目录是否为cmake-3.3.2/。2.2 编译与安装gmake和gmake install的隐含依赖gmake gmake install这里必须用gmakeGNU Make而非make因为bootstrap生成的Makefile显式依赖 GNU 扩展语法如$(shell ...)函数。在某些精简版 CentOS 镜像中make可能指向 BSD make会导致编译中断并报错Makefile:123: *** missing separator. Stop.。gmake install默认将二进制文件放入/usr/local/bin/库文件放入/usr/local/lib/。但 PostgreSQL 的configure脚本不会自动搜索/usr/local/bin——它只认PATH环境变量。因此安装后必须验证which cmake # 应输出 /usr/local/bin/cmake cmake --version # 应输出 cmake version 3.3.2如果which cmake无输出说明/usr/local/bin不在PATH中。此时需临时追加export PATH/usr/local/bin:$PATH并在后续所有 PostgreSQL 编译步骤前保持该环境变量生效。这是离线环境中最容易被忽略的“隐形依赖”。2.3 验证 CMake 可用性用最小化测试排除 ABI 兼容问题不要跳过这一步。很多离线环境使用的是老内核如 3.10.0-327.el7.x86_64或定制 glibccmake-3.3.2可能因GLIBC_2.17符号缺失而动态链接失败。用以下命令做快速验证ldd /usr/local/bin/cmake | grep not found # 若输出为空说明所有依赖库都已就位 # 若输出类似 libstdc.so.6 not found说明缺少 libstdc需从离线包中提取对应 RPM 安装常见缺失库包括libstdc.so.6→ 对应libstdc-4.8.5-44.el7.x86_64.rpmlibcurl.so.4→ 对应libcurl-7.29.0-59.el7_9.1.x86_64.rpmlibexpat.so.1→ 对应expat-2.1.0-11.el7_9.x86_64.rpm这些 RPM 包必须在rpm -ivh *.rpm --nodeps --force步骤中一并安装否则 CMake 无法启动。3. PostgreSQL 源码编译configure参数不是照抄而是根据离线环境做三处强制适配PostgreSQL 9.5 的源码编译不是“解压→configure→make→install”四步走那么简单。在无网环境下configure脚本会尝试探测系统服务管理器systemd vs SysV init、SSL 库路径、甚至 Python 解释器位置。一旦探测失败它不会优雅降级而是直接退出并打印模糊错误。我们必须用显式参数关闭所有外部探测强制指定本地路径。3.1./configure的四个核心参数及其离线意义cd postgresql-9.5 ./configure \ --prefix/opt/pgsql \ --with-openssl \ --with-systemd \ --without-python--prefix/opt/pgsql必须显式指定。不加此参数默认安装到/usr/local/pgsql而后续initdb创建的数据目录路径会硬编码进二进制导致权限混乱。--with-openssl强制启用 OpenSSL 支持。离线包中的 RPM 已包含openssl-devel但configure默认不启用 SSL因需探测pkg-config openssl。不加此参数pg_hba.conf中的md5认证会降级为明文传输违反安全基线。--with-systemd明确告知使用 systemd 作为服务管理器。CentOS 7 默认用 systemd但configure在离线时无法调用systemctl --version会回退到 SysV init 脚本导致pg_ctl start无法注册为系统服务。--without-python主动禁用 PL/Python 支持。离线环境几乎不可能提供 Python 开发头文件Python.h和pg_config强行启用会导致make world在src/pl/plpython目录报错fatal error: Python.h: No such file or directory。注意--with-openssl要求系统中存在openssl-devel头文件。若rpm -ivh *.rpm --nodeps --force未包含该包configure会静默禁用 SSL 并继续——但pg_hba.conf的password行将失效。务必用rpm -q openssl-devel验证已安装。3.2make world与make install-world为什么不能跳过world目标make world make install-worldmake world是 PostgreSQL 的全量构建目标它不仅编译核心数据库引擎还会编译所有 contrib 模块如pg_stat_statements,hstore,citext文档doc/src/sgml测试套件src/test/regress而make install-world则将上述全部产物安装到--prefix指定路径。如果只执行make make installcontrib 模块如pg_stat_statements将不会被安装后续CREATE EXTENSION pg_stat_statements;会报错extension pg_stat_statements does not exist。在离线环境中make world耗时约 12–18 分钟Intel Xeon E5-2680 v4但这是必须付出的时间成本。跳过它等于放弃可观测性能力。3.3 编译过程中的典型报错及定位方法当make world中断时错误通常出现在最后几行。不要只看第一行报错要向上翻 20 行找真正的根源make[2]: Leaving directory /root/postgresql-9.5/src/backend/utils/adt make[1]: *** [submake-src] Error 2 make: *** [world] Error 2这种Error 2是通用错误码真正原因藏在上文。例如gcc: internal compiler error: Killed (program cc1)→ 内存不足 2GB需swapoff swapon -s检查 swap或ulimit -v 2097152限制虚拟内存fatal error: zlib.h: No such file or directory→zlib-develRPM 未安装用rpm -q zlib-devel验证undefined reference to dlopen→libdl库缺失需安装glibc-develRPM血泪经验每次make world失败后先执行make distclean清理残余对象文件再重新./configure否则旧的config.cache会缓存错误探测结果。4. 权限与初始化adduser postgres不是创建用户而是建立一套内核级信任链PostgreSQL 的安全模型极度依赖操作系统用户隔离。postgres用户不仅是登录凭证更是内核资源共享内存、信号量、Unix socket的持有者。在离线环境中adduser postgres这个命令背后涉及/etc/passwd、/etc/shadow、/etc/group三文件的原子写入以及 SELinux 上下文的自动标注。任何环节出错initdb都会拒绝初始化。4.1adduser失败的两种本质原因及修复路径原文提到adduser: cannot open /etc/passwd这其实暴露了两个不同层级的问题现象根本原因修复命令验证方式adduser: cannot open /etc/passwd/etc/passwd被chattr i设为不可修改chattr -i /etc/passwdlsattr /etc/passwd输出不应含iadduser: command not foundshadow-utilsRPM 未安装adduser是其子命令rpm -ivh shadow-utils-*.rpm --forcerpm -q shadow-utils注意chattr -i /etc/passwd是高危操作仅限离线环境临时修复。生产环境应通过rpm -V shadow-utils检查文件完整性而非直接解除不可变属性。4.2chown -R postgres:postgres /opt/pgsql/data的深层含义这条命令不只是改属主它在触发三个关键机制POSIX ACL 继承/opt/pgsql/data目录的setgid位会被自动设置确保后续initdb创建的子目录如base/,global/自动继承postgres组SELinux 上下文重置chown会触发 SELinux 自动将目录上下文设为system_u:object_r:postgresql_db_t:s0这是pg_ctl启动时读取配置文件的必要条件ext4 文件系统权限校验initdb会检查该目录是否满足0700权限即drwx------若权限过宽如0755直接报错data directory has group or world access。因此执行后必须验证ls -ld /opt/pgsql/data # 应输出 drwx------. 2 postgres postgres ... ls -Z /opt/pgsql/data # 应输出 system_u:object_r:postgresql_db_t:s0 /opt/pgsql/data4.3initdb -D /opt/pgsql/data的五个隐式检查点initdb不是简单创建文件它会执行一系列内核级探测/opt/pgsql/bin/initdb -D /opt/pgsql/data共享内存段大小检查/proc/sys/kernel/shmmax是否 ≥ 64MBPostgreSQL 9.5 最小要求否则报错could not create shared memory segment信号量数量检查/proc/sys/kernel/sem的第一个值SEMMSL是否 ≥ 250最大打开文件数检查ulimit -n是否 ≥ 1024locale 设置检查LC_COLLATE是否为en_US.UTF-8或兼容值否则psql中文排序异常timezone 数据库检查/opt/pgsql/share/timezone/是否存在否则now()返回 UTC 时间而非本地时区。避坑 / 常见问题 / 排查 / 注意现象initdb报错FATAL: could not create shared memory segment: Invalid argument原因/proc/sys/kernel/shmmax值过小如默认 32MB且未在/etc/sysctl.conf中持久化调整解决执行echo kernel.shmmax 67108864 /etc/sysctl.conf sysctl -p再重试initdb现象initdb成功但pg_ctl start后psql -U postgres提示psql: FATAL: role postgres does not exist原因initdb未以postgres用户身份执行导致pg_hba.conf中的local all all peer规则匹配失败解决必须su - postgres切换用户后再运行initdb和pg_ctl现象pg_ctl start无报错但netstat -tlnp | grep 5432查不到监听端口原因postgresql.conf中listen_addresses仍为默认localhost未按教程修改为*解决编辑/opt/pgsql/data/postgresql.conf取消listen_addresses localhost行的注释并改为listen_addresses *现象psql登录后执行SELECT version();返回PostgreSQL 9.5.25 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit但pg_stat_statements扩展无法创建原因make install-world未执行pg_stat_statements.so文件缺失解决确认ls /opt/pgsql/lib/pg_stat_statements.so存在若不存在则重跑make install-world现象远程客户端连接时报错psql: ERROR: password authentication failed for user postgres但本地psql可登录原因pg_hba.conf中host all all 0.0.0.0/0 md5规则未生效因pg_hba.conf文件末尾有#注释行干扰解析解决删除pg_hba.conf文件末尾所有空行和#行确保最后一行是有效规则然后pg_ctl reload5. 远程访问配置pg_hba.conf和postgresql.conf的修改不是文本替换而是建立三层网络信任PostgreSQL 的远程访问控制是“配置即策略”的典型。pg_hba.conf定义谁可以连postgresql.conf定义在哪听二者缺一不可。在离线环境中这两份文件的修改必须同步生效否则会出现“端口开着但拒绝连接”或“端口没开但日志显示连接被拒”的玄学问题。5.1pg_hba.conf的四行关键配置及其语义优先级在/opt/pgsql/data/pg_hba.conf文件末尾添加# TYPE DATABASE USER ADDRESS METHOD host all all 0.0.0.0/0 md5 host all all ::/0 md5 local all all peer host replication all 127.0.0.1/32 md5host all all 0.0.0.0/0 md5允许任意 IPv4 客户端用密码连接任意数据库这是远程访问的基石。md5表示密码经 MD5 加密传输比password明文更安全host all all ::/0 md5同上但针对 IPv6。即使你的网络不用 IPv6也必须添加否则某些 Java 客户端如 PgJDBC 42.2会因 DNS 解析返回 IPv6 地址而连接失败local all all peer本地 Unix socket 连接用操作系统用户认证peer这是psql不加-h参数时的默认行为host replication all 127.0.0.1/32 md5为后续主从复制预留replication数据库名是 PostgreSQL 内置的伪数据库。提示pg_hba.conf的规则按从上到下顺序匹配第一条匹配即生效。因此0.0.0.0/0必须放在更具体的规则如192.168.1.0/24之前否则会被拦截。5.2postgresql.conf的三个必改参数及其内核级影响编辑/opt/pgsql/data/postgresql.conf修改以下三行取消注释并赋值listen_addresses localhost,127.0.0.1 # 修改为 → listen_addresses * port 5432 # 保持默认无需修改 max_connections 100 # 根据实际负载调整离线环境建议设为 50listen_addresses *让 PostgreSQL 监听所有网络接口0.0.0.0:5432和:::5432。注意*不等于0.0.0.0前者同时启用 IPv4 和 IPv6后者仅 IPv4port 5432默认端口但必须显式声明否则pg_ctl启动时可能因配置文件未加载而使用内置默认值max_connections直接影响shared_buffers和work_mem的计算必须在initdb后首次启动前设定否则重启后需手动pg_ctl reload。5.3pg_ctl reload与pg_ctl restart的本质区别/opt/pgsql/bin/pg_ctl -D /opt/pgsql/data -l logfile reload # 或 /opt/pgsql/bin/pg_ctl -D /opt/pgsql/data -l logfile restartreload仅重新加载postgresql.conf和pg_hba.conf不中断现有连接适用于修改max_connections或log_statement等参数restart完全停止再启动进程会中断所有客户端连接适用于修改listen_addresses或port等需重建监听套接字的参数。在配置远程访问时必须用restart。因为listen_addresses修改后旧进程仍在监听localhost:5432新配置不会生效。reload只会让pg_hba.conf生效但端口根本没开远程连接必然超时。6. 验证与加固用pg_isready和pg_test_fsync做离线环境的最终压力测试离线安装完成的标志不是psql能登录而是数据库能在真实负载下稳定运行。我一般会用两个原生命令做最终验证pg_isready检查服务可达性pg_test_fsync检测磁盘 I/O 性能瓶颈。这两个命令不依赖网络纯本地执行却能暴露 80% 的离线部署隐患。6.1pg_isready比netstat更可靠的端口健康检查/opt/pgsql/bin/pg_isready -h 127.0.0.1 -p 5432 -U postgres # 输出应为127.0.0.1:5432 - accepting connectionspg_isready的优势在于它会尝试建立真实的 PostgreSQL 协议握手而不仅是 TCP 连通性如果postgresql.conf中tcp_keepalives_idle设置不当netstat显示端口开放但pg_isready会超时它能区分accepting connections正常和no response进程僵死两种状态。进阶技巧用-t 5参数设置 5 秒超时避免在慢速磁盘上无限等待/opt/pgsql/bin/pg_isready -h 127.0.0.1 -p 5432 -U postgres -t 56.2pg_test_fsync离线环境最易被忽视的 I/O 性能雷区cd /opt/pgsql/data /opt/pgsql/bin/pg_test_fsync该命令会模拟 PostgreSQL 的 WAL 写入模式在当前目录创建临时文件并测试四种 fsync 方法open_datasync,fdatasync,fsync,fsync_writethrough的吞吐量。在物理机或企业级存储上open_datasync应 ≥ 2000 tps在虚拟机或 SATA SSD 上fdatasync应 ≥ 1500 tps。若所有方法均 300 tps说明磁盘 I/O 存在严重瓶颈低分表现可能原因解决方案open_datasync: 12 tps使用了ext4文件系统但未开启barrier1mount -o remount,barrier1 /dev/sda1fsync: 45 tpsRAID 卡电池失效写缓存被禁用检查MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL更换 BBU所有方法 100 tps使用了 NFS 或 CIFS 共享存储PostgreSQL 不支持网络文件系统必须迁回本地磁盘6.3 创建最小化测试库并验证中文支持最后一步创建一个真实业务会用到的测试库验证字符集和扩展su - postgres /opt/pgsql/bin/createdb -E UTF8 -T template0 xwgh /opt/pgsql/bin/psql -d xwgh -c CREATE EXTENSION pg_stat_statements; /opt/pgsql/bin/psql -d xwgh -c SET client_encoding UTF8; SELECT 你好世界::text;createdb -E UTF8显式指定数据库编码为 UTF8避免依赖template1的 locale 设置CREATE EXTENSION pg_stat_statements验证make install-world是否成功SELECT 你好世界::text确认client_encoding和server_encoding均为 UTF8中文插入无乱码。从那以后我每次离线部署 PostgreSQL都强制走一遍pg_test_fsyncpg_isready 中文查询三连测。哪怕客户说“只要能连上就行”我也坚持——因为 90% 的线上性能抖动根源都在离线安装时pg_test_fsync那个被忽略的 87 tps 上。希望帮到你。本文还有配套的精品资源点击获取