From: | Philippe Amelant <pamelant(at)companeo(dot)com> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Understanding streaming replication |
Date: | 2012-11-13 16:19:31 |
Message-ID: | 50A27313.9070009@companeo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Le 13/11/2012 14:57, Albe Laurenz a écrit :
> Philippe Amelant wrote:
>>
>> So i was thinking it was just a reconnect to the sender (and I can see
>> the standby trying to reconnect in the log)
> Hmmm. I think I was too quick when I said no.
>
> If you ship the WAL archives including the "history" file to the
> standby, then the standby should be able to recover across the
> timeline change from the archives (if you have recovery_target_timeline
> set to "latest" in recovery.conf) and then reestablish streaming
> replication.
>
> I never tried that though.
>
> (The patch I quoted above would allow the timeline change via
> streaming replication.)
>
> Yours,
> Laurenz Albe
You're right
I added
recovery_target_timeline='latest'
in the recovery.conf then I promoted the standby.
The replication on the second standby stopped with a message
complaining about timeline.
Then I copied the archived wal from the new master to the (stopped)
standby (in pg_xlog)
The standby restarted on the new timeline and the datas seem to be ok.
I also tried to just copy the last 000000X.history in pg_xlog and it
work too.
I suppose this could fail if max_wal_keep_segment is too low
Thanks you very much for your help.
Could you just point me where you found this information in the doc ?
Regards
From | Date | Subject | |
---|---|---|---|
Next Message | Clemens Park | 2012-11-13 16:51:50 | Using window functions to get the unpaginated count for paginated queries |
Previous Message | Aleksandar Lazic | 2012-11-13 15:26:07 | general fear question about move PGDATA from one Disc to another |