我查看了postgres文档,下面给出了概要:
pg_resetxlog [-f] [-n] [-ooid ] [-x xid ] [-e xid_epoch ] [-m mxid ] [-O mxoff ] [-l timelineid,fileid,seg ] datadir
但是文档中没有任何内容可以解释数据的含义。
它是%postgres-path%/9.0/data
还是%postgres-path%/9.0/data/pgxlog
?
另外,如果我想更改我的xlog目录,我可以简单地移动当前pg_xlog
目录中的项目并运行命令指向另一个目录吗? (假设我当前的pg_xlog目录位于/data1/postgres/data/pg_xlog
中,我想要的日志目录是:/data2/pg_xlog
)
以下命令会实现我刚刚描述的内容吗?
mv /data1/postgres/data/pg_xlog /data2/pg_xlog
pg_resetxlog /data2
答案 0 :(得分:6)
pg_resetxlog
是在以下情况下让您的数据库再次运行的最后工具:
您删除了pg_xlog
;
由于备份系统配置错误,您恢复了省略pg_xlog
目录的文件系统级备份(这种情况发生的次数超出了您的想象,人们认为“它已登录名称,因此它必须是不重要的;我会把它从备份中删除“)。
由于硬件故障或硬盘驱动器故障导致的文件系统损坏损坏了您的数据目录;甚至可能
PostgreSQL错误或操作系统错误损坏了预写日志(非常罕见)。
正如手册所说:
pg_resetxlog清除预写日志(WAL)[...]。这个 如果这些文件已损坏,有时需要函数。它 当服务器无法启动时,应该仅作为最后的手段使用 由于这种腐败。
除非您确切知道自己在做什么以及为什么,否则不要运行pg_resetxlog
。如果您不确定,请在pgsql-general mailing list或https://dba.stackexchange.com/上询问。
pg_resetxlog
可能会损坏您的数据库。如果必须使用它,则应REINDEX
,转储数据库,重新initdb并重新加载数据库。不要只是继续使用损坏的群集。根据文件:
运行此命令后,应该可以启动服务器, 但请记住,数据库可能包含不一致的数据 部分承诺的交易。你应该立即转储你的 数据,运行initdb和重新加载。重新加载后,检查是否存在不一致 并根据需要进行修理。
如果您只想将预写日志目录移动到其他位置,则应该:
pg_xlog
如果日志位于与其不同的磁盘上,则是有利的 主数据库文件。这可以通过移动pg_xlog来实现 目录到另一个位置(服务器关闭时) 当然)并从原始位置创建一个符号链接 主数据目录到新位置。
如果PostgreSQL无法启动,那你就做错了。不要使用pg_resetxlog
来“修复”它。撤消您的更改并找出您做错的事情。
答案 1 :(得分:2)
将pg_xlog目录的内容移动到所需位置,例如'/ home / foo / pg_xlog'
mv pg_xlog/* /home/foo/pg_xlog
删除pg_xlog目录
rm -rf pg_xlog
创建pg_xlog的软链接
ln -s /home/foo/pg_xlog pg_xlog
验证链接
ls -lrt pg_xlog
注意:pg_resetxlog不是移动pg_xlog的正确工具,请阅读
http://www.postgresql.org/docs/9.2/static/app-pgresetxlog.html
答案 2 :(得分:1)
数据目录对应于postgresql.conf文件中的data_directory
条目,或PGDATA
环境变量,也可以使用SHOW data_directory
语句在SQL中查询。它不指向pg_xlog
目录,而是指向上一级。
要更改WAL文件的位置,必须关闭PG服务器,将pg_xlog
目录及其内容移动到新位置,应从旧位置创建符号链接到新位置,并重新启动服务器。 pg_resetxlog
不应该用于此,因为它可能会抑制最新的事务(此工具通常用于所有其他方法都失败时的崩溃恢复情况)。
答案 3 :(得分:0)
你永远不应该手动触摸WAL文件,这是非常清楚的。
如果pg_xlog
目录中存在悬空文件,也就是说,子文件夹.done*
中存在以archive_status
结尾的文件,需要手动清理,可以使用sql命令
CHECKPOINT;
强制事务检查点,包括清理WAL段文件。
请参阅documentation for 9.3,但存在于Postgresql的所有当前版本中。