如何防止硬关机后启动时pg wals删除?

# select version();
> PostgreSQL 11.4 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 8.3.0-3ubuntu1) 8.3.0, 64-bit

我的电脑坏了 archive_command 了一段时间。Pg保留了WALs,直到它们没有像预期的那样被存档。然后,我杀了pg进程,并启动它。我注意到,所有的WALs,这是准备被归档,被删除。在google bucket中也没有WALs。

pg日志后重新启动。

2020-04-22 14:27:23.702 UTC [7] LOG:  database system was interrupted; last known up at 2020-04-22 14:27:08 UTC
2020-04-22 14:27:24.819 UTC [7] LOG:  database system was not properly shut down; automatic recovery in progress
2020-04-22 14:27:24.848 UTC [7] LOG:  redo starts at 4D/BCEF6BA8
2020-04-22 14:27:24.848 UTC [7] LOG:  invalid record length at 4D/BCEFF0C0: wanted 24, got 0
2020-04-22 14:27:24.848 UTC [7] LOG:  redo done at 4D/BCEFF050
2020-04-22 14:27:25.286 UTC [1] LOG:  database system is ready to accept connections

我重复了这个场景与conf param log_min_messages=DEBUG5 我看到pg删除了旧的WALs,无视它们被等待存档的事实。

2020-04-23 14:55:42.819 UTC [6] LOG:  redo starts at 0/22000098
2020-04-23 14:55:50.138 UTC [6] LOG:  redo done at 0/22193FB0
2020-04-23 14:55:50.138 UTC [6] DEBUG:  resetting unlogged relations: cleanup 0 init 1
2020-04-23 14:55:50.266 UTC [6] DEBUG:  performing replication slot checkpoint
2020-04-23 14:55:50.336 UTC [6] DEBUG:  attempting to remove WAL segments older than log file 000000000000000000000021
2020-04-23 14:55:50.349 UTC [6] DEBUG:  recycled write-ahead log file "000000010000000000000015"
2020-04-23 14:55:50.365 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000012"
2020-04-23 14:55:50.372 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000001B"
2020-04-23 14:55:50.382 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000001E"
2020-04-23 14:55:50.390 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000013"
2020-04-23 14:55:50.402 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000014"
2020-04-23 14:55:50.412 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000001D"
2020-04-23 14:55:50.424 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000001C"
2020-04-23 14:55:50.433 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000000F"
2020-04-23 14:55:50.442 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000001F"
2020-04-23 14:55:50.455 UTC [6] DEBUG:  removing write-ahead log file "00000001000000000000001A"
2020-04-23 14:55:50.471 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000020"
2020-04-23 14:55:50.480 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000018"
2020-04-23 14:55:50.489 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000011"
2020-04-23 14:55:50.502 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000016"
2020-04-23 14:55:50.518 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000017"
2020-04-23 14:55:50.529 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000010"
2020-04-23 14:55:50.536 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000019"
2020-04-23 14:55:50.547 UTC [6] DEBUG:  removing write-ahead log file "000000010000000000000021"
2020-04-23 14:55:50.559 UTC [6] DEBUG:  MultiXactId wrap limit is 2147483648, limited by database with OID 1
2020-04-23 14:55:50.559 UTC [6] DEBUG:  MultiXact member stop limit is now 4294914944 based on MultiXact 1
2020-04-23 14:55:50.566 UTC [6] DEBUG:  shmem_exit(0): 1 before_shmem_exit callbacks to make
2020-04-23 14:55:50.566 UTC [6] DEBUG:  shmem_exit(0): 4 on_shmem_exit callbacks to make
2020-04-23 14:55:50.566 UTC [6] DEBUG:  proc_exit(0): 2 callbacks to make
2020-04-23 14:55:50.566 UTC [6] DEBUG:  exit(0)
2020-04-23 14:55:50.566 UTC [6] DEBUG:  shmem_exit(-1): 0 before_shmem_exit callbacks to make
2020-04-23 14:55:50.566 UTC [6] DEBUG:  shmem_exit(-1): 0 on_shmem_exit callbacks to make
2020-04-23 14:55:50.566 UTC [6] DEBUG:  proc_exit(-1): 0 callbacks to make
2020-04-23 14:55:50.571 UTC [1] DEBUG:  reaping dead processes
2020-04-23 14:55:50.572 UTC [10] DEBUG:  autovacuum launcher started
2020-04-23 14:55:50.572 UTC [1] DEBUG:  starting background worker process "logical replication launcher"
2020-04-23 14:55:50.572 UTC [10] DEBUG:  InitPostgres
2020-04-23 14:55:50.572 UTC [10] DEBUG:  my backend ID is 1

有什么方法可以防止pg删除未归档的WALs?

解决方案:

它看起来像,这是。”[BUG]非归档WAL在生产崩溃恢复过程中被删除”,发现最后几周。https:/www.postgresql.orgmessage-id20200331172229.40ee00dc%40firost

根据PG邮件列表的讨论,目前正在开发一个补丁,但还没有推出。最早可能在5月推出。

给TA打赏
共{{data.count}}人
人已打赏
未分类

Javascript。如何从utf-8编码到iso-8859-1,并从中进行解码?

2022-9-8 22:00:40

未分类

如何在 react native 中从普通函数中获取上下文值?(没有使用Context或类组件)

2022-9-8 22:11:26

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索