我们遇到一种情况，即使用walmanager在主Postgres数据库和从属Postgres数据库之间发送wal文件。从机已经失败，必须重建。这导致很多未消耗的wal文件在master上构建。
如果向Postgres主人发出重新启动，并且有24小时的未消耗的wal文件，那么主人会受到影响还是会开始干净？
答案 0 :(得分：0)
如果WAL运输工作正常，那么主人将开始清理。
这听起来像传统的9.0之前的热备用WAL运输。回想一下它是如何工作的。在WAL达到某个（可配置的）大小阈值之前，主人会开展业务。当满足WAL大小阈值时，主控器开始WAL检查点。作为检查点的一部分，主服务器将所有WAL记录与检查点完全同步到持久存储。换句话说，保证WAL检查点之前的所有内容都保证在磁盘上。检查点提交后，可以安全地丢弃前面的WAL。
Postgres 在每个检查点之后丢弃或回收WAL文件。但是，在热备份时，它首先通过调用您配置的archive_command来发送一个检查点的WAL段。听起来你正在使用SkyTools的脚本作为archive_command。 archive_command将WAL段从主服务器的专用存储$PGDATA/data/pg_xlog复制到某个中立存储，然后从服务器可以使用它。你正在使用一些中性目录来存储WAL段，直到奴隶消耗它们，对吧？无论如何，一旦archive_command向主机返回零，主机就会假定WAL段已成功发货，并删除或重新使用$PGDATA/data/pg_xlog中留下的段文件。主人永远不会知道或关心那之后会发生什么。由archive_command生成的段副本可能是由奴隶使用的，也可能不是;主人没有参与。
换句话说，当WAL段发货时，主控制器结束。因此，主人不能干涉已发货但未消耗的WAL段。这包括重新启动主服务器。
但是：如果您的WAL运输中断，则所有投注均已关闭。请确保您的archive_command一直正常和，即未使用的WAL位于Postgres安装之外的中性目录中。前面的讨论还假设您正在进行推荐的热备份配置，如手册中的PG团队详细信息。
这也是我最喜欢检查备份的时间。给我温暖和模糊的看法，如果出现意外情况，我仍然可以恢复...