当我加载 postgres 服务器(v9.0.1)时,我得到一个阻止它启动的恐慌:
PANIC:找不到有效的检查点记录
我怎样才能解决这个问题?
当我加载 postgres 服务器(v9.0.1)时,我得到一个阻止它启动的恐慌:
PANIC:找不到有效的检查点记录
我怎样才能解决这个问题?
它正在事务日志中查找可能不存在或已损坏的检查点记录。您可以通过运行来确定是否是这种情况:
# Postgres >= 10
pg_resetwal DATADIR
# Postgres < 10
pg_resetxlog DATADIR
如果事务日志已损坏,您将看到如下消息:
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
以强制更新:
# Postgres >= 10
pg_resetwal -f DATADIR
# Postgres < 10
pg_resetxlog -f DATADIR
那应该重置事务日志。但是,它可能会使您的数据库处于不确定状态,如PostgreSQL 文档pg_resetwal
中所述:
如果
pg_resetwal
抱怨它无法确定 的有效数据 ,您可以通过指定(force) 选项pg_control
强制它继续进行 。-f
在这种情况下,将用合理的值代替缺失的数据。大多数字段都可以匹配,但下一个 OID、下一个事务 ID 和 epoch、下一个多事务 ID 和偏移量以及 WAL 起始位置字段可能需要手动协助。可以使用下面讨论的选项设置这些字段。如果您无法确定所有这些字段的正确值,-f
仍然可以使用,但必须以比平时更加怀疑的方式对待恢复的数据库:立即转储和重新加载是必要的。在转储之前不要在数据库中执行任何数据修改操作,因为任何此类操作都可能使损坏变得更糟。
我正在运行 9.1.7,我发现成功运行了以下内容:
/usr/lib/postgresql/9.1/bin/pg_resetxlog -f /var/lib/postgresql/9.1/main
该命令的最后一个参数pg_resetxlog
应该是 postgres 存储数据库数据的磁盘位置。
如此处所示,不应运行 pg_resetxlog。提到这个的答案是不好的建议。假设错误发生在复制/复制实例的上下文中,该链接提供了一种更简洁的复制/复制方式pg_basebackup
您是否进行持续归档?如果您当时正在备份,您可能会发现删除 backup_label 更为谨慎。 pg_resetxlog
是一件很严重的事情。
我在这里遇到了一个没有重新启动的 Docker Postgresql-13。我通过查找卷(用于数据)并运行来修复它
在卷数据文件夹中,例如,/var/lib/docker/volumes/c4c8d637d9eee086265d732b2974690b731abcb23f47ca61bf75fe28526e31ce/_data
作为目录的所有者运行(对我来说,它是 systemd-coredump 用户)
sudo -u systemd-coredump /usr/lib/postgresql/13/bin/pg_resetwal -f .
确保您需要安装相同的 Postgresql 版本(如果pg_resetwal
不是卷的一部分)
工作过
就像日志说:找不到有效的检查点记录。Postgres 在 $PGDATA/pg_xlog/ 目录下找不到正确的 WAL。尝试使用 pg_resetxlog
此答案适用于 Postgres 14。在执行以下步骤后,我在备用日志中遇到了相同的错误:
pg_basebackup -D $APP_BACKUP_PATH -F t -P -v -U 复制器 -w --no-password -h 10.29.51.98
提取生成$APP_BACKUP_PATH/base.tar
到备用数据目录。
重新启动待机。启动失败,出现 : PANIC: could not locate a valid checkpoint record
。
因此,事实证明备份没有正确生成。它需要使用附加选项生成-X stream
。
在重新生成并将更新的备份应用到备用数据目录后,备用出现没有此错误。
对我来说,当我从 postgres 中删除包含数据的文件夹时它起作用了,所以它靠近其他解决方案,但有人解释说删除文件夹可能会解决问题。
所以:Ubuntu 20.04
一步步: