游乐游手机版
首页/数据库/文章详情

PostgreSql中pg_ctl命令示例代码

时间:2026-04-30 19:26
一、概述 在管理PostgreSQL数据库时,手里得有几样趁手的工具。pg_ctl就是这样一位“大管家”,专司数据库服务的生命周期控制,从初始化到启停、状态监控乃至日志管理,基本都能包办。 二、语法 --初始化数据库实例 pg_ctl init[db] [-D datadir] [-s] [-o i

一、概述

在管理PostgreSQL数据库时,手里得有几样趁手的工具。pg_ctl就是这样一位“大管家”,专司数据库服务的生命周期控制,从初始化到启停、状态监控乃至日志管理,基本都能包办。

二、语法

--初始化数据库实例
pg_ctl init[db] [-D datadir] [-s] [-o initdb-options]

--启动数据库实例
pg_ctl start [-D datadir] [-l filename] [-W] [-t seconds] [-s] [-o options] [-p path] [-c]

--停止数据库实例
pg_ctl stop [-D datadir] [-m s[mart] | f[ast] | i[mmediate] ] [-W] [-t seconds] [-s]

--重启数据库实例
pg_ctl restart [-D datadir] [-m s[mart] | f[ast] | i[mmediate] ] [-W] [-t seconds] [-s] [-o options] [-c]

--重新加载数据库配置文件
pg_ctl reload [-D datadir] [-s]

--查看数据库状态
pg_ctl status [-D datadir]

--备库切换为主库
pg_ctl promote [-D datadir] [-W] [-t seconds] [-s]

--轮换服务器日志文件
pg_ctl logrotate [-D datadir] [-s]

--向一个指定进程发送一个消息
pg_ctl kill signal_name process_id 

--注册服务(Windows)
pg_ctl register [-D datadir] [-N servicename] [-U username] [-P password] [-S a[uto] | d[emand] ] [-e source] [-W] [-t seconds] [-s] [-o options]

--移除服务(Windows)
pg_ctl unregister [-N servicename]

这里的 initinitdb 动作,其实就是调用了 initdb 命令来完成数据库实例的初始化工作。想了解更底层的细节,直接去查initdb的命令手册会更清楚。

参数说明

-c 或 --core-files:这个选项比较关键,它允许服务器在崩溃时生成核心转储文件(core dump),对于事后调试定位问题非常有帮助。

-D datadir 或 --pgdata=datadir:指定数据库集群的数据目录在哪里。如果不指定,那么pg_ctl会去读取环境变量PGDATA的值。所以,把数据目录管理清楚,是避免混淆的第一步。

-l filename 或 --log=filename:将服务器的日志输出追加到指定的filename文件中。日志是运维的眼睛,给它找个固定的地方很重要。

-m mode 或 --mode=mode:指定停止服务器时的关闭模式。mode可以是smartfastimmediate,用首字母缩写也行。如果没有明说,默认会按fast模式来。三种模式区别很大:smart会等所有连接结束,fast会中断事务并回滚,immediate则近似于强制终止,选哪个得看场景。

-o options 或 --options=options:这个参数是用来把选项直接传递给后台的postgres进程的。可以多次使用-o,所有给定的选项都会传过去。这里有个小技巧:传递的选项通常需要用单引号或双引号包起来,以确保它们被作为一个整体解析。

-o initdb-options 或 --options=initdb-options:和上面类似,但选项是传递给initdb命令的。同样可以多次指定,同样建议用引号包围。

-p path:指定postgres可执行文件的路径。一般来说,pg_ctl会从自己所在的目录找,找不到再去硬编码的安装目录找。除非你做了特别定制并遇到“找不到可执行文件”的报错,否则这个参数基本用不上。在init模式下,它则用于指定initdb的位置。

-s 或 --silent:静默模式。只打印错误信息,常规的信息性消息就不输出了,让界面更清爽。

-t seconds 或 --timeout=seconds:设置等待某个操作完成的最大秒数。默认会先去读PGCTLTIMEOUT这个环境变量,如果没设置,那就等60秒。超时了,pg_ctl会以非零状态退出,但请注意,操作可能在后台继续并最终成功。

-V 或 --version:打印pg_ctl自己的版本号,然后退出。用于快速确认工具版本。

-w 或 --wait:等待操作完成。对于start, stop, restart, promote, register这些模式,这个选项是默认开启的。在等待时,pg_ctl会反复检查服务器的PID文件,间歇性休眠。启动成功等的是PID文件显示服务器已就绪;停止成功等的是PID文件被移除。pg_ctl会根据等待到的结果返回相应的退出码。

-W 或 --no-wait:与-w相反,不等待操作完成就立即返回。这样你就得自己去查看服务器日志或通过外部监控系统来确认操作的实际进度和结果了。在早期版本的PostgreSQL中,除了stop,其他模式默认都是不等待的。

参数说明(Windows)

-e source:在Windows系统以服务形式运行时,pg_ctl自身向事件日志中记录消息时所使用的事件源名称。默认是“PostgreSQL”。这里要分清:这个参数只管pg_ctl自己发的日志;服务器启动后,会用event_source参数指定的名称来记录。如果服务器在启动早期(还没读到这个参数)就失败了,它可能也会用默认的“PostgreSQL”来记一笔。

-N servicename:要注册到Windows服务管理器的服务名称,会同时用作服务名和显示名。默认也是“PostgreSQL”。

-P password:运行该服务的对应用户账户的密码。

-S start-type:指定注册的服务的启动类型。可以是auto(自动)或demand(手动),用首字母也行。默认是auto

-U username:用于运行该服务的用户名。如果是域账户,格式得写成DOMAIN\username

三、示例

--启动
pg_ctl start

--要使用端口 5433 启动,并且运行时不使用fsync:
pg_ctl -o "-F -p 5433" start 

--停止
pg_ctl stop
pg_ctl stop -m smart

--重启
pg_ctl restart

--如果指定了-o,则会替换任何之前的选项。要使用端口 5433 重启并在重启时禁用fsync:
pg_ctl -o "-F -p 5433" restart

--查看状态
pg_ctl status
pg_ctl: server is running (PID: 13718)
/usr/local/pgsql/bin/postgres "-D" "/usr/local/pgsql/data" "-p" "5433" "-B" "128"
第二行是在重启模式可能被调用的命令行。

上面的例子很直观。比如启动时通过-o传递-F(关闭fsync)和-p 5433(指定端口)给服务器进程。查看状态时,除了告诉你服务器正在运行,还会打印出它实际启动时的完整命令行,这在排查配置问题时非常有用。

总结

总的来看,pg_ctl是PostgreSQL管理员日常交互最频繁的工具之一。它的命令结构清晰,参数虽然不少,但大多符合直觉。关键在于理解几个核心操作(启、停、重启、状态)和几个关键参数(数据目录-D、关闭模式-m、传递选项-o)的用法。特别是在生产环境,选择正确的停止模式(-m)和合理设置等待超时(-t),对于平衡服务可用性与数据一致性至关重要。把这些基本操作练熟,数据库服务的日常管控就能做到心中有数了。

来源:https://www.jb51.net/database/343345vpv.htm
上一篇PostgreSQL修改最大连接数的详细操作步骤 下一篇PostgreSQL的扩展adminpack使用
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
金仓数据库逻辑备份实战:全库导出与模式替换全流程
数据库 · 2026-07-03

金仓数据库逻辑备份实战:全库导出与模式替换全流程

在长期的运维实践中,我越来越体会到,备份就像一份保险——平时看似无用,但关键时刻却是唯一的救命稻草。逻辑备份看似简单,可真正执行恢复时,各种陷阱接连浮现:表名大小写不一致、Schema 未正确切换、Owner 属性未同步修改……任何一个环节处理不当,最终恢复出的数据库就会与预期相去甚远。 本文将深入

金仓数据库sys_rman物理备份全流程演练与误覆盖恢复
数据库 · 2026-07-03

金仓数据库sys_rman物理备份全流程演练与误覆盖恢复

干运维这行,逻辑备份和物理备份我都接触过,但说句实在话,真正能在生产环境里扛住事儿的,还得是物理备份。逻辑备份导出的是 SQL 语句,数据量一大,那速度慢得让人抓狂,而且最关键的是,它没法做时间点恢复。物理备份不一样,它直接拷贝数据文件,再配上 WAL 归档日志,想恢复到过去哪一秒都行,这是它最硬核

Windows下将MySQL注册为系统自启服务教程
数据库 · 2026-07-03

Windows下将MySQL注册为系统自启服务教程

先说一个关键前提:务必以管理员身份运行终端,否则 mysqld --install 这条命令几乎不可能成功。问题不在于命令写错,而是 Windows 系统的用户账户控制(UAC)机制会在中途拦截——在普通 CMD 或 PowerShell 窗口执行这条命令,要么直接提示 Access is deni

Mac版Navicat中快速对比两个数据库的表结构异同
数据库 · 2026-07-03

Mac版Navicat中快速对比两个数据库的表结构异同

直接说结论:Mac 版 Navicat 和 Windows 版在表结构比对逻辑上完全一致。但默认配置下,它确实无法承受“全库一键比对上万张表”的压力。要想避免卡死、内存溢出、进度条永远停在 0%,你必须手动将表分批处理,或者利用前缀过滤来控制扫描范围。 为什么 Mac 上点击「结构同步」后界面会卡住

MySQL中UNION操作推荐用UNION ALL的原因
数据库 · 2026-07-03

MySQL中UNION操作推荐用UNION ALL的原因

MySQL中UNION与UNION ALL性能对比:别再被“保险”迷惑,差距远超预期 先给出核心结论:UNION ALL 的性能通常比 UNION 高出不止一个数量级。原因在于,UNION 在合并结果集后会自动触发去重操作,这往往伴随着隐式排序,进而产生临时表和文件排序。而 UNION ALL 则直