Replication: slave is in permanent startup 'recovery' - Mailing list pgsql-general

From Henry C.
Subject Replication: slave is in permanent startup 'recovery'
Date
Msg-id d3f42cf4a8ee090431ec3a6be778f9c0.squirrel@zenmail.co.za
Whole thread Raw
Responses Re: Replication: slave is in permanent startup 'recovery'
Re: Replication: slave is in permanent startup 'recovery'
Re: Replication: slave is in permanent startup 'recovery'
List pgsql-general
Greets,

Pg 9.0.3

This must be due to my own misconfiguration, so apologies if I'm not seeing
the obvious - I've noticed that my slave seems to be stuck in a permanent
startup/recovery state.  ps on the slave shows:

...
postgres: wal receiver process   streaming 190/A6C384A0
postgres: startup process   recovering 0000000100000190000000A6 (1)
...

(1) keeps incrementing to reflect each new log file in pg_xlog on the master
(even after the slave caught up with all the other log files after the initial
rsync).

If I try and execute a long-lived SQL query on the slave, it eventually fails
with "canceling statement due to conflict with recovery".  Replication is
definitely working (DML actions are propagated to the slave), but something is
amiss.

I'm trying Streaming replication.  Once I get this working reliably, the idea
is to use it on a rather busy server where the log files are used in case the
slave(s) fall behind the stream during peak periods.  (sorry if I'm using the
wrong idioms, or not quite understanding Pg's built in replication methods -
I'm used to Skype's Londiste)

MASTER CONFIG
wal_level = hot_standby
archive_mode = on
archive_command = 'cp -a "%p" /home/psql-wal-archive/"%f"'
max_wal_senders = 5
wal_keep_segments = 8

SLAVE CONFIG
wal_level = hot_standby
wal_keep_segments = 64
hot_standby = on


Any ideas what I'm doing wrong here?

Thanks


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.0 Out of memory
Next
From: AShved@symcor.com
Date:
Subject: Re: [ADMIN] Streaming Replication limitations