日志传送过程（archive_timeout）答案

【问题标题】：log shipping process (archive_timeout)日志传送过程（archive_timeout）
【发布时间】：2014-11-17 00:39:12
【问题描述】：

我是 postgresql 的新手。我想问一下日志传送复制过程。我知道超时参数在日志传送过程中是可选的。它指定我们不希望 postgreSQL 等到 WAL 文件包含 16 MB 才能发送，因为它默认情况下会发送。我的问题是，最好有超时参数（例如：archive_timeout = 60）还是没有？是不是当我们做超时参数时，WAL 文件在日志传送中的处理速度比默认值快（默认值 0 表示它会一直到 WAL 填满）？为什么？

对不起，我仍然对这种情况感到困惑。

【问题讨论】：

标签： postgresql log-shipping

【解决方案1】：

如果您想要及时复制，我建议启用流式复制以及日志传送。

archive_timeout 的主要目的是确保当您使用日志传送进行 PITR 备份时，在服务器未生成大量 WAL 的情况下，数据丢失的最大时间窗口因此段轮换会否则不常见。

【讨论】：

感谢您的回复..对不起，我不清楚，“服务器没有生成大量 WAL，因此段轮换将不频繁”是什么意思？你能解释一下吗？还有一件事我也做流式复制并且它是工作的，但是当我做日志传送时它不起作用，因为在从属服务器上数据库系统正在启动。我在themagicnumber.es/replication-in-postgresql-i?lang=en上引用了这个步骤。我使用 postgresql 9.3 版。我希望你能帮助我。
@Najwa 好吧，假设您每分钟都在做一个小的 INSERT。每次写入可能会产生不到 1 kb 的 WAL，因此对于 16MB 段，在将 WAL 段发送到存档之前需要大约 4 个半小时 justify_interval(INTERVAL '16384' SECOND) =。您可能希望它发送得比这快得多，这样您就可以保证，例如，您在崩溃中最多丢失 10 分钟的数据。这就是archive_timeout 的用途。
就是说，一个WAL文件段发送到存档的时间越长，崩溃的概率越大？
@Najwa 导致主数据库完全丢失的崩溃/火灾/任何原因（因此您所拥有的只是存档的 WAL 和基本备份），是的。当然，简单的意外重启、postgres 服务器强制重启等都没关系，因为 Pg 是崩溃安全的。但是再次...... 使用流复制，你通常没问题。此选项的存在主要是为了确保数据在限定时间内可用于 PITR。
archive_timeout 值的更改是否需要 postgres 重新加载/重新启动？