My understanding is this:
Once the standby stops (restarts, HUP, whatever), it needs to connect to the primary and get anything that didn't happen during the down time.
This is _always_ somewhere in a WAL, hence wal_keep_segments. If this is set sufficiently high, you don't _need_ WAL archiving. It will find the missing pieces from those, replay, and get back into streaming mode.
In the event that it's missing pieces it needs to replay, you'll need to reinitialize your standby from a base backup and start it back up.
Someone please correct me if I am wrong.
----- On Dec 17, 2014, at 9:40 AM, John Scalia <jayknowsunix@gmail.com> wrote:
Hi all,
I've got 3 PostgreSQL servers in a streaming standby configuration: 1 primary and 2 standby. These have been running great for a long time, and they are all running WAL archiving
as an insurance policy to the stream. My questions relate to when any standby is started up, I always see in the logs that it tries to read a couple of WAL segments that should be
present. What would happen if these weren't using WAL archiving - that is the primary wasn't sending them segments? How many segments is a standby usually looking for (I think I
always see two)? I've also seen that if one of these segments is broken or malformed, that the standby errors on start and often fails to start. Could I just remove the segment
causing the problem? After all with streaming working aren't WAL archives just superfluous?
--
Jay
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Journyx, Inc.
7600 Burnet Road #300
Austin, TX 78757
www.journyx.com
p 512.834.8888
f 512-834-8858
Do you receive our promotional emails? You can subscribe or unsubscribe to those emails here.