From: | John DeSoi <desoi(at)pgedit(dot)com> |
---|---|
To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-general(at)postgresql(dot)org general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: streaming replication not working |
Date: | 2013-09-25 17:10:38 |
Message-ID: | 7C741B47-D496-4CA6-9440-94E512BDBFA4@pgedit.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sep 25, 2013, at 8:36 AM, Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
> Your config file and your debug logs don't match. Your config file says
> that the restore command is rsync, but your logs say its pg_standby.
>
> Check if you have a pg_standby process on the slave. That would explain
> why the slave never tries to establish a replication connection to the
> master.
rsync is only used in the primary configuration to push the WAL files to the standby. But pg_standby is indeed the problem. I thought pg_standby was a more feature rich option than using cp for the restore command. I see now the documentation says it supports creation of a "warm standby". It did not occur to me this meant the standby could not connect to the primary for streaming replication. Even when using pg_standby, the server was really a "hot standby" because I was able to connect to it and make read-only queries. I think it would be helpful for pg_standby to emit a warning if primary_conninfo is set it the recovery.conf.
I changed the restore command to use cp and now everything appears to be working as expected.
Thanks very much for your help and to everyone who offered suggestions.
John DeSoi, Ph.D.
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Schlansker | 2013-09-25 17:50:35 | Re: Deduplication and transaction isolation level |
Previous Message | Stuart Bishop | 2013-09-25 16:01:14 | Re: Incorrect password when restarting a cluster |