Postgresql WAL archive_command文件比较

我已阅读“Hans-Jurgen Schonig的PostgreSQL复制”，以及一些最佳实践，不要在执行archive_command期间覆盖归档WAL文件 - 任何人都可以展开这是为什么？并且如果以下方案对WAL覆盖有效？Postgresql WAL archive_command文件比较

我写了一个脚本，将执行以下高层次的逻辑为个人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字节匹配-wise
复制过程将再次发生，希望结束写损坏的文件
EXIT_STATUS 0中的文件的成功比较的情况下，否则这个过程会被重复

有参与的比较（我可以更新到MD5校验一个非常小的开销），任何人都可以看到这种方法可能产生的问题吗？或者推荐什么？

谢谢

来源

2017-10-19 abstractx1

如果我正确地读出你的伪代码，你会在存档覆盖WAL段，如果它们不相同，以你目前的WAL-待归档。

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

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

来源

2017-10-19 12:36:49

啊当然，辉煌的谢谢你。在我的情况下，这是本地存储到单个postgresql服务器。 – abstractx1

Postgresql WAL archive_command文件比较

回答

相关问题