Question

我已经阅读过＆＃34; Hans-Jurgen Schonig＆＃34;的PostgreSQL复制，以及最好的做法是在执行archive_command期间不覆盖存档WAL文件的几个地方 - 任何人都可以请继续扩展原因是什么？如果以下场景对WAL覆盖有效？

我编写了一个脚本，它将为单个WAL归档过程执行以下高级逻辑：

if (/archive/00000001000000F700000067 exists and is readable) and (00000001000000F700000067 is byte by byte equal to /archive/00000001000000F700000067)
  exit with status 0
else
  if (copy 00000001000000F700000067 to /archive/00000001000000F700000067 is successful)
    if (/archive/00000001000000F700000067 exists and is readable) and (00000001000000F700000067 is byte by byte equal to /archive/00000001000000F700000067)
      exit with status 0
    else
      exit with status non-zero
  else
    exit with status non-zero

简而言之，这种方法希望至少防止原始WAL文件被错误存档的情况 - 副本具有有效的文件名但是已损坏（例如由于硬件故障）。我在这个例子中对WAL存档过程的理解：

archive_command将在复制过程之后的逐字节比较期间返回非零退出状态（让我们假设复制过程有错误的成功响应）
根据文档，在非零exit_status时，将无限期地重新尝试WAL归档 - 应该进行第二次WAL归档尝试
archive_command将识别现有存档WAL与当前WAL字节不匹配
复制过程将再次发生，希望覆盖损坏的文件
exit_status 0，如果文件成功比较，否则此过程将重复

比较涉及一个非常小的开销（我可能会更新到md5检查），任何人都可以看到这种方法可能产生的任何问题吗？或推荐更进一步的东西？

谢谢

Answer 1

如果我正确读取了伪代码，如果它们与您当前的待归档WAL不相同，您将覆盖归档中的WAL段。

问题在于，WAL档案是非常重要的信息，你正在为以前有人写过的存档的WAL段写字。如果错误配置两个PostgreSQL集群错误地写入同一个归档目录，那么WAL归档将被破坏。

最好在这种情况下停止存档并提醒管理员。

Postgresql WAL archive_command文件比较

1 个答案: