On Wed, April 14, 2010 08:23, Heikki Linnakangas wrote:
> Erik Rijkers wrote:
>> This replication test that was working well earlier (it ran daily), stopped working
>
> This is probably because of this change:
>
>> date: 2010/04/12 09:52:29; author: heikki; state: Exp; lines: +71 -23
>> Change the logic to decide when to delete old WAL segments, so that it
>> doesn't take into account how far the WAL senders are. This way a hung
>> WAL sender doesn't prevent old WAL segments from being recycled/removed
>> in the primary, ultimately causing the disk to fill up. Instead add
>> standby_keep_segments setting to control how many old WAL segments are
>> kept in the primary. This also makes it more reliable to use streaming
>> replication without WAL archiving, assuming that you set
>> standby_keep_segments high enough.
>
> If you generate enough WAL records in the master that the standby can't
> keep up, the primary will eventually delete a WAL segment that hasn't
> been streamed to the standby yet, hence the "requested WAL segment
> 000000010000000000000032 has already been removed" error.
ah, I hadn't seen that change, and setting standby_keep_segments
to some higher value (I chose 10000 for now) prevents these errors.
>It shouldn't
> remove the segment before it's successfully archived, though, and your
> logs show that the standby can't find that file in the archive either.
> Is archiving set up properly?
It wasn't really - I was archiving on the primary server, instead of copying
to the standby server. I'll fix that, thanks.
Btw, typo alert: documentation 18.5.4, subhead 'standby_keep_segments',
says: 'replciation' for 'replication'.
http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html#RUNTIME-CONFIG-REPLICATION
thanks,
Erik Rijkers
