PostgreSQL最后的救命稻草 — pg_resetwal

精选原创

李先生lxs 2023-05-05 11:01:51 博主文章分类：PostgreSQL数据库 ©著作权

文章标签 数据库 pg_resetwal 恢复数据库 pg控制文件丢失 文章分类 运维 yyds干货盘点

©著作权归作者所有：来自51CTO博客作者李先生lxs的原创作品，请联系作者获取转载授权，否则将追究法律责任

数据库出现故障，就像陷入泥潭的大象。本文就主要介绍PostgreSQL数据库最后的救命稻草 — pg_resetwal

pg_resetwal— 重置 PostgreSQL 数据库集群的预写日志和其他控制信息

适用版本：PostgreSQL 12/13/14/15

PostgreSQL最后的救命稻草 — pg_resetwal_pg_resetwal

语法

pg_resetwal [ -f | --force ] [ -n | --dry-run ] [option...] [ -D | --pgdata ]datadir

描述

pg_resetwal 清除预写日志WAL，并可选地重置pg_control文件中的一些其他控制信息。当WAL文件或pg_control控制文件损坏时，导致数据库无法启动时，该操作将作为数据库修复的最后手段使用。

通过pg_resetwal修复而启动数据库后，可能会由于部分提交的事务，导致数据库可能存在数据不一致的情况。所以，应该立即转储数据，建议重新初始化新的数据库恢复。恢复后再检查不一致，并根据需要进一步修复。

pg_resetwal只能由安装数据库用户运行，因为它需要对数据目录进行读/写访问。注意：考虑安全原因，pg_resetwal不使用环境变量PGDATA，所以必须在命令行上指定数据目录。

如果pg_resetwal提示无法确定pg_control的有效数据，可以通过指定-f（force）选项强制继续执行。大多数字段可以自动匹配，但下一个OID、下一个事务ID和epoch、下一多事务ID和偏移量以及WAL起始位置字段值可能需要手动指定。可以使用一些选项设置这些字段值。如果无法确定这些字段的正确值，也可使用-f，但必须对恢复的数据库更为严谨的处理：必须立即转储和恢复。在转储之前，不要在数据库中执行任何数据修改操作，因为任何此类操作都可能会使损坏更严重。

命令帮助

[postgres@lyp ~]$ pg_resetwal --help
pg_resetwal resets the PostgreSQL write-ahead log.

Usage:
  pg_resetwal [OPTION]... DATADIR

Options:
  -c, --commit-timestamp-ids=XID,XID    设置带有提交时间戳的最早和最新事务（零表示没有更改）
 [-D, --pgdata=]DATADIR                 数据目录
  -e, --epoch=XIDEPOCH                  设置下一个事务ID纪元epoch
  -f, --force                           强制更新完成
  -l, --next-wal-file=WALFILE           设置新WAL的最小起始位置
  -m, --multixact-ids=MXID,MXID         设置下一个和最旧的多事务ID
  -n, --dry-run                         没有更新，只显示将要执行的操作
  -o, --next-oid=OID                    设置下一个OID
  -O, --multixact-offset=OFFSET         设置下一个多事务偏移量
  -V, --version                         输出版本信息，然后退出
  -x, --next-transaction-id=XID         设置下一个事务ID
      --wal-segsize=SIZE                WAL段的大小（MB）
  -?, --help                            

Report bugs to <pgsql-bugs@lists.postgresql.org>.
PostgreSQL home page: <https://www.postgresql.org/>
[postgres@lyp ~]$

选项详解

只有当pg_resetwal无法通过读取pg_control来确定适当的值时，才需要以下选项。对于采用数字参数的值，可以使用前缀0x指定十六进制值。

-c xid1,xid2 --commit-timestamp-ids=xid1,xid2
手动设置可以检索提交时间的最旧和最新事务ID。
xid1：可以通过在$PGDATA/pg_commit_ts目录中查找数值最小的文件名来确定可以检索提交时间的最旧事务ID的安全值（第一部分）。xid2：相反，可以通过在同一目录中查找数值最大的文件名来确定可以检索提交时间的最新事务ID的安全值。文件名为十六进制。
-e xid_epoch --epoch=xid_epoch
手动设置下一个事务ID的epoch。
事务ID epoch实际上并没有保存在数据库中的任何位置，除非存储在由pg_resetwal设置的字段中，因此就数据库本身而言，任何值都是有效的。您可能需要调整此值，以确保复制系统（如Slony-I和Skytools）正常工作-如果是这样，应该可以从下游复制数据库的状态获得适当的值。
-l walfile --next-wal-file=walfile
通过指定下一个WAL段文件的名称，手动设置WAL起始位置。
可以通过$PGDATA/pg_wal目录中查找数值最新的WAL段的文件名，+1。这些名称也是十六进制的，有三个部分。第一部分是“时间线ID”，通常应保持不变。例如，如果0000000100000009000000B7是pg_wal中最大的条目，请使用-l 0000000100000009000000B8或更高。注意，当使用非默认WAL段大小时，WAL文件名中的数字与系统函数和系统视图报告的LSN不同。此选项采用WAL文件名，而不是LSN。
格式：-l 0000000100000009000000B8
-m mxid1,mxid2 --multixact-ids=mxid1,mxid2
手动设置下一个和最旧的多事务ID。
mxid1：下一个多事务ID的安全值可以通过在$PGDATA/pg_multixact/offsets目录中查找数值最大的文件名，+1，然后乘以65536（0x10000）来确定。mxid2：相反，最旧的多事务ID的安全值可以通过$PGDATA/pg_multixact/offsets目录中数字最小的文件名，乘以65536来确定。文件名是十六进制的，因此最简单的方法是以十六进制指定选项值并附加四个零。
注意：若当前值为0，那么mxid2亦为0，则mxid2取mxid1的值。
格式：-m 0x10000, 0x100000

-o oid --next-oid=oid
手动设置下一个OID。
没有相对简单的方法来确定下一个超出数据库中最大OID的OID，但幸运的是，正确设置下一个OID并不重要。
-O mxoff --multixact-offset=mxoff
手动设置下一个多事务处理偏移量。
安全值可以通过在$PGDATA/pg_multixact/members目录中查找数值最大的文件名，+1，然后乘以52352（0xCC80）来确定。文件名为十六进制。没有像附加零的其他选项那样的简单方法。
若找到最大值0000，+1，乘以 52352 (0xCC80)，这个需要进行计算，没有简单的加0的方法。格式：0xCC80
若找到最大值00C1(193)，+1，乘以 52352 (0xCC80)。最后得值：（193+1）* 52352 = 4918288。16进制为：4B0C10，结果为：0x004B0C10
--wal-segsize=wal_segment_size
设置新的WAL段大小（MB）。该值必须设置为介于1和1024（兆字节）之间的2的幂。

虽然pg_resetwal会将WAL起始地址设置在最新的现有WAL段文件之外，但某些段大小的更改可能会导致重用以前的WAL文件名。如果WAL文件名重叠会导致归档策略出现问题，建议将-l与此选项一起使用以手动设置WAL起始地址。

-u xid --oldest-transaction-id=xid
手动设置最旧的未冻结交易ID。
可以通过在$PGDATA/pg_xact目录中查找数值最小的文件名，然后乘以1048576（0x100000）来确定安全值。请注意，文件名是十六进制的，因此最简单的方法是以十六进制指定选项值并附加五个零。例如，如果0007是pg_xact中最小的条目，-u 0x700000将起作用。
-x xid --next-transaction-id=xid
手动设置下一个事务ID。
安全值可以通过在$PGDATA/pg_xact目录中查找数值最大的文件名，+1，然后乘以1048576（0x100000）来确定。请注意，文件名是十六进制的。，因此最简单的方法是以十六进制指定选项值并附加五个零。例如，如果0011是pg_xact中最大的条目，-x 0x1200000将起作用（五个尾随零提供正确的乘数）。

使用案例

pg_resetwal用于丢失一些文件导致数据库无法启动进行修复。需要再次强调，pg_resetwal并不是日常使用的工具，是数据库最后的修复手段。常规性恢复请使用常规手段进行。

使用pg_resetwal修复的数据库，一般会正常启动，但是可能会因为参数的不准确而导致数据库存在其他异常问题。

如果因为丢失WAL文件导致数据库不一致，或者控制文件丢失，那么我们只需要通过这个工具生成一个最新的文件就可以强制打开数据库了。

重置WAL

创建测试数据

[postgres@lyp pg_wal]$ psql
psql (14.1)
Type "help" for help.

postgres=# create table lxs1(id int);
CREATE TABLE
postgres=# insert into lxs1 values(1);
INSERT 0 1
postgres=# insert into lxs1 values(2);
INSERT 0 1
postgres=# checkpoint;
CHECKPOINT
postgres=# insert into lxs1 values(3);
INSERT 0 1
postgres=#

模拟数据库异常

[postgres@lyp pg_wal]$ ps -ef |grep postgres
root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
postgres  19865      1  0 16:54 ?        00:00:00 /opt/pgsql14.1/bin/postgres
postgres  19866  19865  0 16:54 ?        00:00:00 postgres: logger 
postgres  19868  19865  0 16:54 ?        00:00:00 postgres: checkpointer 
postgres  19869  19865  0 16:54 ?        00:00:00 postgres: background writer
postgres  19870  19865  0 16:54 ?        00:00:00 postgres: walwriter 
postgres  19871  19865  0 16:54 ?        00:00:00 postgres: autovacuum launcher
postgres  19872  19865  0 16:54 ?        00:00:00 postgres: archiver failed on 000000010000000000000012
postgres  19873  19865  0 16:54 ?        00:00:00 postgres: stats collector 
postgres  19874  19865  0 16:54 ?        00:00:00 postgres: logical replication launcher
postgres  19883  19865  0 16:55 ?        00:00:00 postgres: postgres postgres [local] idle
postgres  19899  19791  0 16:55 pts/2    00:00:00 ps -ef
postgres  19900  19791  0 16:55 pts/2    00:00:00 grep --color=auto postgres
[postgres@lyp pg_wal]$ kill -9 19865
[postgres@lyp pg_wal]$ ps -ef |grep postgres
root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
postgres  19901  19791  0 16:55 pts/2    00:00:00 ps -ef
postgres  19902  19791  0 16:55 pts/2    00:00:00 grep --color=auto postgres
[postgres@lyp pg_wal]$

删除WAL文件

[postgres@lyp ~]$ cd $PGDATA/pg_wal
[postgres@lyp pg_wal]$ ls -lrt
total 196620
-rw-------. 1 postgres postgres 16777216 Feb 21  2022 000000010000000000000007
-rw-------. 1 postgres postgres 16777216 Feb 21  2022 000000010000000000000008
-rw-------. 1 postgres postgres      345 Feb 21  2022 000000010000000000000008.00000028.backup
-rw-------. 1 postgres postgres 16777216 Feb 22  2022 000000010000000000000009
-rw-------. 1 postgres postgres 16777216 Feb 22  2022 00000001000000000000000A
-rw-------. 1 postgres postgres      318 Feb 22  2022 00000001000000000000000A.00000028.backup
-rw-------. 1 postgres postgres 16777216 Feb 24  2022 00000001000000000000000B
-rw-------. 1 postgres postgres 16777216 Feb 24  2022 00000001000000000000000C
-rw-------. 1 postgres postgres 16777216 Feb 25  2022 00000001000000000000000D
-rw-------. 1 postgres postgres 16777216 May 10  2022 00000001000000000000000E
-rw-------. 1 postgres postgres 16777216 Nov 19 23:13 00000001000000000000000F
-rw-------. 1 postgres postgres 16777216 Nov 26 18:21 000000010000000000000010
-rw-------. 1 postgres postgres 16777216 Mar 13 16:52 000000010000000000000011
-rw-------. 1 postgres postgres 16777216 Mar 13 16:52 000000010000000000000012
drwx------. 2 postgres postgres     4096 Mar 13 16:52 archive_status
-rw-------. 1 postgres postgres 16777216 Mar 13 16:52 000000010000000000000013
[postgres@lyp pg_wal]$ 
[postgres@lyp pg_wal]$ rm -rf 0000000100000000000000*
[postgres@lyp pg_wal]$ 
[postgres@lyp pg_wal]$ ls -lrt
total 4
drwx------. 2 postgres postgres 4096 Mar 13 16:52 archive_status
[postgres@lyp pg_wal]$

尝试启动数据库

[postgres@lyp pg_wal]$ pg_ctl start
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2023-03-13 16:56:07.956 CST [19916] LOG:  redirecting log output to logging collector process
2023-03-13 16:56:07.956 CST [19916] HINT:  Future log output will appear in directory "log".
 stopped waiting
pg_ctl: could not start server
Examine the log output.
[postgres@lyp pg_wal]$

重置WAL

[postgres@lyp pg_wal]$ pg_resetwal $PGDATA
The database server was not shut down cleanly.
Resetting the write-ahead log might cause data to be lost.
If you want to proceed anyway, use -f to force reset.
[postgres@lyp pg_wal]$ pg_resetwal -f $PGDATA
Write-ahead log reset
[postgres@lyp pg_wal]$ ls -lrt
total 16384
drwx------. 2 postgres postgres        6 Mar 13 17:03 archive_status
-rw-------. 1 postgres postgres 16777216 Mar 13 17:03 000000010000000000000014
[postgres@lyp pg_wal]$

启动数据库

[postgres@lyp pg_wal]$ pg_ctl start
waiting for server to start....2023-03-13 17:04:10.205 CST [20173] LOG:  redirecting log output to logging collector process
2023-03-13 17:04:10.205 CST [20173] HINT:  Future log output will appear in directory "log".
 done
server started
[postgres@lyp pg_wal]$ psql
psql (14.1)
Type "help" for help.

postgres=# select * from lxs1;
 id 
----
  1
  2
(2 rows)

postgres=#

可以看到测试数据中checkpoint检查点后的数据，由于WAL重置而丢失。

重建控制文件

创建测试数据

[postgres@lyp pg_wal]$ psql
psql (14.1)
Type "help" for help.

postgres=# drop table lxs1;
DROP TABLE
postgres=# create table lxs1(id int);
CREATE TABLE
postgres=# insert into lxs1 values(1);
INSERT 0 1
postgres=# insert into lxs1 values(2);
INSERT 0 1
postgres=# checkpoint;
CHECKPOINT
postgres=# insert into lxs1 values(3);
INSERT 0 1
postgres=#

模拟数据库异常

[postgres@lyp pg_wal]$ ps -ef |grep postgres
root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
root      19965  19924  0 16:56 pts/0    00:00:00 su - postgres
postgres  19966  19965  0 16:56 pts/0    00:00:00 -bash
postgres  20013  19966  0 16:56 pts/0    00:00:00 tail -100f postgresql-2023-03-13_072.log
postgres  20272      1  0 17:08 ?        00:00:00 /opt/pgsql14.1/bin/postgres
postgres  20273  20272  0 17:08 ?        00:00:00 postgres: logger 
postgres  20275  20272  0 17:08 ?        00:00:00 postgres: checkpointer 
postgres  20276  20272  0 17:08 ?        00:00:00 postgres: background writer
postgres  20277  20272  0 17:08 ?        00:00:00 postgres: walwriter 
postgres  20278  20272  0 17:08 ?        00:00:00 postgres: autovacuum launcher
postgres  20279  20272  0 17:08 ?        00:00:00 postgres: archiver failed on 000000010000000000000015
postgres  20280  20272  0 17:08 ?        00:00:00 postgres: stats collector 
postgres  20281  20272  0 17:08 ?        00:00:00 postgres: logical replication launcher
postgres  20288  20272  0 17:08 ?        00:00:00 postgres: postgres postgres [local] idle
postgres  20359  19791  0 17:10 pts/2    00:00:00 ps -ef
postgres  20360  19791  0 17:10 pts/2    00:00:00 grep --color=auto postgres
[postgres@lyp pg_wal]$ kill -9 20272
[postgres@lyp pg_wal]$ ps -ef |grep postgres
root      19555  13684  0 16:49 pts/1    00:00:00 su - postgres
postgres  19556  19555  0 16:49 pts/1    00:00:00 -bash
postgres  19767  19556  0 16:52 pts/1    00:00:00 psql
root      19790  18013  0 16:53 pts/2    00:00:00 su - postgres
postgres  19791  19790  0 16:53 pts/2    00:00:00 -bash
root      19965  19924  0 16:56 pts/0    00:00:00 su - postgres
postgres  19966  19965  0 16:56 pts/0    00:00:00 -bash
postgres  20013  19966  0 16:56 pts/0    00:00:00 tail -100f postgresql-2023-03-13_072.log
postgres  20361  19791  0 17:11 pts/2    00:00:00 ps -ef
postgres  20362  19791  0 17:11 pts/2    00:00:00 grep --color=auto postgres
[postgres@lyp pg_wal]$

破坏控制文件

[postgres@lyp pg_wal]$ cd $PGDATA/global
[postgres@lyp global]$ ls -rlt pg_control 
-rw-------. 1 postgres postgres 8192 Mar 13 17:08 pg_control
[postgres@lyp global]$ echo "" >pg_control 
[postgres@lyp global]$ ls -rlt pg_control 
-rw-------. 1 postgres postgres 1 Mar 13 17:12 pg_control
[postgres@lyp global]$

尝试启动数据库

[postgres@lyp global]$ pg_ctl start
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2023-03-13 17:13:06.788 CST [20419] PANIC:  could not read file "global/pg_control": read 1 of 296
 stopped waiting
pg_ctl: could not start server
Examine the log output.
[postgres@lyp global]$

重建控制文件

pg_resetwal重建控制文件，需要参数如下：

-l walfile --next-wal-file=walfile
通过指定下一个WAL段文件的名称，手动设置WAL起始位置。
可以通过$PGDATA/pg_wal目录中查找数值最新的WAL段的文件名，+1。

[postgres@lyp global]$ cd $PGDATA/pg_wal
[postgres@lyp pg_wal]$ ls -lrt
total 32768
-rw-------. 1 postgres postgres 16777216 Mar 13 17:08 000000010000000000000015
drwx------. 2 postgres postgres       44 Mar 13 17:08 archive_status
-rw-------. 1 postgres postgres 16777216 Mar 13 17:09 000000010000000000000016
[postgres@lyp pg_wal]$

当前000000010000000000000016是pg_wal中最大的条目，则使用-l 000000010000000000000017

-m mxid1,mxid2 --multixact-ids=mxid1,mxid2
手动设置下一个和最旧的多事务ID。
mxid1：下一个多事务ID的安全值可以通过在$PGDATA/pg_multixact/offsets目录中查找数值最大的文件名，+1，然后乘以65536（0x10000）来确定。mxid2：相反，最旧的多事务ID的安全值可以通过$PGDATA/pg_multixact/offsets目录中数字最小的文件名，乘以65536来确定。文件名是十六进制的，因此最简单的方法是以十六进制指定选项值并附加四个零。
注意：若当前值为0，那么mxid2亦为0，则mxid2取mxid1的值。

[postgres@lyp offsets]$ ls -lrt
total 8
-rw-------. 1 postgres postgres 8192 Mar 13 17:08 0000
[postgres@lyp offsets]$

当前值为0000，则mxid1为：0x10000，mxid2取mxid1的值，则使用-m 0x10000,0x10000

-O mxoff --multixact-offset=mxoff
手动设置下一个多事务处理偏移量。
安全值可以通过在$PGDATA/pg_multixact/members目录中查找数值最大的文件名，+1，然后乘以52352（0xCC80）来确定。文件名为十六进制。没有像附加零的其他选项那样的简单方法。

[postgres@lyp members]$ ls -rlt
total 8
-rw-------. 1 postgres postgres 8192 Feb 21  2022 0000
[postgres@lyp members]$

当前值为0000，则使用-O 0xCC80

-x xid --next-transaction-id=xid
手动设置下一个事务ID。
安全值可以通过在$PGDATA/pg_xact目录中查找数值最大的文件名，+1，然后乘以1048576（0x100000）来确定。请注意，文件名是十六进制的。，因此最简单的方法是以十六进制指定选项值并附加五个零。

[postgres@lyp members]$ cd $PGDATA/pg_xact
[postgres@lyp pg_xact]$ ls -rlt
total 8
-rw-------. 1 postgres postgres 8192 Mar 13 17:08 0000
[postgres@lyp pg_xact]$

当前值为0000，则使用-x 0x100000

重建控制文件

[postgres@lyp global]$ pg_resetwal -l 000000010000000000000017 -m 0x10000,0x10000 -O 0xCC80 -x 0x100000 $PGDATA
pg_resetwal: error: lock file "postmaster.pid" exists
pg_resetwal: Is a server running?  If not, delete the lock file and try again.
[postgres@lyp global]$

由于是数据异常关闭，所以存在锁文件，删除后重新执行。

[postgres@lyp global]$ ls -rlt $PGDATA/postmaster.pid
-rw-------. 1 postgres postgres 39 Mar 13 17:13 /opt/pgdata14.1/postmaster.pid
[postgres@lyp global]$ rm -rf  $PGDATA/postmaster.pid
[postgres@lyp global]$ pg_resetwal -l 000000010000000000000017 -m 0x10000,0x10000 -O 0xCC80 -x 0x100000 $PGDATA
pg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring it
Guessed pg_control values:

pg_control version number:            1300
Catalog version number:               202107181
Database system identifier:           7209963927373898017
Latest checkpoint's TimeLineID:       1
Latest checkpoint's full_page_writes: off
Latest checkpoint's NextXID:          0:3
Latest checkpoint's NextOID:          12000
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        3
Latest checkpoint's oldestXID's DB:   0
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 0
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Size of a large-object chunk:         2048
Date/time type storage:               64-bit integers
Float8 argument passing:              by value
Data page checksum version:           0


Values to be changed:

First log segment after reset:        000000010000000000000017
NextMultiXactId:                      65536
OldestMultiXid:                       65536
OldestMulti's DB:                     0
NextMultiOffset:                      52352
NextXID:                              1048576
OldestXID:                            3
OldestXID's DB:                       0

If these values seem acceptable, use -f to force reset.
[postgres@lyp global]$ 
[postgres@lyp global]$ pg_resetwal -l 000000010000000000000017 -m 0x10000,0x10000 -O 0xCC80 -x 0x100000 $PGDATA -f
pg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring it
Write-ahead log reset
[postgres@lyp global]$ 
[postgres@lyp global]$ ls -rlt pg_control 
-rw-------. 1 postgres postgres 8192 Mar 13 17:43 pg_control
[postgres@lyp global]$

启动数据库

[postgres@lyp global]$ pg_ctl start
waiting for server to start....2023-03-13 17:44:00.209 CST [20785] LOG:  redirecting log output to logging collector process
2023-03-13 17:44:00.209 CST [20785] HINT:  Future log output will appear in directory "log".
 done
server started
[postgres@lyp global]$ psql
psql (14.1)
Type "help" for help.

postgres=# select * from lxs1;
 id 
----
  1
  2
(2 rows)

postgres=#

可以看到测试数据中checkpoint检查点后的数据，由于控制文件重置而丢失。

注意

注意据库正在运行时，不得使用此命令。
如果pg_resetwal在数据目录中找到服务器锁定文件，将启动失败。
如果数据库已崩溃，那么可能会留下一个锁文件（postmaster.pid）；在这种情况下，可以删除锁定文件以保证pg_resetwal的正常运行。但在此操作之前，需要再次确保没有数据库进程在运行。
pg_resetwal仅适用于相同主版本的数据库服务器。

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯