Replication: slave is in permanent startup 'recovery'

From: "Henry C(dot)" <henka(at)cityweb(dot)co(dot)za>
To: pgsql-general(at)postgresql(dot)org
Subject: Replication: slave is in permanent startup 'recovery'
Date: 2011-04-13 18:15:54
Message-ID: d3f42cf4a8ee090431ec3a6be778f9c0.squirrel@zenmail.co.za
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message AShved 2011-04-13 18:23:09 Re: Streaming Replication limitations
Previous Message Tom Lane 2011-04-13 18:15:30 Re: 9.0 Out of memory