有人可以向我解释时间轴和历史文件的目的以及recovery.conf中的“recovery_target_timeline”设置。
我从postgresql 9.1文档中得到的模糊理解是，当slave完成恢复时，它会切换到新的时间轴，以防止覆盖之前时间轴的WAL。我不清楚如何在恢复方案中使用它以及.history文件的目的和'recovery_target_timeline'设置为'latest'。
我试图了解当我推动奴隶成为新主人时会发生什么。它在接受读/写查询之前恢复并启动新的时间线。
现在，如果我将现有从站提升为主站，则设置新的从站，是否需要/使用前一个从站（新主站）生成的历史文件来读取由新主站生成的新WAL（用于连续）存档/日志传送。
非常感谢。
答案 0 :(得分：0)
要了解时间表，您必须了解的是，他们要避免出现MVCC问题和时间轴分歧。考虑这一点的好方法是在复制的背景下。在主/从流复制中，您不希望有人将主服务器作为主服务器插入一堆信息，然后将其重新转换为从服务器。如果这样做，WAL段的二进制日志将无法再正常运行，您将获得数据库损坏。
当您将奴隶恢复到新的主人时，它会完成“恢复”并开始自己的时间线。从现在开始，它现在是主人，如果没有重建就不能再回到奴隶身边了。这会给故障转移和故障恢复带来一些问题，但执行此操作的方法是定期使用旧主服务器重建db（使用pg_basebackup）作为新从服务器来回执行故障。这意味着每个故障转移/故障回复都是新的时间轴。
是的，这确实会影响多台服务器的故障，因为从站必须更改时间轴。