【问题标题】:timelines and history files postgresql 9.1时间线和历史文件 postgresql 9.1
【发布时间】:2012-06-20 22:44:16
【问题描述】:

谁能解释一下时间线和历史文件的用途以及 recovery.conf 中的“recovery_target_timeline”设置。

我从 postgresql 9.1 文档中得到的模糊理解是,当从属设备完成恢复时,它会切换到新的时间线以防止覆盖先前时间线的 WAL。我不清楚这是如何在恢复场景中使用的,以及 .history 文件的用途以及将“recovery_target_timeline”设置为“最新”。

我试图了解当我将奴隶提升为新主人时会发生什么。它在接受读/写查询之前恢复并启动新的时间线。

现在如果我设置一个新的从站,因为我将现有的从站提升为主站,它是否需要/使用前一个从站(新主站)生成的历史文件来读取(由新主站)生成的新 WAL 以保持连续归档/日志传送。

非常感谢。

【问题讨论】:

  • recovery_target_timeline 用于指定一个时间线,以防您在之前已经执行过时间点恢复之后进行恢复,这会产生不同的时间线。见postgresql.org/docs/9.1/static/…

标签: postgresql postgresql-9.1


【解决方案1】:

要了解时间线,您必须了解的是,它们是为了避免 MVCC 和不同时间线的问题。考虑这一点的一个好方法是在复制的上下文中。在主/从流复制中,您不希望有人将从属作为主插入一堆信息,然后将其转回从属。如果这样做,WAL 段的二进制日志将无法再正常运行,您将获得 db 损坏。

当您将奴隶恢复到新的主人时,它会完成“恢复”并开始自己的时间线。从这一点开始,它现在是主人,如果没有重建,就不能再成为奴隶。这给故障转移和故障恢复带来了一些问题,但这样做的方法是定期来回故障,旧主服务器重建数据库(使用pg_basebackup)作为新的从服务器。这意味着每次故障转移/故障回复都是一个新的时间线。

是的,这确实会影响多台服务器的故障转移,因为从属服务器必须更改时间线。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-04-25
    • 2012-08-26
    • 1970-01-01
    • 1970-01-01
    • 2018-11-25
    • 2023-02-01
    • 1970-01-01
    • 2017-12-25
    相关资源
    最近更新 更多