If the standby server cannot pull the WAL file from the master using streaming replication, then it will attempt to pull it from the archive. If the WAL segment isn't archived (for example because you aren't using archiving), then your streaming replication is unrecoverable and you have to take a fresh backup from the master and transfer it over to the standby machine to start replication again. So the value of having archiving setup is that in case a standby falls way behind, then the standby can recover without having to copy your database over to the standby machine again.
Another setting you can tweak is "wal_keep_segments" on the master machine, which is the minimum numbers of WAL segments it will keep without deleting. So just with some simple math: (wal_keep_segments * 16MB / your_wal_write_rate) you can determine a ballpark of how long your standby machines can fall behind while still being able to recover without archiving. -Dan On Tue, Feb 8, 2011 at 6:51 PM, Ogden <li...@darkstatic.com> wrote: > > On Feb 8, 2011, at 8:47 PM, Ray Stell wrote: > > > > > pg_controldata command is helpful. > > > > Archiving wal not required, but you can roll it either way. > > > > > > That is my confusion - Archiving wal does not conflict in any way with > streaming replication? What if streaming replication lags behind (especially > with a lot of connections). > > Thank you > > Ogden > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
