PostgreSQL未启动:致命: xlog刷新请求不满足？？只刷新到0。
我有一个带有本地Linux卷映射的Docker PostgreSQL (TimescaleDB) developer实例。
version: '3'
services:
dex-timeseriesdb:
image: timescale/timescaledb:latest-pg12
# https://stackoverflow.com/a/56754077/315168
shm_size: 1g
container_name: dex-timeseriesdb
environment:
POSTGRES_USER: postgres
volumes:
- $PWD/data/postgresql:/var/lib/postgresql/data在不干净的关闭之后，实例不再以FATAL: xlog flush request 0/2CEFA910 is not satisfied --- flushed only to 0/1B48258错误启动：
dex-timeseriesdb |
dex-timeseriesdb | PostgreSQL Database directory appears to contain a database; Skipping initialization
dex-timeseriesdb |
dex-timeseriesdb | 2021-06-13 18:50:47.330 UTC [1] LOG: starting PostgreSQL 12.6 on x86_64-pc-linux-musl, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 64-bit
dex-timeseriesdb | 2021-06-13 18:50:47.330 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
dex-timeseriesdb | 2021-06-13 18:50:47.330 UTC [1] LOG: listening on IPv6 address "::", port 5432
dex-timeseriesdb | 2021-06-13 18:50:47.336 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
dex-timeseriesdb | 2021-06-13 18:50:47.486 UTC [21] LOG: database system shutdown was interrupted; last known up at 2021-06-13 18:47:35 UTC
dex-timeseriesdb | 2021-06-13 18:50:49.629 UTC [21] LOG: database system was not properly shut down; automatic recovery in progress
dex-timeseriesdb | 2021-06-13 18:50:49.645 UTC [21] LOG: redo starts at 0/1B46C68
dex-timeseriesdb | 2021-06-13 18:50:49.648 UTC [21] LOG: invalid record length at 0/1B48258: wanted 24, got 0
dex-timeseriesdb | 2021-06-13 18:50:49.648 UTC [21] LOG: redo done at 0/1B48220
dex-timeseriesdb | 2021-06-13 18:50:49.697 UTC [21] LOG: request to flush past end of generated WAL; request 0/2CEFA910, currpos 0/1B48258
dex-timeseriesdb | 2021-06-13 18:50:49.697 UTC [21] CONTEXT: writing block 0 of relation base/13455/16573_vm
dex-timeseriesdb | 2021-06-13 18:50:49.697 UTC [21] FATAL: xlog flush request 0/2CEFA910 is not satisfied --- flushed only to 0/1B48258
dex-timeseriesdb | 2021-06-13 18:50:49.697 UTC [21] CONTEXT: writing block 0 of relation base/13455/16573_vm
dex-timeseriesdb | 2021-06-13 18:50:49.701 UTC [1] LOG: startup process (PID 21) exited with exit code 1
dex-timeseriesdb | 2021-06-13 18:50:49.701 UTC [1] LOG: aborting startup due to startup process failure
dex-timeseriesdb | 2021-06-13 18:50:49.744 UTC [1] LOG: database system is shut down这很可能是由于不干净的码头关机造成的数据损坏。
数据库中没有什么重要的东西。但是，我仍然想了解在这种情况下是否有可能恢复数据库，而不是从头开始重建数据库，或者从备份中恢复数据库。
我使用shell测试了这个卷映射在Docker实例中是可写的，所以这不应该是一个问题。
回答 1
Database Administration用户
发布于 2022-07-29 10:52:02
根据提供的日志，该问题与数据文件损坏有关--这可能是由于不正确的关闭造成的。其中一个数据文件已损坏。
文件位置应该是$PGDATA/base/13455/16573_vm
推荐行动：
首先，重要的是要记住，这个错误是关于写入数据目录的页面，而不是WAL流。这意味着，如果表的数据确实丢失了，那么这里的主要目的是从WAL流中获取数据的副本。
在我们详细讨论如何做到这一点之前，让我们先找出哪个表或索引会受到影响。
在日志消息invalid page in block 0 of relation base/13455/16573_vm中，我们得到以下信息：
- 16573是受影响的索引或表的pg_class.relfilenode值。
- 13455是数据库OID，即pg_database.oid
- 0是块号，从中可以确定文件段以及文件中的位置。
这意味着我们可以通过以下操作找到受影响的表，以找到正确的数据库：
SELECT datname FROM pg_database WHERE oid = 13455;然后连接到该数据库并运行以下操作，这将为我们提供受影响的表或索引：
SELECT relname, relkind FROM pg_class WHERE relfilenode = 16573;如果受影响的数据库对象是索引，那么它对您来说是幸运的--您可以重新构建索引来修复所有问题。
如果受影响的数据库对象是一个表--运气不好--可用的选项是：
- 失败到HA备用服务器/追随者数据库
- 从一个足够老的基本备份中重放WAL
- 接受一些数据丢失的事实，让Postgres继续前进。您可以尝试转储表的数据(在转储过程中可能会出现错误，并丢失一些数据)，然后截断表。
https://dba.stackexchange.com/questions/294204
复制相似问题
腾讯云开发者
