pg_resetxlog

PostgreSQL 9.4.4 中文手册
上一页 | 上一级 |  | 下一页

# pg_resetxlog

## 名称

pg_resetxlog -- 重置一个数据库集群的预写日志以及其它控制内容

## 大纲

`pg_resetxlog` [`-f`] [`-n`] [`-o` `oid`] [`-x` `xid`] [`-e` `xid_epoch`] [`-m` `mxid`,`mxid`] [`-O` `mxoff`] [`-l` `xlogfile`] `datadir`

## 描述

`pg_resetxlog`清理预写日志(WAL)并且可以有选择地重置其它一些存储在 `pg_control`文件中的控制信息。有时候，如果这些文件崩溃了，就需要这个功能。 一定只把它用作最后的方法，就是说只有因为这样的崩溃导致服务器无法启动的时候才使用。

运行这个命令之后，可能就可以启动服务器了，但是， 一定要记住数据库可能因为部分提交的事务而含有不完整的数据。你应该马上转储数据， 运行`initdb`，然后重新加载。在重新加载之后， 检查不完整的部分然后根据需要进行修复。

这个命令只能由安装服务器的用户运行，因为它需要对数据目录的读写权限。 出于安全考虑，`pg_resetxlog`不使用环境变量`PGDATA`， 你必须在命令行上声明数据目录。

如果`pg_resetxlog`抱怨说它无法判断用于`pg_control` 的有效数据，那么你可以强制它继续处理，方法是声明`-f`(强制)开关。 在这种情况下，那些丢失了的数据将用模糊的近似数值代替。大多数字段都可以匹配上， 但是下一个 OID 、下一个事务 ID 、下一个事务 ID 的 epoch(时间点)、 下一个多事务 ID(两阶段提交的东西)、下一个多事务偏移量、WAL 开始地址可能需要手工帮助， 这些字段可以使用下面讨论的选项设置。如果你不能判断所有这些字段的正确数值， 那么`-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 得到。相反的，最老多事务ID（`-m`的第二部分） 的安全值可以通过查看相同目录里的数字最小的文件名，然后乘以65536得到。 和上面一样，文件名是十六进制的，因此最简单的方法是给选项声明一个十六进制的开关值， 然后在结尾加四个零。

- 下一个多事务偏移量(`-O`)的安全值可以通过检查数据目录里 `pg_multixact/members`子目录下的数字最大的文件名，加一， 然后乘以 65536 得到。和上面一样，文件名是十六进制的。 这里没有像上面一样添加零的简单方法。

- WAL 的起始位置(`-l`)应该比目前存在于数据目录`pg_xlog` 里面的任何WAL段文件号都大。它的文件名也是十六进制的，并且有三部分。 第一部分是"时间线 ID"，通常应该保持相同。比如， 如果`00000001000000320000004A`是`pg_xlog`里最大的条目， 那么选择`-l 00000001000000320000004B`或更多。

  > 注意: `pg_resetxlog`本身查看`pg_xlog`里面的文件， 并选择一个缺省的超过最后一个现存文件号的`-l`设置。因此， 只有知道WAL段文件当前不在`pg_xlog`中时，才需要手动调整`-l`， 例如离线归档中的条目；或如果`pg_xlog`的内容完全丢失。

- 没有很容易的办法来判断比数据库中最大的 OID 大一号的下一个 OID ， 不过很走运的是获取正确的下一个 OID 并非非常关键的事情。

- 除了由`pg_resetxlog`设定的字段外， 事务 ID epoch 实际上并未存储在数据库里的任何地方。 所以只要是涉及到数据库自身的任何数值都有效。你可能需要调整这个值以确保诸如 Slony-I之类的备份系统能够正常工作。如果是这样的话， 应当从下游已复制的数据库中获取恰当的值。

`-n`(无操作)选项指示`pg_resetxlog`打印从 `pg_control`重新构造的数值和要修改的数值，然后不修改任何值就退出。这主要是一个调试工具， 但是在`pg_resetxlog`真正处理前进行的合理性检查的时候可能会有用。

`-V` 和 `--version`选项打印pg_resetxlog 的版本然后退出。选项`-?` 和 `--help`显示参数的支持信息然后退出。

## 注意

在服务器运行的时候一定不要运行这个命令。如果发现在数据文件目录里有锁文件， 那么`pg_resetxlog`将拒绝启动。如果服务器崩溃， 那么可能会留下一个锁文件；如果这样，你可以删除该锁文件以便允许 `pg_resetxlog`运行。但是在你这么做之前， 一定要确保没有任何后端服务器进程仍在运行。

上一页 | 起始页 | 下一页
pg_ctl | 上一级 | postgres