【问题标题】:Streaming replication is failing with "WAL segment has already been moved"流式复制因“WAL 段已被移动”而失败
【发布时间】:2019-11-08 17:59:15
【问题描述】:

我正在尝试在Postgres 11.5 上实现主/从流复制。我运行了以下步骤 -

在主上

select pg_start_backup('replication-setup',true);

在奴隶 停止 postgres 11 数据库并运行

rsync -aHAXxv --numeric-ids --progress -e "ssh -T -o Compression=no -x" --exclude pg_wal --exclude postgresql.pid --exclude pg_log MASTER:/var/lib/postgresql/11/main/* /var/lib/postgresql/11/main

主控

select pg_stop_backup();

在奴隶上

rsync -aHAXxv --numeric-ids --progress -e "ssh -T -o Compression=no -x"  MASTER:/var/lib/postgresql/11/main/pg_wal/* /var/lib/postgresql/11/main/pg_wal

我在 slave ~/11/main 文件夹上创建了 recovery.conf 文件

standby_mode = 'on'
primary_conninfo = 'user=postgres host=MASTER port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'
primary_slot_name='my_repl_slot'

当我在 Slave 上启动 Postgres 时,我在 MASTER 和 SLAVE 日志上都收到错误 -

019-11-08 09:03:51.205 CST [27633] LOG:  00000: database system was interrupted; last known up at 2019-11-08 02:53:04 CST
2019-11-08 09:03:51.205 CST [27633] LOCATION:  StartupXLOG, xlog.c:6388
2019-11-08 09:03:51.252 CST [27633] LOG:  00000: entering standby mode
2019-11-08 09:03:51.252 CST [27633] LOCATION:  StartupXLOG, xlog.c:6443
2019-11-08 09:03:51.384 CST [27634] LOG:  00000: started streaming WAL from primary at 12DB/C000000 on timeline 1
2019-11-08 09:03:51.384 CST [27634] LOCATION:  WalReceiverMain, walreceiver.c:383
2019-11-08 09:03:51.384 CST [27634] FATAL:  XX000: could not receive data from WAL stream: ERROR:  requested WAL segment 00000001000012DB0000000C has already been removed
2019-11-08 09:03:51.384 CST [27634] LOCATION:  libpqrcv_receive, libpqwalreceiver.c:772
2019-11-08 09:03:51.408 CST [27635] LOG:  00000: started streaming WAL from primary at 12DB/C000000 on timeline 1
2019-11-08 09:03:51.408 CST [27635] LOCATION:  WalReceiverMain, walreceiver.c:383

问题是 START WAL - 00000001000012DB0000000C 在我运行 pg_stop_backup() 之前一直可用,并且在执行 pg_stop_backup() 后被归档并且不再可用。因此,这不是由于WAL_KEEP_SEGMENTS 低而导致 WAL 被归档的问题。

postgres@SLAVE:~/11/main/pg_wal$ cat 00000001000012DB0000000C.00000718.backup
START WAL LOCATION: 12DB/C000718 (file 00000001000012DB0000000C)
STOP WAL LOCATION: 12DB/F4C30720 (file 00000001000012DB000000F4)
CHECKPOINT LOCATION: 12DB/C000750
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2019-11-07 15:47:26 CST
LABEL: replication-setup-mdurbha
START TIMELINE: 1
STOP TIME: 2019-11-08 08:48:35 CST
STOP TIMELINE: 1

我的 MASTER 设置了 archive_command,并且我有缺少的 WAL 可用。我将它们复制到 SLAVE 上的还原目录并尝试了下面的 recovery.conf,但仍然失败,MASTER 报告相同的 WAL segment has already been moved 错误。
知道如何解决这个问题吗?我过去在 Postgres 9.6 上使用 rsync 设置复制没有任何问题,但在 Postgres 11 上遇到了这个问题。

standby_mode = 'on'
primary_conninfo = 'user=postgres host=MASTER port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'
restore_command='cp /var/lib/postgresql/restore/%f %p'

【问题讨论】:

  • 您确定恢复失败了吗?它可能会要求文件,被告知它不存在并报告错误,然后继续处理它已有的文件。
  • 它失败了,因为它在同一个 WAL 上不断重复同样的错误,并且没有达到一致的状态。 psql 连接也失败了。
  • 您在问题中粘贴了recovery.conf 的两个内容——它们是否相关?一个有restore_command,另一个没有
  • 我会编辑 restore_command 以放置类似“echo trying to copy %f %p;”的内容在真正的 cp 命令之前,确保该命令的输出实际上被捕获在您的日志中和/或它正在运行。此外,如果您暂时注释掉 primary_conninfo,可能会使您的日志更清晰、更易于理解。
  • 修改recovery.conf添加restore_command后是否重启了replica?

标签: postgresql replication


【解决方案1】:

restore_command 放入recovery.conf 可以恢复归档的WAL 文件,就可以了。

【讨论】:

  • 所以你是说 - 在 recovery.conf? 中包含 restore_commandprimary_slot_name。知道为什么领先的 WAL 会被pg_stop_backup() 归档和删除吗?非常感谢。
  • 是的,我就是这个意思。你也有primary_conninfo,对吧?当前的 WAL 段由pg_stop_backup 存档,因为没有它,备份是不完整的。它是恢复所必需的。
  • 非常感谢。下次遇到这个问题我会试试的。我已经发布了关于如何修复它的解决方案。
  • 在从属服务器上启动 postgres 并启动恢复后,我通过在主服务器上运行 pg_stop_backup() 解决了这个问题。这样,在恢复开始之前不会归档领先的 WAL。不确定这是否是一个好方法......但它解决了我的问题。
  • 这似乎不正确。不正确的设置可能会损坏备用服务器。你要么听从我的建议,要么在主节点上增加wal_keep_segments
猜你喜欢
  • 2018-05-18
  • 2013-02-03
  • 2022-01-18
  • 2016-01-01
  • 2017-05-08
  • 1970-01-01
  • 2016-06-13
  • 2018-08-14
  • 1970-01-01
相关资源
最近更新 更多