我过去曾成功使用过 MySQL 的延迟复制功能，该功能允许您停止复制，检查 bin 日志以查找错误查询，SLAVE UNTIL并在该查询之前跳过它。
自从 Postgresql 引入了该min_recovery_apply_delay设置后，我就希望在 Postgres 中实现同样的效果，但是，我不断阅读文章，这些文章都停留在停止复制的点上。现在您有 x 小时前的数据……您如何恢复运行？类似于我为 MySQL 编写将是理想的
编辑：经过大量搜索，我找到了 omnipitr 和 pghoard 工具以及恢复目标设置。特别是recovery_target_xid允许我恢复到精确查询的设置。现在唯一缺少的难题是，我不确定如何告诉 postgresql 跳过这个坏查询并在那之后继续恢复。
答案1
通过询问一些比我更有经验的 PostgreSQL 人员并进行进一步阅读，似乎您实际上无法像在 MySQL 中那样跳过查询。当您在恢复后恢复时，会创建一个新的“时间线”，就像“回到未来”一样。
也许 PostgresSQL 将来会找到一种安全的方法来实现这一点，但是现在看来，您只能恢复到某个时间点，但如果不进行大量的手动工作，在此之后写入的所有数据都将丢失。
答案2
我可能是错的，但对于 postgresql 流复制，你必须在主服务器上设置存档（参见文档https://www.postgresql.org/docs/current/static/continuous-archiving.html)。Master 将旧的 XLOGS（WAL 日志）保存在给定目录中（您需要稍后定期删除它们，因为 master 目前还不会自动执行此操作）。这些存档的 xlog 是必需的，否则 postgresql 复制现在将在一些较长的网络问题等情况下存活下来。所以这就是您的意思吗？
这与 MySQL 类似，如果副本在停机或无法访问一段时间后启动，并且主服务器上不再存在二进制日志，则必须重新创建副本。否则，如果二进制日志仍然可用，副本将自动同步（除非从服务器已停止或在配置文件中强制不启动）。