☰

找不到“时间线历史文件”以使复制工作正常

tag-icon • tag-icon postgresql replication
找不到“时间线历史文件”以使复制工作正常

我正在运行 PostgreSQL 9.4，尝试进行复制。

我正在做的，从中汲取灵感维基百科上的说明和文档：

  1. SELECT pg_start_backup('clone', true);
  2. rsync数据库到潜在副本
  3. SELECT pg_stop_backup();
  4. rsync文件pg_xlog夹到可能的副本

我启动副本，它显示：

LOG:  fetching timeline history file for timeline 3 from primary server
FATAL:  could not receive timeline history file from the primary server:
    ERROR:  could not open file "pg_xlog/00000003.history": No such file or directory

当然，我在两台服务器上寻找该.history文件pg_xlog/，但没有找到。

我浏览了文档，发现

要使用备份，您需要保留文件系统备份期间和之后生成的所有 WAL 段文件。为了帮助您执行此操作，pg_stop_backup 函数会创建一个备份历史文件，该文件会立即存储到 WAL 存档区域中。此文件以文件系统备份所需的第一个 WAL 段文件命名。例如，如果起始 WAL 文件是 0000000100001234000055CD，则备份历史文件将命名为 0000000100001234000055CD.007C9330.backup。

然而碰巧的是，我这样做之后，pg_stop_backup()仍然没有出现这种情况pg_xlog/，也没有任何地方出现这种情况。

那么我从哪里可以得到这个“时间线历史文件”？

答案1

根据六合二发布后，您可能只需要创建一个文件，然后它将继续进行复制设置，但本质上它是一个 PostgresSQL 错误，即使它不适用或根据操作已被删除，它仍然需要这个文件。

笔记： 对于 Postgresql 10 及更高版本，该函数已重命名为pg_current_wal_lsn()

当 PostgreSQL 提升新的主服务器时，它会以放置在 WAL 文件目录中的小文本文件的形式创建时间线分割的标记。此文件使得在某些相当复杂的故障转移和故障恢复场景下实现时间点恢复成为可能。

因此，您似乎必须重新创建该文件。您可以找到 非常好的总结 Postgres wiki 上的 .history 文件。由于信息是 .pdf 格式，因此索引起来比较困难，因此如果您不知道它在那里，您可能会很难找到文档。

但我们永远不会回到那个时间线，因为它在我们升级之前。我们只需要一个足够好的数字就可以重新创建丢失的文件。您可以通过运行以下命令获取一个：

# SELECT pg_current_xlog_location();
 pg_current_xlog_location
--------------------------
 1/38F70328
(1 row)

使用这些值在 WAL 目录中模拟一个 .history 文件，然后就大功告成了。副本将立即能够启动。

来源

使用这些（以上）结果创建文件，但使用根据错误预期的名称。

更多资源

  • 了解 PostgreSQL 时间线

  • 系统管理功能

    姓名： pg_current_xlog_location()

    退货类型： 文本

    描述： 获取当前事务日志写入位置

    pg_current_xlog_location以上述函数使用的相同格式显示当前事务日志写入位置。类似地，pg_current_xlog_insert_location 显示当前事务日志插入点。插入点是任何时刻事务日志的“逻辑”结尾，而写入位置是实际从服务器内部缓冲区写出的内容的结尾。写入位置是可以从服务器外部检查的内容的结尾，如果您有兴趣归档部分完成的事务日志文件，这通常是您想要的。插入点主要用于服务器调试目的。这些都是只读操作，不需要超级用户权限。

    您可以使用pg_xlogfile_name_offset从上述任何函数的结果中提取相应的事务日志文件名和字节偏移量。

    类似地，pg_xlogfile_name仅提取事务日志文件名。当给定的事务日志位置恰好位于事务日志文件边界时，这两个函数都会返回前一个事务日志文件的名称。这通常是管理事务日志归档行为所需的行为，因为前一个文件是当前需要归档的最后一个文件。

    来源

相关内容