企业官网建设流程全解析

接手一台CentOS 7.9服务器，业务方指定要装PostgreSQL 9.6。第一反应是“装个数据库而已，多简单”，真动手才发现，这个组合属于典型的老系统适配问题——操作系统不算新，数据库更是已经停止官方维护的版本，中间还夹着系统自带软件包与第三方源打架的隐性坑。如果你跟我一样，手上压着一个老业务系统，代码里写着只有9.6才能跑的SQL方言，或者甲方明确要求“环境必须和原生产一致”，那这篇就是给你准备的。内容覆盖从仓库配置、依赖处理、初始化、认证配置到问题排查的完整链路，适合运维、后端开发、接手老项目的同学直接抄作业。

先说清楚我能帮你解决什么：在CentOS 7.9上把PostgreSQL 9.6装得干净、跑得稳、能远程连接、敢拿去上线，顺便把初次使用最常踩的几个坑提前填平。这篇文章不是简单的命令堆砌，我会把每个步骤“为什么这么做”也讲明白，毕竟盲敲命令出了问题，新手根本不知道从哪查起。

1. 为什么要在CentOS 7.9上装PostgreSQL 9.6

1.1 业务遗留项目的现实约束

很多人会问，PostgreSQL都出到十几了，为什么还装9.6？答案通常是三个字：没得选。我经手过的某老ERP系统就是这样，报表模块里大量SQL是用9.6特有的语法写的，开发团队早就散了，没人敢动这些查询。换新版本意味着每一句SQL都要重新验证，这个工作量在业务优先的场景里根本排不上期。另一个常见情况是数据库迁移项目，源库就是9.6，为了降低迁移风险，目标环境也必须先装一个同样版本的库做数据比对。

这种项目听起来不性感，却是很多企业真实存在的基础设施债务。作为接手的人，你不需要评判这个选择是否合理，你需要的是把这件事做对、做稳，别在老系统还没迁移完成的时候，先把新环境搞挂了。

1.2 9.6在CentOS 7.9下的兼容性表现

CentOS 7.9虽然是2020年之后还持续维护的老版本系统，但它内部的基础库如glibc、openssl，对PostgreSQL 9.6来说反而非常友好。9.6发布的时候，主流Linux发行版恰恰就是CentOS 7这个世代，两者算是同一个时代的产物，所以依赖兼容性远好于把9.6硬塞进一个特别新的系统里。

需要注意，CentOS 7.9自带的软件源里确实有PostgreSQL，但版本是9.2，不是9.6。如果你直接yum install postgresql-server，装出来的版本跟你预期的完全不同，后面业务连不上又排查半天，就属于自讨苦吃了。所以第一步必须引入官方源，这也是整个安装过程里最容易出错的地方之一。

1.3 版本决策：装旧版不是偷懒

在动手之前，我还是建议你想清楚一个事情：如果业务方只是说“数据库用PostgreSQL”，没有强制版本，那就不要装9.6。9.6已经在2021年停止官方维护，安全漏洞不会再修复，任何等保测评或者安全审计看到这个版本都会亮红灯。但如果你确实遇到业务锁死版本的情况，那安装之后必须做几件事：限制数据库只在内网访问、关闭不必要的扩展、定期做逻辑备份。也就是说，旧版本不是不能用，但要用“运维隔离”来弥补“版本补丁”的缺失。

你可以把9.6当成一套装修很老的房子，水电管路都已经定型了，住是能住，但家里贵重物品得锁好，门窗要加牢。后面我讲的防火墙、认证配置、远程访问限制，都是这门锁和防盗窗。

2. 安装前的准备工作：仓库、依赖与基础环境

2.1 先确认系统版本与基础环境

不管多简单的安装，开工前确认环境总是值得的。登录服务器后，先看看系统版本和资源情况：

cat /etc/centos-release uname -a free -h df -h nproc

为什么看这些？版本确认避免你把CentOS 6的命令用到7上，命令和软件源都不一样；内存和磁盘决定了后续初始化参数怎么给，比如shared_buffers给多少，数据目录放哪个分区，都需要根据实际资源来定。我见过有人不看磁盘，装完之后数据目录所在分区只有几百MB剩余，跑两天就把磁盘写满，数据库直接宕掉。

还有一个容易忽略的项：检查是不是已经装了PostgreSQL相关包。

rpm -qa | grep postgres

如果系统之前装过9.2或者别的版本，先别急着卸载。你要搞清楚它是系统自带的还是之前手动装的，有没有正在跑的实例，随便卸载可能会连带破坏别的应用。我的建议是：默认不卸载，只需在后续安装时指定正确的来源和版本，并注意端口冲突即可。

2.2 配置PGDG官方软件源

这是整个安装中最关键的一步。PostgreSQL官方维护着一个名为PGDG的仓库，里面按照大版本分别提供了对应的rpm包。CentOS 7对应的是EL7的rpm包，安装后会在/etc/yum.repos.d/下生成多个repo文件，把9.6、10、11、12等多个版本的源都带上。

操作思路是这样的：先把PGDG的仓库rpm安装到系统里，然后清理yum缓存，再根据自己需要的版本启用对应的仓库。这里不推荐手动去网上搜乱七八糟的源，优先用官方仓库地址，来源可信才能保证包完整、依赖干净。

yum install -y epel-release yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm yum clean all yum makecache

之所以要先装epel-release，是因为PGDG源里的某些依赖包会从EPEL仓库获取，不装的话，安装的时候可能报依赖找不到。命令里的URL以官方文档为准，我这边写的是常规路径，实际使用时如果官网调整了目录结构，请以官方最新页面为准。

安装完仓库后，建议马上看一眼仓库状态：

yum repolist | grep pgdg

正常情况下你应该能看到pgdg96、pgdg10、pgdg11等好几个源。这就是PGDG的一个特点：不指定版本的话，yum可能默认安装最新的大版本，给你装出个PostgreSQL 16，到时候又是一脸懵。

2.3 清理自带PostgreSQL的冲突风险

前面提到系统自带9.2，它和我们要装的9.6本质上可以共存，因为PGDG的包把可执行文件放在/usr/pgsql-9.6/目录下，数据目录用/var/lib/pgsql/9.6/，与系统自带的/usr/bin/psql以及/var/lib/pgsql/data并不冲突。

但有个麻烦点：如果系统里已经有正在运行的9.2实例占用了5432端口，那9.6启动时就会报端口被占。所以在安装9.6之前，最好查一下当前5432端口有没有服务：

ss -lntp | grep 5432

如果占用，就要先停掉旧服务或者给9.6换端口。我的习惯是让9.6先用默认5432，因为后续应用配置通常写死这个端口，少一个改动就少一个风险点。

2.4 数据库目录与初始资源规划

PostgreSQL的PGDG包默认会把数据目录放在/var/lib/pgsql/9.6/data。这个目录在安装rpm包的时候会自动创建，所有者是postgres用户。如果你默认用这个路径，后面会省很多权限方面的麻烦。

如果你想把数据放到独立的数据盘，比如/data/pgsql，那就需要手动创建目录并授权：

mkdir -p /data/pgsql chown -R postgres:postgres /data/pgsql chmod 700 /data/pgsql

这里目录权限必须是700，所有者必须postgres，否则initdb会直接拒绝。为什么是700？因为数据库文件属于敏感数据，不能给其他系统用户任何读权限。数据盘规划还有个建议：不要把数据库放在根分区，根分区一般还要容纳系统日志、临时文件、应用代码，一旦数据库膨胀，很容易把整个系统盘写满，最终导致操作系统异常。

3. 正式安装与数据目录初始化

3.1 安装PostgreSQL 9.6服务端

环境准备就绪后，正式安装。为了精确锁定9.6版本，安装时要显式指定仓库：

yum install -y --enablerepo=pgdg96 postgresql96-server postgresql96 postgresql96-contrib

• postgresql96-server：服务端主程序，包含initdb、postgres、pg_ctl等核心工具
• postgresql96：客户端工具，包括psql、pg_dump等
• postgresql96-contrib：常用扩展和附加工具，比如pg_stat_statements、uuid-ossp，建议装

有人会问，为什么不用postgresql96-devel？如果你只是跑数据库，不编译扩展、不装第三方插件，devel可以不用。但装了也不亏，后面如果要用pg_stat_statements或者编译一些C扩展时会用到头文件。

安装完成后验证一下版本：

/usr/pgsql-9.6/bin/postgres --version

应该输出类似“postgres (PostgreSQL) 9.6.24”的版本信息。这里注意，我们执行时用的路径是/usr/pgsql-9.6/bin/，因为9.6的可执行文件并不在系统默认的PATH里。这也意味着，后面用psql、pg_ctl等命令时要么写全路径，要么把路径加进环境变量。

我习惯在/etc/profile.d/下加一个环境变量文件，避免每次敲全路径：

echo 'export PATH=/usr/pgsql-9.6/bin:$PATH' > /etc/profile.d/pgsql96.sh source /etc/profile.d/pgsql96.sh

这个步骤不是必须的，但能明显提升后续操作的舒适度，特别是经常用pg_dump做备份的人，少打一长串路径，体感完全不一样。

3.2 初始化数据目录

初始化数据库是安装过程的分水岭，很多人就是在这里翻车的。在CentOS 7上初始化PostgreSQL有两种方式：一种是使用官方提供的setup脚本，另一种是手动调用initdb。我先说官方脚本方式，这是PGDG针对systemd环境封装好的，最简单：

/usr/pgsql-9.6/bin/postgresql96-setup initdb

脚本会自动以postgres用户执行initdb，初始化/var/lib/pgsql/9.6/data目录。如果你想手动初始化，命令是这样的：

su - postgres -c "/usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data -E UTF8 --locale=en_US.UTF-8"

手动方式必须用su切换成postgres用户执行，否则会报“cannot be run as root”。这也是PostgreSQL的传统：数据目录的所有者只能是postgres用户，initdb和postgres进程都不允许以root运行。理解这个设计很关键，数据库不像Web服务那样需要高权限，它只操作自己的数据目录，用最低权限运行反而是最好的安全策略。

关于字符集，建议明确指定-E UTF8，并设置合适的locale。如果服务器locale本来就是en_US.UTF-8或zh_CN.UTF-8，不指定也行。但某些情况下系统locale是C或POSIX，初始化出来的库默认字符集是SQL_ASCII，后面存中文数据会出现乱码或编码转换问题。所以，宁可初始化时多敲几个参数，也不要给未来埋坑。

初始化成功的标志是最后出现一句类似“Success. You can now start the database server”的提示，并且data目录下生成postgresql.conf、pg_hba.conf、base、global等文件和目录。

3.3 启动服务并设置开机自启

初始化完成后，剩下的事情就对胃口了。CentOS 7使用systemd管理服务，PostgreSQL 9.6的服务名是postgresql-9.6：

systemctl start postgresql-9.6 systemctl status postgresql-9.6 systemctl enable postgresql-9.6

启动后看一下状态，正常是active (running)。如果失败，先别慌，用journalctl看日志：

journalctl -u postgresql-9.6 --no-pager -n 50

大多数启动失败都可以归纳为三类：数据目录权限不对、配置文件语法错误、端口被占用。日志里一般都会直接点明原因，比如“could not open data directory Permission denied”就是权限问题，“port 5432 already in use”就是端口冲突。

enable那步特别重要，不然后面服务器重启，数据库起不来，如果恰好是凌晨重启，第二天业务全部报数据库连接失败，你连个远程桌面都来不及找。

3.4 验证安装结果

启动服务后，验证一下底层状态。先切到postgres用户连接一次默认数据库：

su - postgres psql -c "SELECT version();"

注意，前面设置过PATH的话，这里直接打psql就行；如果没设置，就用/usr/pgsql-9.6/bin/psql。正常能看到PostgreSQL 9.6.x的信息。这里默认的数据库连接方式是通过Unix Socket，以postgres系统用户身份连接时，数据库角色默认也是postgres，而且是trust认证，不需要密码。这个“免密”是初始化默认的认证策略，后面必须改掉，否则数据库等于大门敞开。

再确认一下当前监听的端口：

ss -lntp | grep 5432 ss -lntp | grep 5432

如果看到监听在127.0.0.1:5432，说明服务正常。注意它默认只监听本机回环地址，这也就是为什么外部IP连不上——不是防火墙拦你，而是数据库自己根本没把端口对外敞开。

4. 安装后的基础配置与安全加固

4.1 监听地址与端口配置

PostgreSQL安装完成后默认只监听localhost，如果你只是本机用，那挺好；但大多数业务场景需要应用服务器从别的机器连过来，所以得改监听配置。

修改/var/lib/pgsql/9.6/data/postgresql.conf，找到这两行：

#listen_addresses = 'localhost' #port = 5432

把注释去掉，并将listen_addresses改成：

listen_addresses = '*'

如果想指定内网网卡IP，也可以写成'192.168.1.10'，这样比直接开*更安全，因为数据库只会在这一块网卡上监听，其他网络接口直接拒绝。对于安全要求高的环境，我强烈建议指定具体IP，而不是图省事用星号。端口一般保持5432不动，除非你已经有一个实例占用了它。

修改后需要重启服务：

systemctl restart postgresql-9.6

然后检查监听状态：

ss -lntp | grep 5432

此时应该能看到监听在0.0.0.0:5432，或者你指定的IP:5432。这一步做完，数据库才开始具备被远程访问的基础能力。

4.2 pg_hba.conf认证规则逐条拆解

修改postgresql.conf只是“把门打开了”，真正决定谁能进、怎么进的是pg_hba.conf文件。这个文件名字是“host-based authentication”的缩写，每一行都代表一条访问规则，数据库从文件顶部开始逐条匹配，一旦匹配成功就不再往下看。所以规则的顺序非常重要。

默认的pg_hba.conf内容包括：

local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust

trust的意思是“不需要密码直接放行”。这个默认配置在刚装完时方便管理员操作，但在生产环境等于裸奔。我需要新增一条远程访问规则，并把本地也改成密码认证。修改后的核心配置看起来是这样：

local all all md5 host all all 127.0.0.1/32 md5 host all all ::1/128 md5 host all all 192.168.0.0/16 md5 host all all 0.0.0.0/0 md5

最后一条0.0.0.0/0是“允许所有IP”，如果业务应用服务器的IP段相对固定，我更建议直接写具体网段或单一IP，比如：

host all all 192.168.1.0/24 md5

这比“全部放行”安全得多。补充一个9.6版本特有的坑：PGDG的9.6默认认证方式一般是md5，不要试图写成scram-sha-256，因为scram认证是PostgreSQL 10才正式引入的。9.6的libpq和服务器如果配置了scram-sha-256，会直接报错说认证方式不支持。这一点在从新版本知识迁移过来的同学身上尤其容易踩坑。

4.3 数据库密码设置与客户端认证切换

前面我们以postgres用户身份直接登录，是因为trust认证。现在认证改成了md5，所以数据库角色postgres必须设置密码，否则远程连接会报“password authentication failed”。

修改密码的操作很简单：

ALTER USER postgres WITH PASSWORD '你的强密码';

密码复杂度方面，尽量使用大小写字母加数字加特殊字符，长度不低于16位。数据库密码一旦泄漏，等于把整个业务数据拱手送人。这里也顺便解释一下trust和md5的本质差别：trust认证是“你说是谁就是谁”，常见于本机管理场景；md5认证是“你说你是谁，并且要证明你知道密码”。

设置完密码后，后续本地连接也需要提供密码了：

psql -h 127.0.0.1 -U postgres -W

如果不加-W，psql在非交互模式下会直接尝试用当前系统用户身份匹配，很可能触发“no password supplied”的错误。脚本化连接推荐用PGPASSWORD环境变量，或者使用.pgpass文件。但老实说，.pgpass文件虽然方便，也存在明文存放密码的风险，使用时要确保文件权限只有当前用户可读。

4.4 防火墙、SELinux与远程访问

配置完监听和认证，远程连接通常还有两座山要翻：firewalld和SELinux。

CentOS 7默认开着firewalld，即便数据库监听0.0.0.0，外部流量到服务器时还是会被防火墙拒掉。放行5432端口：

firewall-cmd --permanent --add-port=5432/tcp firewall-cmd --reload firewall-cmd --list-all

如果你只想让某个来源IP访问，可以添加富规则：

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=5432 protocol=tcp accept' firewall-cmd --reload

再说SELinux。CentOS 7默认是Enforcing模式，PostgreSQL如果使用标准数据目录和标准端口，一般不受影响。如果你把数据目录放在非默认位置，或者监听非标准端口，SELinux策略会阻拦。检查SELinux状态：

getenforce

如果显示Enforcing且你自定义了数据目录，需要给数据目录设置正确的文件上下文：

semanage fcontext -a -t postgresql_db_t "/data/pgsql(/.*)?" restorecon -Rv /data/pgsql

如果监听非标准端口，还需要放行对应端口类型：

semanage port -a -t postgresql_port_t -p tcp 5433

很多人在改完listen_addresses后还是连不上，排查一圈发现是SELinux在拦截，却因为日志不显眼而没注意到。建议先临时用setenforce 0验证是不是SELinux的问题，但验证完一定要记得设回Enforcing，生产环境不建议长期关闭SELinux。

5. 9.6环境下的性能参数与日常调优

5.1 内存类参数怎么给

数据库装好了，能连上了，接下来要谈怎么好好用。PostgreSQL默认配置非常保守，适合在低配机器上跑起来，但如果你不调优，性能只能说能用，不能说好用。

先看内存。最核心的参数是shared_buffers，它是PostgreSQL的共享缓冲区大小，所有连接共享这块内存来缓存数据页。建议值是物理内存的25%左右，且单实例不要超过8GB。为什么不是越大越好？因为操作系统本身还要用内存做文件页缓存，如果shared_buffers过大，会导致双缓存竞争，反而降低性能。

假设你的服务器内存是16GB，可以这样设置：

shared_buffers = 4GB effective_cache_size = 8GB work_mem = 32MB maintenance_work_mem = 256MB

effective_cache_size表示操作系统文件缓存可用于PostgreSQL的预期大小，建议设置为系统可用内存的50%~75%，它不分配真实内存，只是给查询规划器一个估值的依据，设置偏小会导致优化器低估索引扫描的优势。

work_mem是每个排序、哈希操作可以使用的内存，默认4MB。这个值不能无限大，因为它是一个操作一个连接一份内存，如果有100个并发连接同时做排序，每个分配32MB，那一共就是3.2GB内存开销，要按最坏情况统筹。

maintenance_work_mem主要用于VACUUM、CREATE INDEX、ALTER TABLE这类维护操作，默认64MB。做大表建索引时，调高到256MB甚至1GB能明显加快速度，但同样要考虑并发维护任务的内存总和。

5.2 检查点与WAL相关参数

内存参数之外，9.6另一个值得调的是检查点相关参数。wal_level如果业务不需要流复制或归档，保持默认replica即可（9.6版本叫replica，再早版本是hot_standby）。

常用配置参考：

wal_buffers = 16MB checkpoint_completion_target = 0.9 max_wal_size = 4GB min_wal_size = 1GB

max_wal_size决定两个检查点之间最多允许WAL增长到多大，增大它可以让系统减少检查点频率，降低大批量写入时的性能抖动。checkpoint_completion_target表示检查点刷新脏页的操作要分散在设计周期的90%内完成，默认0.5意味着系统会在检查点后半程快速刷盘，容易产生IO尖峰，调到0.9可以让写入更平滑。

这些参数都在postgresql.conf里改，改完之后，如果是9.6版本，需要注意shared_buffers、max_wal_size等参数不能直接reload生效，必须要重启数据库：

systemctl restart postgresql-9.6

这个细节很多人忽略，导致改完参数发现没变化，然后怀疑配置没生效。区分方法是：SHOW命令查看参数状态是最直接的验证方式。不过先说明，参数修改后如果是用systemctl restart方式重启，会在重启瞬间断开所有连接，务必在维护窗口操作。

5.3 日志与慢查询监控

性能调优的前提是能看到问题。PostgreSQL默认日志记录得非常克制，只有错误和警告才会记录，慢查询默认根本不记。我建议在postgresql.conf中开启日志收集器并记录慢SQL：

logging_collector = on log_directory = 'log' log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_min_duration_statement = 1000 log_line_prefix = '%m [%p] '

log_min_duration_statement单位为毫秒，设为1000就是记录所有执行时间超过1秒的SQL语句。这个参数是排查性能问题的一大利器，你能清楚看到哪些查询在吃时间，然后针对性加索引或改写SQL。

慢查询日志生成在数据目录下的log子目录，也就是/var/lib/pgsql/9.6/data/log。如果开启了log_truncate_on_rotation，同一个星期的日志会被循环覆盖，对于始终关注性能的库，建议设置每天一个文件：

log_rotation_age = 1d

另外，扩展pg_stat_statements也值得启用，它可以汇总SQL的执行次数、总耗时、平均耗时。启用方法是在postgresql.conf中设置：

shared_preload_libraries = 'pg_stat_statements'

然后重启数据库，执行，然后确认扩展：

CREATE EXTENSION pg_stat_statements; SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;

这个视图能在不改动业务的情况下，帮你找出最消耗资源的Top SQL，属于老库翻新和新库上线都比较值得加装的监控手段。

6. 常见问题排查与避坑实录

6.1 yum安装时找不到postgresql96-server包

这是一个很经典的问题，表现为执行install命令时提示“No package postgresql96-server available”。绝大多数原因是PGDG仓库没有正确启用，或者yum缓存里还没有仓库的数据。

排查顺序是：先yum repolist确认源确实存在，再yum clean all清缓存，再yum makecache重新生成缓存。如果还是找不到，检查一下是否在安装时误用了--disablerepo把所有repo都禁掉了，或者repo文件里的enabled=0。还有一个小概率情况：服务器架构不是x86_64，PGDG对某些架构不提供rpm包，比如32位系统就找不到，这时只能改用源码编译方式，成本会高很多。

6.2 initdb初始化报错怎么办

initdb报错五花八门，最常见的几种我在实操里都遇到过：

• 以root用户直接执行initdb，报错“cannot be run as root”。解决方案是su到postgres用户再执行。
• 数据目录非空，报错“directory exists and is not empty”。如果确定目录里没有有价值数据，就清空，但要小心rm误删。
• 数据目录所有者不是postgres，报错“permission denied”。直接chown -R postgres:postgres目录即可。
• locale相关错误，比如“invalid locale name zh_CN.UTF-8”，说明系统没生成这个locale。需要先localectl list-locales确认可用项，或者改用en_US.UTF-8/C。

还有一次比较隐蔽，服务器上设置了内核参数shmmax过小，导致共享内存分配失败。PostgreSQL 9.6的默认SysV共享内存配置需要一定内核限制，如果你之前为别的服务改过内核参数，遇到初始化报共享内存错误时，检查kernel.shmmax和kernel.shmall。

6.3 服务起不来：日志定位技巧

systemd的journalctl是定位第一现场的工具，但PostgreSQL自己的日志往往更细致。数据目录下的log子目录里会记录每一次启动和错误信息。如果你的logging_collector没开，错误信息会直接输出到标准错误，由systemd捕获，在journalctl里一样能看到。

比较常见的启动失败原因：

• 端口被占用，日志会直接写明“could not bind IPv4 address: Address already in use”。用ss -lntp找到占用进程，确认是否是旧版本PostgreSQL或者别的应用。
• postgresql.conf里面有语法错误，日志会指到具体行号。比如“invalid value for parameter ...”，多半是参数名拼错或者值类型不对，改回去再启动。
• 数据目录里面的postmaster.pid文件残留，导致误判为另一个实例正在运行。确认没有相应进程后，删除pid文件再启动。

6.4 客户端连接失败的几种经典场景

远程连接失败，是新手问得最多的问题。先要看错误类型：

• psql报“could not connect to server: Connection refused”。这通常表示端口没监听或者防火墙拦截。按顺序检查数据库监听地址、firewalld放行、SELinux限制。
• psql报“no pg_hba.conf entry for host ...”。这说明IP能到达PostgreSQL，但认证文件里没有匹配的规则。检查pg_hba.conf的host条目，确认你的客户端IP来源和段设置是否匹配，改完要reload配置。
• psql报“password authentication failed for user ...”。说明匹配规则正确，但密码不对。用pg_hba.conf中指定的认证方式重新设置密码，注意9.6不支持scram，只能md5。
• psql报“FATAL: database does not exist”。连接时没有指定正确的数据库名，默认是尝试连接与用户名同名的数据库，postgres用户默认连接postgres库，否则要加-d参数指定。

这些错误信息本身就能给你定性，关键是要养成先看报错再动手的习惯，不要一上来就去关防防火墙、改权限，很可能把问题越搞越复杂。

6.5 老数据库迁移到9.6的注意点

最后顺带说一下，很多人装9.6是为了迁库。如果你要把5.6或者旧版本的9.x数据迁过来，最稳妥的方式是逻辑导出导入：

pg_dump -h 源库IP -U 用户 -d 目标库 -Fc -f backup.dump pg_restore -h 目标库IP -U postgres -d target_db -j 4 backup.dump

-Fc是自定义压缩格式，搭配-j参数可以并行恢复，速度比纯SQL文件快不少。迁移前要确认两端字符集一致，否则中文数据可能乱码。还要特别注意序列的迁移，pg_dump默认会带出序列的当前值，但如果你用了--data-only之类的参数，序列值可能没恢复到位，导致主键冲突。我一般建议先恢复表结构（--schema-only），再恢复数据，最后单独检查并修正序列值。

如果是同一大版本范围内的实例迁移，也可以考虑用pg_upgrade或者简单的物理文件拷贝，前提是版本高度接近，且数据库归档模式配置正确。但在9.6这种老版本上做迁移，我更倾向于逻辑备份，因为物理迁移的环境差异和版本差异实在太容易出幺蛾子，逻辑备份虽然慢一点，但每一步都看得见结果，出问题也好回滚。

我个人在实际操作中体会最深的一点是，老版本数据库安装最关键的不是命令本身，而是对默认行为和版本差异的敏感度。9.6的认证方式、目录结构、配置文件路径，和现在的新版本都有差别，用习惯了新版本再来装老库，处处都会踩到“我以为会这样”的坑。所以整个过程尽量别赶时间，每做一步就验证一步，做到端口、认证、日志、备份全部确认过再交接，这个库才能真正放心用起来。

最后再分享一个小技巧：装完PostgreSQL 9.6后，别着急配应用，先用psql把pg_hba.conf里的认证规则逐条测一遍，再写一个连接失败的测试清单，比如“本地socket连-应该成功”、“密码错了-应该报认证失败”、“外部IP连-应该成功”。这样一套测下来，等于给数据库做了一次完整的体检，后续业务接入时再出任何连接问题，你就知道问题不在数据库环境，而在应用配置，排查范围瞬间缩小一半。