Re: Slave show ahead of the WAL error - Mailing list pgsql-admin

From Keith
Subject Re: Slave show ahead of the WAL error
Date
Msg-id CAHw75vu2dUOfwrhJbnWo9nhkTvTewgsppVoZfxTr-rMmPz8pcg@mail.gmail.com
Whole thread Raw
In response to Slave show ahead of the WAL error  (Ankur Kaushik <ankurkaushik@gmail.com>)
List pgsql-admin


On Thu, Aug 11, 2016 at 8:51 AM, Ankur Kaushik <ankurkaushik@gmail.com> wrote:

I stopped the slave PostgreSQL

apply 

mv recovery.conf recovery1.conf

Started PostgreSQL

Change pg_hba.conf added new IP

Now

mv recovery1.conf recovery.conf

STARTED Slave Postgresql


Now Error Showing on Slave

< 2016-08-11 18:16:36.409 IST >LOG:  started streaming WAL from primary at 5/E1000000 on timeline 1
< 2016-08-11 18:16:36.409 IST >FATAL:  could not receive data from WAL stream: ERROR:  requested starting point 5/E1000000 is ahead of the WAL flush position of this server 5/E000EDD8


Error Showing on Master

< 2016-08-11 18:11:32.157 IST >LOG:  replication connection authorized: user=repl
< 2016-08-11 18:11:32.214 IST >ERROR:  requested starting point 5/E1000000 is ahead of the WAL flush position of this server 5/E0012708




The presence of the recovery.conf file is what tells postgresql the given instance is a slave. When you started the slave without a valid recovery.conf file, postgres likely made an assumption that it was no longer a slave and put itself into a stand-alone mode. Normally you'd do this by touching the failover file, so I'm really not sure what sort of state you put postgres into when you did it this way. Then when you put the recovery.conf back, it tries to treat that system as a slave, but is unable to connect to the given master because it's no longer at a point where it can pick up the WAL stream.

If all you're trying to do is add a new IP to the pg_hba.conf of the slave, can you do that by editing the file while the database is running and simply issuing a reload.

Keith


pgsql-admin by date:

Previous
From: Ankur Kaushik
Date:
Subject: Slave show ahead of the WAL error
Next
From: Mark Steben
Date:
Subject: pg_upgrade question