1. 三套启停入口先搞清楚你在跟谁打交道PostgreSQL 启动停止命令这几个字乍一看是最没技术含量的部分——pg_ctl start、pg_ctl stop、systemctl restart postgresql翻来覆去就这几条谁不会敲。真正把人从床上叫起来的恰恰是这几条命令敲了启动回车之后报FATAL: lock file postmaster.pid already exists敲了停止命令挂在那里几分钟不动重启完了应用那边一片超时监控告警刷屏。问题不在于命令本身而在于大多数人只记住了「怎么敲」没搞清楚「敲下去之后谁在干活」。这篇内容我按实际运维时的手感来拆一台 PostgreSQL 实例的启停到底有几个入口停止命令背后发出去的是什么信号启动那几秒数据库内部在忙什么改完配置该 reload 还是 restart重启之后为什么性能会掉一截以及停不下来、起不来的时候按什么顺序排查。适合刚开始接手数据库的研发、负责日常运维的同学也适合已经能敲命令但总在细节上翻车的朋友我会把每个「为什么这么做」讲透。1.1 systemctl、pg_ctl、pg_ctlcluster别混着用PostgreSQL 没有 MySQL 那一套mysqld_safe守护进程它的启停入口取决于你当初是怎么装的。常见三种情况对应的命令完全不一样安装方式常用启停入口特点源码编译 / 部分通用二进制包pg_ctl -D $PGDATA start/stop/restart直接对着数据目录操作最底层RHEL、CentOS 系 RPM 包systemctl start/stop/restart postgresql-14一个 unit 管一个实例Debian、Ubuntu 系 deb 包pg_ctlcluster 14 main start/stop/restart一个postgresql.service管机器上所有集群先说你手头这套属于哪一种。判断方法很简单看一眼进程树就够了ps -ef | grep postgres | grep -v grep如果进程的父进程是systemd(1)那它归 systemd 管你就老老实实用systemctl。如果父进程是另一个postgres进程那个就是 postmaster 本身说明它是被pg_ctl直接拉起来的。为什么强调「别混着用」这是我在实际环境里见过最多的低级事故。有人用systemctl stop postgresql-14停了服务systemd 记录这个 unit 处于 inactive 状态然后他又习惯性地用pg_ctl -D /var/lib/pgsql/14/data start把库拉起来了。此时数据库在跑但 systemd 依然认为服务是停的。下次机器重启、或者有人执行systemctl restart postgresql-14systemd 会尝试启动一个「已经占用了 5432 端口」的新实例直接失败。更麻烦的是很多监控系统是按 systemd 的 unit 状态来判断实例死活的你觉得库好好的监控那边一片红。我自己的规矩是谁负责拉起这个进程就只用谁的入口去停它。systemd 拉起来的就用systemctlpg_ctl拉起来的就用pg_ctlDebian 系用pg_ctlcluster。真要换管理方式先把原方式停干净确认端口释放了再用新方式起。Debian 系还有个容易忽略的点pg_lsclusters能看到机器上所有集群的状态包括版本、端口、状态、日志路径。同一台机器跑 13 和 15 两个集群是常规操作你要是systemctl restart postgresql它会把所有集群一起重启而不是你只想动的那一个。这种时候必须用pg_ctlcluster 15 main restart精确打击。1.2 一个数据目录就是一个实例postmaster.pid是它的身份证pg_ctl的所有操作都离不开-D后面那个数据目录因为 PostgreSQL 的规矩是「一个数据目录对应一个 postmaster 进程」没有例外。数据目录里有个postmaster.pid文件很多人报错时看到它但从来没打开看过。它的内容一般是这样几行8241 /var/lib/postgresql/14/main 1723456789 5432 /var/run/postgresql 127.0.0.1 1234567890 ready依次是PID、数据目录、启动时间戳、端口、Unix socket 目录、监听地址、共享内存标识、状态。最后那个ready很关键它说明实例已经完成恢复、可以接受连接如果是starting或者shutting down那就对应两种经典的报错场景应用连上来报the database system is starting up或者the database system is shutting down。postmaster.pid最大的价值是判断残留。启动时报lock file already exists说明文件还在。这时候不要急着删先做两件事cat /var/lib/postgresql/14/main/postmaster.pid | head -1 ps -p $(head -1 /var/lib/postgresql/14/main/postmaster.pid)如果ps能查到这个 PID 且确实是 postgres 进程说明实例还在跑你遇到的是「端口被占」或者「你在重复启动」这时候该做的是查状态而不是删文件。如果ps查不到这个 PID那就是上次非正常退出留下的残留文件确认没有其他 postgres 进程后可以删掉再启动。我踩过的坑是容器环境下 PID 会被复用你查到的 PID 恰好被另一个无关进程占用了看着像「还在跑」其实数据库早死了。所以更稳的判断是看ps -ef里有没有对应数据目录的 postmaster 进程而不是只看 PID 号。2. 停止命令到底发了什么信号很多人把pg_ctl stop当成一个黑盒「反正它能让库停下来」。但停库有三种模式模式不同发出去的信号不同行为差异很大选错模式轻则业务报错一片重则下次启动多花几十分钟做崩溃恢复。2.1 smart、fast、immediate 三档停机语义完全不同PostgreSQL 的停机模式本质是 Unix 信号理解了信号就理解了行为模式对应信号行为典型耗时smartSIGTERM等所有客户端主动断开后才开始关闭新连接仍然接受不可控可能永远等不到fastSIGINT立刻断开所有客户端、回滚未提交事务然后做一次 checkpoint 再退出秒级到几十秒immediateSIGQUIT不等待、不做 checkpoint直接退出下次启动走崩溃恢复毫秒级smart这个模式我基本不用原因很直白它要等所有会话自己退出。生产库上只要有连接池挂着长连接、有一个忘了关的 psql 窗口、有一个跑了半天的批处理它就一直等。你敲完命令回车终端就那么挂着你以为卡死了其实它老老实实在等客户端。曾经有个同事在测试环境用 smart 停库结果那个环境里挂着一个pg_sleep(3600)的会话命令硬生生挂了四十分钟最后还得另开窗口kill。fast是日常停库的默认选择pg_ctl stop不带-m参数时默认就是它。它会主动踢掉客户端、回滚事务然后做一次 checkpoint 把脏页刷下去保证下次启动不需要恢复。业务的感受是「连接突然断了」所以要么挑低峰要么让应用端有重连机制。immediate是紧急刹车对应pg_ctl stop -m immediate。注意它不是kill -9它仍然是 postmaster 主动退出共享内存会被释放只是跳过了 checkpoint把「一致性」这件事交给下次启动时的 WAL 重放。什么时候用它实例已经进入不正常状态、fast 模式等了几分钟还不退出、磁盘快满了需要立刻停写。用它就要接受一个后果下次启动会变慢因为要从最近的 checkpoint 位置开始重放 WAL。2.2 停机耗时能算出来别凭感觉设超时fast 模式的耗时大头是 checkpoint把shared_buffers里的脏页刷到磁盘。这个时间是可以粗算的。假设shared_buffers设了 8GB某个时刻脏页占比 25%那就是 2GB 待刷数据。机械盘顺序写按 120MB/s 算约 17 秒SATA SSD 按 450MB/s 算约 4.5 秒NVMe 按 1.5GB/s 算不到 2 秒。这还只是写盘时间实际还要加上 fsync 的延迟、元数据操作所以真实耗时通常是理论值的 1.5 到 3 倍。这个估算不是纸上谈兵它直接决定了两个参数该设多少# pg_ctl 等待启动/停止完成的超时单位秒 pg_ctl -D /var/lib/postgresql/14/main -m fast -w -t 120 stop-w表示等待操作真正完成-t 120是超时 120 秒。不写-w的话命令会立刻返回你以为停完了其实后台还在刷盘紧接着你去启动就撞上「already running」。我建议所有脚本里都显式带上-w -t。systemd 这一侧对应的参数是TimeoutStopSec默认值因发行版而异常见 90 秒。如果你的库很大、shared_buffers给得很足fast 停机可能超过这个时间systemd 等不及会直接发 SIGKILL。SIGKILL 一上来postmaster 没有任何清理机会共享内存段残留、postmaster.pid残留下次启动必须做完整的崩溃恢复本来只要几十秒的事情变成几十分钟。所以大内存实例一定要检查这个值systemctl show postgresql-14 -p TimeoutStopSec不够就改 unit 的 override# /etc/systemd/system/postgresql-14.service.d/override.conf [Service] TimeoutStopSec300改完systemctl daemon-reload生效。这一步我在好几个内存 64G 以上的实例上都做过属于典型的「平时看不出问题出事时救命」的配置。3. 启动从敲下回车到能接连接中间发生了什么pg_ctl start返回成功不代表数据库就能用了。理解启动过程才能解释那些「明明启动了却连不上」的怪现象。3.1 启动流程拆开看postmaster 启动后大致这么走读postgresql.conf和postgresql.auto.conf→ 检查postmaster.pid→ 创建共享内存和信号量 → 启动 checkpointer、background writer、walwriter、autovacuum launcher 等后台进程 → 检查pg_control文件判断上次是否正常关闭 → 如果不正常就进入崩溃恢复从最近的 checkpoint 开始重放 WAL → 打开监听端口 → 状态写成ready。这条链路里每一步都可能卡住对应的现象也不一样卡在读配置配置文件语法错误日志里会有syntax error in file进程直接退出。卡在 pid 检查lock file already exists。卡在共享内存could not create shared memory segment通常是内核shmmax、shmall限制或者huge_pages配置和系统不匹配。卡在崩溃恢复日志里刷redo starts at ...此时端口已经监听但拒绝连接报the database system is starting up。最后这种最容易被误判。有人看ss -lntp发现 5432 在监听就断定「服务起来了」然后应用连不上开始怀疑网络、怀疑防火墙查半天。其实看日志一行就明白了tail -f /var/log/postgresql/postgresql-14-main.log # 或者源码安装的 tail -f $PGDATA/log/postgresql-*.log崩溃恢复的进度在日志里是可见的redo done at ...出现才算恢复完。恢复耗时取决于两件事上次 checkpoint 之后产生了多少 WAL以及磁盘的随机读能力。粗算方法是看pg_wal目录里 checkpoint 之后的段文件数量一个 16MB乘以段数就是需要重放的数据量上限。如果业务写入是 500MB/mincheckpoint_timeout是 5 分钟那最坏情况要重放 2.5GB 左右机械盘上可能就是几分钟的事。3.2 启动命令的正确写法pg_ctl启动我一般这么写pg_ctl -D /var/lib/postgresql/14/main \ -l /var/log/postgresql/postgresql-14-main.log \ -w -t 300 \ start-l指定日志文件很重要。不指定的话启动日志会打到当前终端你 SSH 一断日志就没了出了事只能靠猜。有些环境里logging_collector on日志由数据库自己管理这时候-l可以省但启动早期配置还没解析完的报错仍然只会出现在 stderr所以我还是习惯带上。启动完成后别急着走用pg_isready探一下pg_isready -h 127.0.0.1 -p 5432 -t 5 # /var/run/postgresql:5432 - accepting connections这个命令返回 0 才代表真的能接受连接比ps看进程靠谱得多。写脚本做健康检查时pg_isready加psql -c select 1双层校验是我常用的组合前者快后者能验证认证和权限链路。还有一种情况必须提PostgreSQL 不允许用 root 启动。你用 root 敲pg_ctl start会直接看到pg_ctl: cannot be run as root。这是故意设计的防止数据库进程拥有过高权限。正确做法是su - postgres切过去再操作或者用sudo -u postgres pg_ctl ...。用 systemd 的话不存在这个问题unit 文件里已经指定了Userpostgres。3.3 开机自启这件事装完就该确认新装完的实例很多人只测了「手动能起来」没测「重启机器能自己起来」。我接手环境时的标准动作是systemctl is-enabled postgresql-14 systemctl enable postgresql-14Debian 系则是systemctl is-enabled postgresql。源码编译 pg_ctl管理的情况没有 systemd 帮忙要么写个 init 脚本要么在crontab里加reboot要么干脆用pg_ctl的-w配合一个启动脚本。这一条看着不起眼但机器意外重启后数据库没自己起来业务停摆几个小时的事故我见过不止一次。4. reload 还是 restart改完配置这一步最容易搞错这是我最想强调的一节。很多人改完postgresql.conf条件反射就是systemctl restart。能生效但代价是所有连接断开、缓冲池清空、恢复期业务抖动。而实际上八九成的参数根本不需要重启reload就够了。4.1 三类参数三种生效方式参数类型生效方式典型参数动态参数SIGHUP 即可即 reloadwork_mem、maintenance_work_mem、log_min_duration_statement、checkpoint_completion_target、max_connections新连接生效需重载共享内存必须 restartshared_buffers、wal_buffers、max_connections已存在会话的上限全局结构参数必须 restartport、listen_addresses、data_directory、wal_level、max_wal_senders、huge_pagesreload 的本质是给 postmaster 发 SIGHUP让它重新读配置文件然后把变化广播给子进程。命令有三种写法效果一样# 方式一 pg_ctl -D /var/lib/postgresql/14/main reload # 方式二 systemctl reload postgresql-14 # 方式三在 psql 里 SELECT pg_reload_conf();怎么知道哪些参数改了需要重启PG 9.5 之后有个特别实用的视图SELECT name, setting, pending_restart FROM pg_settings WHERE pending_restart true;只要这个查询有结果说明你已经改了某些参数但还没重启新值还没真正生效。这个视图应该在每次改完配置后都查一遍比翻文档可靠。我第一次见到它的时候还挺惊讶——原来数据库自己知道哪些改动在等重启不用去背参数清单。4.2 改配置的标准流程我自己的操作顺序固定成这样几乎不出错# 1. 备份配置 cp $PGDATA/postgresql.conf $PGDATA/postgresql.conf.bak.$(date %Y%m%d) # 2. 改参数用 ALTER SYSTEM 更规范会写到 postgresql.auto.conf psql -c ALTER SYSTEM SET work_mem 8MB; # 3. 验证语法先 reload psql -c SELECT pg_reload_conf(); # 4. 看日志有没有报错 tail -20 /var/log/postgresql/postgresql-14-main.log # 5. 确认是否还有待重启参数 psql -c SELECT name FROM pg_settings WHERE pending_restart;用ALTER SYSTEM而不是直接编辑postgresql.conf有一个好处改动集中在postgresql.auto.conf里和手工维护的主配置分开出问题好回滚也避免多人编辑同一文件互相覆盖。代价是ALTER SYSTEM不能改需要重启才能生效的参数——它其实能写进去但会提示你重启才生效容易忘。所以改这类参数我还是会去编辑主配置文件改完立刻pending_restart查一遍。有个细节值得说max_connections比较特殊它属于「改了之后新连接能看到新上限但共享内存结构在启动时就定死了」。所以如果你把 100 调到 200 然后只 reload新连接能连进来但一旦超过旧上限的并发真正压上来可能触发共享内存相关的异常。我的建议是这类参数一律走 restart别图省事。4.3 那些「reload 了但没生效」的坑最典型的是改了pg_hba.conf之后 reload然后发现新加的网段还是连不上。先确认三件事改的文件是不是$PGDATA下那个有些环境用hba_file参数指到了别处、reload 有没有真的成功看日志里有没有received SIGHUP、以及客户端走的是 TCP 还是 Unix socket——pg_hba.conf里local和host是两条完全不同的规则。另一个坑是配置文件里的include或include_dir。主配置里可能引了conf.d/*.conf你改的是一份实际生效的是另一份。查当前实际生效值别靠眼睛看文件SHOW work_mem; SELECT * FROM pg_file_settings WHERE error IS NOT NULL;pg_file_settings这个视图会列出所有被加载的配置文件行语法错误也会标出来比逐行检查高效得多。