From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | TJ <tj(at)melodicninja(dot)co(dot)uk> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [pgeu-general] Replication failover |
Date: | 2013-05-22 22:26:29 |
Message-ID: | 519D4615.3070800@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgeu-general pgsql-general |
BTW, pgeu-general is not for technical questions, so moving to
pgsql-general. (I didn't notice the mailing list this came from until
after replying).
On 22.05.2013 18:22, Heikki Linnakangas wrote:
> On 22.05.2013 10:23, TJ wrote:
>> I am looking to migrate my databases from one set of hardware to another
>> all the servers are running PGSQL 9.x
>
> Which version exactly? There are differences in this area between 9.0,
> 9.1, and 9.2. If you can choose, use the latest 9.2.X version.
>
>> The problem i have is that when i fail over to server3 using the trigger
>> file it will increment the timeline which will stop the replication of
>> server4.
>
> With 9.1 and above, it will notice the new timeline and start following
> it, if you set up a WAL archive in addition to streaming replication and
> set recovery_target_timeline='latest' in recovery.conf. Starting with
> 9.3, a standby can follow a timeline changes over streaming replication
> too, so in 9.3 it should just work.
>
> That's all assuming that server4 is behind server3; if it has already
> replayed WAL beyond the point in the WAL where server3 switched to a new
> timeline, it can't follow that timeline switch.
>
> - Heikki
>
>
--
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | TJ | 2013-05-23 07:55:28 | Re: [pgeu-general] Replication failover |
Previous Message | Heikki Linnakangas | 2013-05-22 22:22:01 | Re: Replication failover |
From | Date | Subject | |
---|---|---|---|
Next Message | Neeraj Rai | 2013-05-22 23:52:13 | - pgaql long value corrupted using htons |
Previous Message | Heikki Linnakangas | 2013-05-22 22:22:01 | Re: Replication failover |