postgresql 错误 PANIC：找不到有效的检查点记录
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8799474/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
postgresql error PANIC: could not locate a valid checkpoint record
提问by nathan_scott
When I load up the postgres server (v9.0.1) i get a panic that prevents it from starting:
当我加载 postgres 服务器 (v9.0.1) 时，我感到恐慌，无法启动：
PANIC: could not locate a valid checkpoint record
PANIC：找不到有效的检查点记录
How can I fix this?
我怎样才能解决这个问题？
回答by Erwin Brandstetter
It's looking for a checkpoint record in the transaction log that probably doesn't exist or is corrupted. You can determine if this is the case by running:
它正在事务日志中寻找可能不存在或已损坏的检查点记录。您可以通过运行来确定是否是这种情况：
# Postgres < 10.0
pg_resetxlog DATADIR
# Postgres >= 10.0
pg_resetwal DATADIR
If the transaction log is corrupt, you'll see a message like:
如果事务日志已损坏，您将看到如下消息：
The database server was not shut down cleanly. Resetting the transaction log might cause data to be lost. If you want to proceed anyway, use -f to force reset.
数据库服务器没有完全关闭。重置事务日志可能会导致数据丢失。如果您仍然想继续，请使用 -f 强制重置。
You can then follow the instructions and run with -fto force the update:
然后，您可以按照说明运行并-f强制更新：
# Postgres < 10.0
pg_resetxlog -f DATADIR
# Postgres >= 10.0
pg_resetwal -f DATADIR
That should reset the transaction log, however it could leave your database in an indeterminate state as explained in the PostgreSQL documentation on
pg_resetxlog:
这应该会重置事务日志，但是它可能会使您的数据库处于不确定状态，如PostgreSQL 文档
pg_resetxlog中所述：
If pg_resetxlog complains that it cannot determine valid data for pg_control, you can force it to proceed anyway by specifying the
-f(force) switch. In this case plausible values will be substituted for the missing data. Most of the fields can be expected to match, but manual assistance might be needed for the next OID, next transaction ID and epoch, next multitransaction ID and offset, and WAL starting address fields. These fields can be set using the switches discussed below. If you are not able to determine correct values for all these fields,-fcan still be used, but the recovered database must be treated with even more suspicion than usual: an immediate dump and reload is imperative. Do not execute any data-modifying operations in the database before you dump, as any such action is likely to make the corruption worse.
如果 pg_resetxlog 抱怨它无法确定 pg_control 的有效数据，您可以通过指定
-f(force) 开关来强制它继续进行。在这种情况下，可能的值将替换缺失的数据。大多数字段预计会匹配，但下一个 OID、下一个事务 ID 和纪元、下一个多事务 ID 和偏移量以及 WAL 起始地址字段可能需要手动帮助。可以使用下面讨论的开关设置这些字段。如果您无法确定所有这些字段的正确值，-f仍然可以使用，但恢复的数据库必须比平时更加怀疑：立即转储和重新加载是必要的。在转储之前不要在数据库中执行任何数据修改操作，因为任何此类操作都可能使损坏变得更糟。
回答by limlam
I'm running 9.1.7 and i find ran the following successfully:
我正在运行 9.1.7，我发现成功运行了以下内容：
/usr/lib/postgresql/9.1/bin/pg_resetxlog -f /var/lib/postgresql/9.1/main
Your final argument to the pg_resetxlogcommand should be the location on disk where postgres stores your database data.
该pg_resetxlog命令的最后一个参数应该是 postgres 存储数据库数据的磁盘位置。
回答by Jerome
As indicated herepg_resetxlog should not be run. The answers that refer to this is bad advice. Assuming the error occured in a context of copy/replication instance, the link provides a more succinct way of doing copy/replication with pg_basebackup
如此处所示，不应运行 pg_resetxlog。提到这个的答案是不好的建议。假设错误发生在复制/复制实例的上下文中，该链接提供了一种更简洁的复制/复制方式pg_basebackup
回答by fdr
Do you do continuous archiving? If you are backing up at the time, you may find it more prudent to remove backup_label. pg_resetxlogis a severe thing.
你做连续存档吗？如果您当时正在备份，您可能会发现删除 backup_label 更为谨慎。 pg_resetxlog是很严重的事情。
回答by sgzhan
just like the log saying : could not locate a valid checkpoint record.Postgres can't find a properly WAL under the $PGDATA/pg_xlog/ directory. Try to use pg_resetxlog
就像日志说的那样：找不到有效的检查点记录。Postgres 在 $PGDATA/pg_xlog/ 目录下找不到正确的 WAL。尝试使用 pg_resetxlog
