From: | "James Bardin" <jbardin(at)bu(dot)edu> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #5011: Standby recovery unable to follow timeline change |
Date: | 2009-08-25 19:48:03 |
Message-ID: | 200908251948.n7PJm30e032504@wwwmaster.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 사이트SQL : Postg토토 사이트SQL 메일 링리스트 : 2009-08-25 이후 PGSQL-BUGS 19:48 |
The following bug has been logged online:
Bug reference: 5011
Logged by: James Bardin
Email address: jbardin(at)bu(dot)edu
PostgreSQL version: 8.4.0-1
Operating system: Centos 5.3
Description: Standby recovery unable to follow timeline change
Details:
This is another use case that fails with what looks like the same issue as
BUG #4796.
http://archives.postgresql.org/pgsql-bugs/2009-05/msg00060.php
(Sorry if this bug is redundant, I couldn't find any way to contribute to
that thread directly)
I'm working on a system where the master and standby servers are expected to
be able to swap roles repeatedly. The first failover works fine, but the
ex-master, now standby, can't recover using the shipped logs.
Using recovery_target_timeline='latest' finds the new history file, and
pg_standby looks good until recovery is attempted. Then we log errors like:
LOG: unexpected timeline ID 0 in log file 0, segment 1, offset 0
LOG: invalid primary checkpoint record
and any changes made after the first failover are lost.
Is this currently possible, or do I have to send a full file-level backup to
sync the ex-master server with the new master?
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-08-25 21:29:41 | Re: BUG #5011: Standby recovery unable to follow timeline change |
Previous Message | Magnus Hagander | 2009-08-25 16:42:28 | Re: BUG #5008: Server Startup Problem - When server is configured for SSL |