Re: Timeline Issue - Mailing list pgsql-admin

From Scott Mead
Subject Re: Timeline Issue
Date
Msg-id AANLkTikXPqVXTO_Cqrq-2KoNMongop6hQhSudHUZQkhg@mail.gmail.com
Whole thread Raw
In response to Timeline Issue  (Selva manickaraja <mavles78@gmail.com>)
List pgsql-admin
(Added list back to keep me honest :-)

On Wed, Feb 16, 2011 at 8:41 PM, Selva manickaraja <mavles78@gmail.com> wrote:
So what would be the best option for there on? Should the standby be converted to primary and the initial primary now nominated as standby?

Once you convert to a primary, you're stuck on it.  You'll have to create a new standby from it, the old primary can't be used as a standby.

--Scott

 


On Thu, Feb 17, 2011 at 9:36 AM, Scott Mead <scottm@openscg.com> wrote:
On Wed, Feb 16, 2011 at 8:29 PM, Selva manickaraja <mavles78@gmail.com> wrote:
Dear All,

We have a primary running continous archiving to a secondary. We managed to test fail-over to the secondary by stopping the database in the primary. Then some transactions were tested in the secondary. It was acting well as a primary to accept both read and write.

Now we want to revert this acting primary back to secondary and bring up the actual primary. We know that the secondary had gone out of synch in ahead of primary. So we do a PITR in this secondary before the time when the initial primary was brought down. Now the primary is up and the secondary is brought up as hot-standby. The secondary complaints that it cannot recover because its Timeline 2 does not match with the Timeline 1 of the primary.

Once you open the standby for use, it cannot be put back into standby mode.  You will need to rebuild the standby server from the primary.

--Scott

 

How can this be resolved?

Thank you.

Regards,

Selvam



pgsql-admin by date:

Previous
From: Scott Mead
Date:
Subject: Re: Timeline Issue
Next
From: Selva manickaraja
Date:
Subject: Trigger File Behaviour