为什么显示 WAL 重放的 repmgr 在所有备用节点上暂停？
在 repmgr cluster show 命令中显示以下错误。为什么它显示 WAL 重播在节点 2 和节点 2 上暂停node3 作为警告。这里node2和node3是我的备用节点。这里我附上了node1和node2的postgresql.auto.conf。使用 Barman 进行 PITR 后我发现了这个问题。为什么会发生这种情况以及如何解决？
At repmgr cluster show command showing below error. Why it show WAL replay is paused on node2 & node3 as a warning. Here node2 and node3 is my standby node. Here I attached postgresql.auto.conf for node1 and node2. After PITR using Barman I found this issue. Why this is happen and how to solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从 v12 开始，默认的 recovery_target_action 已经是“pause”。这使您可以在只读模式下探索系统，以确保在完全打开数据库之前处于最佳时间点。
由于您没有覆盖它（例如，通过使用酒保的
--target-action），因此您会得到“暂停”。您可以通过编辑conf 文件添加recovery_target_action 来修复此问题（无需重做整个恢复），或者仅连接到每个文件并调用pg_wal_replay_resume()。
Since v12, the default recovery_target_action has been "pause". This lets you explore the system in read-only mode to make sure you are at the optimal point in time, before you fully open the database.
Since you didn't override that (by using barman's
--target-action, for example), then "pause" is what you get.You could fix this (without redoing the whole restore) by editing your conf files to add a recovery_target_action, or by just connecting to each one and invoking pg_wal_replay_resume().
我在同样的问题上挣扎了近3-4天，最后发现postgresql.auto.conf是一个待命问题。
请删除或注释 postgresql.auto.conf 中的行 #restore_command = 'cp barman_wal/%f %p' #recovery_end_command = 'rm -fr barman_wal' #recovery_target_time = '2022-11-06 10:00:00'在使用 repmgr 克隆后，我重新启动了备用数据库，一切都开始工作。
希望这有帮助
I struggled with the same issue for almost 3-4 days and finally found that postgresql.auto.conf is an issue on standby.
Please remove or comment lines in postgresql.auto.conf #restore_command = 'cp barman_wal/%f %p' #recovery_end_command = 'rm -fr barman_wal' #recovery_target_time = '2022-11-06 10:00:00'I restarted my standby after cloning using repmgr and everything started to work.
Hope this helps
PostgreSQL 无法复制应用于 SQL 的 DDL 部分的事务，并且当在复制的源数据库上执行此类命令时，流式复制会立即停止。
通过这种方式调查以查找在源数据库上执行了哪个 DDL 命令（CREATE、ALTER、DROP...）...
PostgreSQL is unnable to replicate transaction that apply to the DDL part of SQL and when such a command is executed on the source database of the replication the streaming replication immediately stops.
Investigate that way to find which DDL command (CREATE, ALTER, DROP...) has benn executed on the source database...