Thread: Streaming replication - slave not getting promoted
Hi,
I have streaming replication set up, with PostgreSQL 9.3. The entries in recovery.conf on the slave are as follows - standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=2345 user=postgres password=password'
restore_command = 'cp /pgdata/archive/%f "%p"'
trigger_file = ‘/tmp/down.trg’
hot_standby = on
FATAL: could not connect to the primary server: could not connect to server: Connection refused
One more doubt -
"
# Note that recovery.conf must be in $PGDATA directory.
# It should NOT be located in the same directory as postgresql.conf
"
On 01/04/2015 06:09 AM, Jayadevan M wrote: > Hi, > I have streaming replication set up, with PostgreSQL 9.3. The entries in > recovery.conf on the slave are as follows - > standby_mode = 'on' > primary_conninfo = 'host=127.0.0.1 port=2345 user=postgres > password=password' > restore_command = 'cp /pgdata/archive/%f "%p"' > trigger_file = ‘/tmp/down.trg’ > > In postgresql.conf on the slave, I have set > hot_standby = on > > Replication is working fine. The trigger file does get created by the > failover script when I shut down the primary. But I just keep getting > these entries in the log file in the slave and it does not get promoted. > FATAL: could not connect to the primary server: could not connect to > server: Connection refused > > Any suggestions? Try pg_ctl promote on the standby server to see if it works at all: http://www.postgresql.org/docs/9.3/interactive/app-pg-ctl.html If it does then maybe your standby cannot 'see' the trigger file. > > One more doubt - > > In https://wiki.postgresql.org/wiki/Streaming_Replication, it says > " > # Note that recovery.conf must be in $PGDATA directory. > # It should NOT be located in the same directory as postgresql.conf > " > postgresql.conf is in $PGDATA. So they will be in the same directory? > > Regards, > Jayadevan > -- Adrian Klaver adrian.klaver@aklaver.com
Jayadevan M <maymala.jayadevan@gmail.com> wrote: > > Replication is working fine. The trigger file does get created by the failover > script when I shut down the primary. But I just keep getting these entries in > the log file in the slave and it does not get promoted. > FATAL: could not connect to the primary server: could not connect to server: > Connection refused > > Any suggestions? I think your replication based only on the wal-files but no streaming replication, do you have a entry in the pg_hba.conf on the master for the client? Something like #local replication postgres trust #host replication postgres 127.0.0.1/32 trust #host replication postgres ::1/128 trust (but without the comment-sign) Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) "If I was god, I would recompile penguin with --enable-fly." (unknown) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
On Sun, Jan 4, 2015 at 8:01 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
That was indeed the case. I had copied/pasted the code in Microsoft Word and then copied/pasted from Word to recovery.conf. Word intelligently (?) changed the 'quote' type around the file name. On 01/04/2015 06:09 AM, Jayadevan M wrote:Hi,
I have streaming replication set up, with PostgreSQL 9.3. The entries in
recovery.conf on the slave are as follows -
standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=2345 user=postgres
password=password'
restore_command = 'cp /pgdata/archive/%f "%p"'
trigger_file = ‘/tmp/down.trg’
In postgresql.conf on the slave, I have set
hot_standby = on
Replication is working fine. The trigger file does get created by the
failover script when I shut down the primary. But I just keep getting
these entries in the log file in the slave and it does not get promoted.
FATAL: could not connect to the primary server: could not connect to
server: Connection refused
Any suggestions?
Try pg_ctl promote on the standby server to see if it works at all:
http://www.postgresql.org/docs/9.3/interactive/app-pg-ctl.html
If it does then maybe your standby cannot 'see' the trigger file.
I changed log_min_messages to debug2 and saw that the trigger file name was not coming up right.
Thanks.
Regards,
Jayadevan
On 01/04/2015 06:54 PM, Jayadevan M wrote: > > On Sun, Jan 4, 2015 at 8:01 PM, Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>> wrote: > > That was indeed the case. I had copied/pasted the code in Microsoft Word > and then copied/pasted from Word to recovery.conf. Word intelligently > (?) changed the 'quote' type around the file name. Yea, word processors do all sort of 'helpful' things. Type in 1/4 and see what happens. To work with and maintain the integrity of text files on Windows I use Notepad++: http://notepad-plus-plus.org/ > I changed log_min_messages to debug2 and saw that the trigger file name > was not coming up right. > > Thanks. > Regards, > Jayadevan -- Adrian Klaver adrian.klaver@aklaver.com