On Thu, Aug 18, 2011 at 4:26 AM, Lonni J Friedman <netllama@gmail.com> wrote:
> I wish I knew. All the documentation out there always focuses on
> setting up a restore command, as if there would be a huge disaster if
> it wasn't done. Is it safe to simply make wal_keep_segments really
> large, and skip the restore_command altogether?
There are pros and cons of replication setting NOT using restore_command.
Please evaluate whether it's safe or not according to them.
Pros;
* You don't need to prepare the archive area shared between the master
and standby. Don't need to purchase new server for that.
* If you use restore_command and have the shared archive area,
archive_command is a bit more likely to fail because it copies WAL files
via network. Failure of archive_command might fill up the pg_xlog
directory on the master, which might cause PANIC error. So you need
to consider how to handle this failure case. OTOH, you don't need to
do that if you don't use restore_command.
Cons;
* When setting up the standby, if the backup takes very long because
the database is quite large, some WAL files required to the backup
might be deleted from the master during the backup. If this happens,
the standby starting from that backup will fail to start replication.
To avoid such an unexpected deletion of WAL files from the master,
you need to increase wal_keep_segments enough. But it might not
be easy to determine the appropriate value of it.
* You need to prepare large disk space for pg_xlog directory
if wal_keep_segments is large. Because, in that case, a large number
of WAL files can accumulate in pg_xlog.
* When replication connection is terminated, no WAL data is streamed
to the standby, so the standby cannot advance recovery at all. OTOH,
if you set restore_command on the standby and have the shared
archive area, the standby can read new WAL file from it by using
restore_command and advance recovery.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center