声明
postgres
可执行文件的位置。缺省位于
pg_ctl
自身所在目录,如果没找到则使用硬编码的安装目录。除非你想干点什么特别的事情,并且想得到类似没有找到
postgres
这样的错误,否则必须使用这个选项。
只打印错误,而不打印提示性信息。
等待启动或者关闭的完成(60 秒超时),这个参数是关闭时的缺省值。成功的关闭是以删除 PID 文件为标志的。对于启动而言,一次成功的
psql -l
就标志着成功。
pg_ctl
将企图使用对
psql 合适的端口,如果存在
PGPORT
环境变量,那么将用它。否则,它将查找在
postgresql.conf
文件里是否设置了一个端口。如果都没有,它将使用 PostgreSQL 编译时的缺省端口(缺省 5432)。在等待的时候,
pg_ctl
将根据启动或者关闭的成功状况返回一个准确的退出代码。
不等待启动或者停止的完成。这是启动和重启的缺省。
Windows 选项
-
-N
servicename
-
要注册的系统服务的名字。这个名字将用于服务名和显示名。
-
-P
password
-
用户启动服务的口令
-
-U
username
-
用于启动服务的用户的用户名。对于域用户,使用
DOMAIN\username
格式。
-
postmaster.opts.default
-
如果这个文件存在于数据目录,
pg_ctl (在
start
模式下)将把文件地内容当作传递给
postgres
命令的选项传递过去,除非被
-o
选项覆盖。
-
postmaster.opts
-
如果这个文件存在于数据目录,
pg_ctl (在
start
模式下)将把文件地内容当作传递给
postgres
命令的选项传递过去,除非被
-o
选项覆盖。这个文件的内容也会在
status
模式里显示出来。
-
postgresql.conf
-
这个文件在数据目录中,会分析它以查找和
psql 一起用的合适的端口(在
start
模式里给出
-w
的时候)。
重启服务器
这个命令几乎等于先停止服务器然后再启动它,只不过
pg_ctl
保存并重新使用上一次运行服务器的命令行参数。重启服务器的最简单的方法是:
$ pg_ctl restart
重启服务器,等待其停止和重启:
$ pg_ctl -w restart
使用 5433 端口重启并且重启后关闭 fsync
:
$ pg_ctl -o "-F -p 5433" restart
显示服务器状态
下面是来自 pg_ctl 的状态输出的例子:
$ pg_ctl statuspg_ctl: server is running (pid: 13718)
Command line was:
/usr/local/pgsql/bin/postgres '-D' '/usr/local/pgsql/data' '-p' '5433' '-B' '128'
这就是在 restart 模式中被调用的命令行。
postgres
pg_resetxlog
pg_resetxlog -- 重置一个数据库集群的预写日志以及其它控制内容
pg_resetxlog
[-f] [-n] [-o
oid
] [-x
xid
] [-e
xid_epoch
] [-m
mxid
] [-O
mxoff
] [-l
timelineid
,
fileid
,
seg
]
datadir
pg_resetxlog
清理预写日志(WAL)并且可以有选择地重置其它一些存储在
pg_control
文件中的控制信息。有时候,如果这些文件崩溃了,就需要这个功能。一定只把它用作最后的方法,就是说只有因为这样的崩溃导致服务器无法启动的时候才使用。
运行这个命令之后,可能就可以启动服务器了,但是,一定要记住数据库可能因为部分提交的事务而含有不完整的数据。你应该马上转储数据,运行
initdb
,然后重新加载。在重新加载之后,检查不完整的部分然后根据需要进行修复。
这个命令只能由安装服务器的用户运行,因为它需要对数据目录的读写权限。出于安全考虑,
pg_resetxlog
不使用环境变量
PGDATA
,你必须在命令行上声明数据目录。
如果
pg_resetxlog
抱怨说它无法判断用于
pg_control
的有效数据,那么你可以强制它继续处理,方法是声明
-f
(强制)开关。在这种情况下,那些丢失了的数据将用模糊的近似数值代替。大多数字段都可以匹配上,但是下一个 OID 、下一个事务 ID 、下一个事务 ID 的 epoch(时间点)、下一个多事务 ID(两阶段提交的东西)、下一个多事务偏移量、WAL 开始地址、数据库区域字段可能需要手工帮助,前面六个可以用下面讨论的开关设置。
pg_resetxlog
自己的环境是猜测区域字段的来源;看看
LANG
等东西,它们应该和
initdb
运行的环境相匹配。如果你不能判断所有这些字段的正确数值,那么
-f
仍然可以使用,但是这样恢复过来的数据库正确性更值得怀疑:立即转储和重新加载是必须的。在转储之前
不要执行任何修改数据的操作,因为任何这样的动作都可能把事情搞得更糟糕。
-o
,
-x
,
-e
,
-m
,
-O
,
-l
开关允许手工设置下一个 OID 、下一个事务 ID 、下一个事务 ID epoch 、下一个多事务 ID 、下一个多事务偏移量、WAL 起始位置的数值。只有在
pg_resetxlog
无法通过读取
pg_control
判断合适的数值的时候才需要它。安全的数值可以用下面的方法判断:
对于下一个事务 ID(
-x
)而言,一个安全的数值是看看数据目录里的
pg_clog
里数值最大的文件名,然后加一,然后再乘上 1048576 。请注意那些文件名是十六进制的。通常也以十六进制的形式声明开关值是最简单的。比如,如果
0011
是
pg_clog
里最大的记录,
-x 0x1200000
就可以了(后面的五个零提供了合适的乘积)。
下一个多事务 ID(
-m
)的安全值可以通过查看数据目录里
pg_multixact/offsets
子目录里面的数字最大的文件名,加一,然后乘以 65536 得到。和上面一样,文件名是十六进制的,因此最简单的方法是给开关声明一个十六进制的开关值,然后在结尾加四个零。
下一个多事务偏移量(
-O
)的安全值可以通过检查数据目录里
pg_multixact/members
子目录下的数字最大的文件名,加一,然后乘以 65536 得到。和上面一样,文件名是十六进制的,因此最简单的方法是给开关声明一个十六进制的开关值,然后在结尾加四个零。
WAL 的起始位置(
-l
)应该比目前存在于数据目录
pg_xlog
里面的任何文件号都大。它的文件名也是十六进制的,并且有三部分。第一部分是"时间线 ID",通常应该保持相同。第三部分不要选择大于 255(
0xFF
);应该是在达到 255 的时候给第二部分增一然后重置第三部分为 0 。比如,如果
00000001000000320000004A
是
pg_xlog
里最大的条目,那么
-l 0x1,0x32,0x4B
就可以了;但如果最大的条目是
000000010000003A000000FF
,那么选择
-l 0x1,0x3B,0x0
或更多。
没有很容易的办法来判断比数据库中最大的 OID 大一号的下一个 OID ,不过很走运的是获取正确的下一个 OID 并非非常关键的事情。
除了由
pg_resetxlog
设定的字段外,事务 ID epoch 实际上并未存储在数据库里的任何地方。所以只要是涉及到数据库自身的任何数值都有效。你可能需要调整这个值以确保诸如
Slony-I 之类的备份系统能够正常工作。如果是这样的话,应当从下游已复制的数据库中获取恰当的值。
-n
(无操作)开关指示
pg_resetxlog
打印从
pg_control
重新构造的数值然后不修改任何值就退出。这主要是一个调试工具,但是在
pg_resetxlog
真正处理前进行的整洁性检查的时候可能会有用。
在服务器运行的时候一定不要运行这个命令。如果发现在数据文件目录里有锁文件,那么
pg_resetxlog
将拒绝启动。如果服务器崩溃,那么可能会剩下一个锁文件;如果这样,你可以删除该锁文件以便允许
pg_resetxlog
运行。但是在你这么做之前,一定要确保没有任何后端服务器进程仍在运行。
postgres
postgres -- PostgreSQL 数据库服务器