↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

受支持版本: 当前版本 (18) / 当前版本 (18) / 17 / 17 / 16 / 16 / 15 / 15 / 14 / 14
测试与开发版本: 19 / 19 / devel / devel
不受支持的版本: 13 / 13 / 12 / 12 / 11 / 11 / 10 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3
历史版本PostgreSQL 7.4 已于 2010 年 10 月结束社区维护,本页译文保留供仍在使用旧版本的读者参考。新系统请看当前版本。

pg_resetxlog

pg_resetxlog — 重置一个 PostgreSQL 数据库集簇的预写式日志和其他控制信息

大纲

pg_resetxlog [ -f ] [ -n ] [ -o oid ] [ -x xid ] [ -l fileid,seg ] datadir

描述

pg_resetxlog 清除预写日志(WAL), 并且可以选择性地重置一些其他的控制信息(存储在 pg_control 文件中)。如果这些文件已经被损坏, 有时就需要这个功能。它应当只作为最后的手段使用, 即当服务器因为这种损坏而无法启动时。

运行这个命令之后,应当就能启动服务器了,但请记住,由于部分提交的事务, 数据库可能包含不一致的数据。你应当立即转储你的数据,运行 initdb, 然后重新加载。重新加载之后,检查不一致之处并根据需要进行修复。

这个工具只能由安装服务器的用户运行,因为它需要对数据目录的读/写访问权限。 出于安全原因,你必须在命令行上指定数据目录。pg_resetxlog 不使用环境变量 PGDATA。

如果 pg_resetxlog 抱怨它无法为 pg_control 确定有效的数据, 你可以通过指定 -f(强制)开关强制它继续执行。在这种情况下, 将用合理的值替代缺失的数据。大多数字段可以期望是匹配的,但下一个 OID、 下一个事务 ID、WAL 起始地址和数据库区域字段可能需要人工辅助。 其中前三项可以使用下面讨论的开关来设置。pg_resetxlog 自己的环境是它对区域字段猜测的来源;请注意让 LANG 等等 与运行 initdb 时的环境相匹配。如果你无法为所有这些字段确定正确的值, 仍然可以使用 -f,但恢复出来的数据库必须比平时更加谨慎地对待:必须立即转储并重新加载。在转储之前不要 在数据库中执行任何修改数据的操作;因为任何这样的动作都很可能使损坏更加严重。

-o、-x 和 -l 开关允许手动设置下一个 OID、 下一个事务 ID 和 WAL 起始地址的值。只有在 pg_resetxlog 无法通过读取 pg_control 确定合适的值时才需要它们。 下一个事务 ID 的安全值可以这样确定:找出数据目录下的 pg_clog 目录中数值最大的 文件名,加一,然后乘以 1048576。注意文件名是十六进制的。 通常用十六进制指定开关值也最容易。例如,如果 0011 是 pg_clog 中最大的条目,那么 -x 0x1200000 就可以工作 (五个尾随零提供了正确的乘数)。WAL 起始地址应当大于 数据目录下 pg_xlog 目录中当前存在的任何文件编号。地址也是十六进制的,并且有两部分。 例如,如果 000000FF0000003A 是 pg_xlog 中最大的条目, 那么 -l 0xFF,0x3B 就可以工作。没有类似的简单方法来确定一个超过 数据库中最大 OID 的下一个 OID,但幸运的是,下一个 OID 设置得是否正确并不关键。

-n(无操作)开关指示 pg_resetxlog 打印从 pg_control 重构出来的值,然后不修改任何东西就退出。 这主要是一个调试工具,但在允许 pg_resetxlog 真正执行之前作为一次健全性检查可能很有用。

注解

当服务器正在运行时,不得使用这个命令。如果 pg_resetxlog 在数据目录中发现一个服务器锁文件,它将拒绝启动。如果 服务器崩溃了,那么可能残留了一个锁文件;这种情况下你可以删除该锁文件以允许 pg_resetxlog 运行。但在这样做之前,务必再三确认那里 没有 postmaster 或任何后端服务器进程仍然存活。

提交更正

译文有误、术语不当或页面显示问题,请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题,请在当前版本的对应页面向上游反馈;上游不再修订已结束维护的版本。