浙江住房和城乡建设厅网站百度竞价培训班
pg_resetwal
— 重置 PostgreSQL 数据库集群的预写日志和其他控制信息
适用版本:PostgreSQL 12/13/14/15
语法
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_resetwa
l 提示无法确定pg_control的有效数据,可以通过指定-f(force)选项强制继续执行。大多数字段可以自动匹配,但下一个OID、下一个事务ID和epoch、下一多事务ID和偏移量以及WAL起始位置字段值可能需要手动指定。可以使用一些选项设置这些字段值。如果无法确定这些字段的正确值,也可使用-f,但必须对恢复的数据库更为严谨的处理:必须立即转储和恢复。在转储之前,不要在数据库中执行任何数据修改操作,因为任何此类操作都可能会使损坏更严重。
命令帮助
[postgres@lyp ~]$ pg_resetwal --helppg_resetwal resets the PostgreSQL write-ahead log.Usage:pg_resetwal [OPTION]... DATADIROptions:-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]$ psqlpsql (14.1)Type "help" for help.postgres=# create table lxs1(id int);CREATE TABLEpostgres=# insert into lxs1 values(1);INSERT 0 1postgres=# insert into lxs1 values(2);INSERT 0 1postgres=# checkpoint;CHECKPOINTpostgres=# insert into lxs1 values(3);INSERT 0 1postgres=#
模拟数据库异常
[postgres@lyp pg_wal]$ ps -ef |grep postgresroot 19555 13684 0 16:49 pts/1 00:00:00 su - postgrespostgres 19556 19555 0 16:49 pts/1 00:00:00 -bashpostgres 19767 19556 0 16:52 pts/1 00:00:00 psqlroot 19790 18013 0 16:53 pts/2 00:00:00 su - postgrespostgres 19791 19790 0 16:53 pts/2 00:00:00 -bashpostgres 19865 1 0 16:54 ? 00:00:00 /opt/pgsql14.1/bin/postgrespostgres 19866 19865 0 16:54 ? 00:00:00 postgres: loggerpostgres 19868 19865 0 16:54 ? 00:00:00 postgres: checkpointerpostgres 19869 19865 0 16:54 ? 00:00:00 postgres: background writerpostgres 19870 19865 0 16:54 ? 00:00:00 postgres: walwriterpostgres 19871 19865 0 16:54 ? 00:00:00 postgres: autovacuum launcherpostgres 19872 19865 0 16:54 ? 00:00:00 postgres: archiver failed on 000000010000000000000012postgres 19873 19865 0 16:54 ? 00:00:00 postgres: stats collectorpostgres 19874 19865 0 16:54 ? 00:00:00 postgres: logical replication launcherpostgres 19883 19865 0 16:55 ? 00:00:00 postgres: postgres postgres [local] idlepostgres 19899 19791 0 16:55 pts/2 00:00:00 ps -efpostgres 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 postgresroot 19555 13684 0 16:49 pts/1 00:00:00 su - postgrespostgres 19556 19555 0 16:49 pts/1 00:00:00 -bashpostgres 19767 19556 0 16:52 pts/1 00:00:00 psqlroot 19790 18013 0 16:53 pts/2 00:00:00 su - postgrespostgres 19791 19790 0 16:53 pts/2 00:00:00 -bashpostgres 19901 19791 0 16:55 pts/2 00:00:00 ps -efpostgres 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 -lrttotal 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 000000010000000000000012drwx------. 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 -lrttotal 4drwx------. 2 postgres postgres 4096 Mar 13 16:52 archive_status[postgres@lyp pg_wal]$
尝试启动数据库
[postgres@lyp pg_wal]$ pg_ctl startpg_ctl: another server might be running; trying to start server anywaywaiting for server to start....2023-03-13 16:56:07.956 CST [19916] LOG: redirecting log output to logging collector process2023-03-13 16:56:07.956 CST [19916] HINT: Future log output will appear in directory "log".stopped waitingpg_ctl: could not start serverExamine the log output.[postgres@lyp pg_wal]$
重置WAL
[postgres@lyp pg_wal]$ pg_resetwal $PGDATAThe 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 $PGDATAWrite-ahead log reset[postgres@lyp pg_wal]$ ls -lrttotal 16384drwx------. 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 startwaiting for server to start....2023-03-13 17:04:10.205 CST [20173] LOG: redirecting log output to logging collector process2023-03-13 17:04:10.205 CST [20173] HINT: Future log output will appear in directory "log".doneserver started[postgres@lyp pg_wal]$ psqlpsql (14.1)Type "help" for help.postgres=# select * from lxs1;id----12(2 rows)postgres=#
可以看到测试数据中 checkpoint
检查点后的数据,由于WAL重置而丢失。
重建控制文件
创建测试数据
[postgres@lyp pg_wal]$ psqlpsql (14.1)Type "help" for help.postgres=# drop table lxs1;DROP TABLEpostgres=# create table lxs1(id int);CREATE TABLEpostgres=# insert into lxs1 values(1);INSERT 0 1postgres=# insert into lxs1 values(2);INSERT 0 1postgres=# checkpoint;CHECKPOINTpostgres=# insert into lxs1 values(3);INSERT 0 1postgres=#
模拟数据库异常
[postgres@lyp pg_wal]$ ps -ef |grep postgresroot 19555 13684 0 16:49 pts/1 00:00:00 su - postgrespostgres 19556 19555 0 16:49 pts/1 00:00:00 -bashpostgres 19767 19556 0 16:52 pts/1 00:00:00 psqlroot 19790 18013 0 16:53 pts/2 00:00:00 su - postgrespostgres 19791 19790 0 16:53 pts/2 00:00:00 -bashroot 19965 19924 0 16:56 pts/0 00:00:00 su - postgrespostgres 19966 19965 0 16:56 pts/0 00:00:00 -bashpostgres 20013 19966 0 16:56 pts/0 00:00:00 tail -100f postgresql-2023-03-13_072.logpostgres 20272 1 0 17:08 ? 00:00:00 /opt/pgsql14.1/bin/postgrespostgres 20273 20272 0 17:08 ? 00:00:00 postgres: loggerpostgres 20275 20272 0 17:08 ? 00:00:00 postgres: checkpointerpostgres 20276 20272 0 17:08 ? 00:00:00 postgres: background writerpostgres 20277 20272 0 17:08 ? 00:00:00 postgres: walwriterpostgres 20278 20272 0 17:08 ? 00:00:00 postgres: autovacuum launcherpostgres 20279 20272 0 17:08 ? 00:00:00 postgres: archiver failed on 000000010000000000000015postgres 20280 20272 0 17:08 ? 00:00:00 postgres: stats collectorpostgres 20281 20272 0 17:08 ? 00:00:00 postgres: logical replication launcherpostgres 20288 20272 0 17:08 ? 00:00:00 postgres: postgres postgres [local] idlepostgres 20359 19791 0 17:10 pts/2 00:00:00 ps -efpostgres 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 postgresroot 19555 13684 0 16:49 pts/1 00:00:00 su - postgrespostgres 19556 19555 0 16:49 pts/1 00:00:00 -bashpostgres 19767 19556 0 16:52 pts/1 00:00:00 psqlroot 19790 18013 0 16:53 pts/2 00:00:00 su - postgrespostgres 19791 19790 0 16:53 pts/2 00:00:00 -bashroot 19965 19924 0 16:56 pts/0 00:00:00 su - postgrespostgres 19966 19965 0 16:56 pts/0 00:00:00 -bashpostgres 20013 19966 0 16:56 pts/0 00:00:00 tail -100f postgresql-2023-03-13_072.logpostgres 20361 19791 0 17:11 pts/2 00:00:00 ps -efpostgres 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 startpg_ctl: another server might be running; trying to start server anywaywaiting for server to start....2023-03-13 17:13:06.788 CST [20419] PANIC: could not read file "global/pg_control": read 1 of 296stopped waitingpg_ctl: could not start serverExamine 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 -lrttotal 32768-rw-------. 1 postgres postgres 16777216 Mar 13 17:08 000000010000000000000015drwx------. 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 -lrttotal 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 -rlttotal 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 -rlttotal 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 $PGDATApg_resetwal: error: lock file "postmaster.pid" existspg_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 $PGDATApg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring itGuessed pg_control values:pg_control version number: 1300Catalog version number: 202107181Database system identifier: 7209963927373898017Latest checkpoint's TimeLineID: 1Latest checkpoint's full_page_writes: offLatest checkpoint's NextXID: 0:3Latest checkpoint's NextOID: 12000Latest checkpoint's NextMultiXactId: 1Latest checkpoint's NextMultiOffset: 0Latest checkpoint's oldestXID: 3Latest checkpoint's oldestXID's DB: 0Latest checkpoint's oldestActiveXID: 0Latest checkpoint's oldestMultiXid: 1Latest checkpoint's oldestMulti's DB: 0Latest checkpoint's oldestCommitTsXid:0Latest checkpoint's newestCommitTsXid:0Maximum data alignment: 8Database block size: 8192Blocks per segment of large relation: 131072WAL block size: 8192Bytes per WAL segment: 16777216Maximum length of identifiers: 64Maximum columns in an index: 32Maximum size of a TOAST chunk: 1996Size of a large-object chunk: 2048Date/time type storage: 64-bit integersFloat8 argument passing: by valueData page checksum version: 0Values to be changed:First log segment after reset: 000000010000000000000017NextMultiXactId: 65536OldestMultiXid: 65536OldestMulti's DB: 0NextMultiOffset: 52352NextXID: 1048576OldestXID: 3OldestXID's DB: 0If 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 -fpg_resetwal: warning: pg_control exists but is broken or wrong version; ignoring itWrite-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 startwaiting for server to start....2023-03-13 17:44:00.209 CST [20785] LOG: redirecting log output to logging collector process2023-03-13 17:44:00.209 CST [20785] HINT: Future log output will appear in directory "log".doneserver started[postgres@lyp global]$ psqlpsql (14.1)Type "help" for help.postgres=# select * from lxs1;id----12(2 rows)postgres=#
可以看到测试数据中 checkpoint
检查点后的数据,由于控制文件重置而丢失。
注意
1、注意据库正在运行时,不得使用此命令。
2、如果 pg_resetwal
在数据目录中找到服务器锁定文件,将启动失败。
3、如果数据库已崩溃,那么可能会留下一个锁文件(postmaster.pid
);在这种情况下,可以删除锁定文件以保证 postmaster.pid
的正常运行。但在此操作之前,需要再次确保没有数据库进程在运行。4、pg_resetwal
仅适用于相同主版本的数据库服务器。