pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedtimeline X of the primary does not match recovery target timeline Y
5+ messages / 2 participants
[nested] [flat]
* timeline X of the primary does not match recovery target timeline Y
@ 2011-09-26 12:54 Adam Tistler <atistler@gmail.com>
0 siblings, 2 replies; 5+ messages in thread
From: Adam Tistler @ 2011-09-26 12:54 UTC (permalink / raw)
To: pgsql-general@postgresql.org
I am trying to set up master/slave warm standby streaming replication (9.1). I am not doing archiving/log shipping. I have read that you cannot reverse roles between the master and slave, and that once a slave is "promoted", you need to use pg_basebackup or rsync to copy files from the newly promoted master to the old master. I am fine with this, however, in my case all I am trying to do is re-enable the slave to be in recovery mode. I am doing this by deleting the trigger file ( which I had originally created to promote the slave to master ) and moving recovery.done to recovery.conf, then restarting postgres. As a result I get the following error:
FATAL: timeline 2 of the primary does not match recovery target timeline 3
Relevant info:
on master: postgresql.conf
max_wal_senders = 5
wal_keep_segments = 32
checkpoint_segments = 8
wal_level = hot_standby
on slave: recovery.conf
standby_mode = on
primary_conninfo = 'host=172.16.135.205 port=5432 user=replicator password=replicator'
trigger_file = '/tmp/pgsql.trigger'
everything in postgresql.conf on the slave is default related to replication.
On a side note I am slightly confused as to why someone would use "archive mode/restore_command" in combination with streaming replication. As I stated above, I am not archiving/restoring on either the master or slave, I am simply relying on streaming replication.... is this the wrong approach??
Thanks in advance for the help.
^ permalink raw reply [nested|flat] 5+ messages in thread
* timeline X of the primary does not match recovery target timeline Y
@ 2011-09-27 17:15 Adam Tistler <atistler@gmail.com>
parent: Adam Tistler <atistler@gmail.com>
1 sibling, 0 replies; 5+ messages in thread
From: Adam Tistler @ 2011-09-27 17:15 UTC (permalink / raw)
To: pgsql-admin
I am trying to set up master/slave warm standby streaming replication (9.1). I am not doing archiving/log shipping. I have read that you cannot reverse roles between the master and slave, and that once a slave is "promoted", you need to use pg_basebackup or rsync to copy files from the newly promoted master to the old master. I am fine with this, however, in my case all I am trying to do is re-enable the slave to be in recovery mode. I am doing this by deleting the trigger file ( which I had originally created to promote the slave to master ) and moving recovery.done to recovery.conf, then restarting postgres. As a result I get the following error:
FATAL: timeline 2 of the primary does not match recovery target timeline 3
Relevant info:
on master: postgresql.conf
max_wal_senders = 5
wal_keep_segments = 32
checkpoint_segments = 8
wal_level = hot_standby
on slave: recovery.conf
standby_mode = on
primary_conninfo = 'host=172.16.135.205 port=5432 user=replicator password=replicator'
trigger_file = '/tmp/pgsql.trigger'
everything in postgresql.conf on the slave is default related to replication.
On a side note I am slightly confused as to why someone would use "archive mode/restore_command" in combination with streaming replication. As I stated above, I am not archiving/restoring on either the master or slave, I am simply relying on streaming replication.... is this the wrong approach??
Thanks in advance for the help.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: timeline X of the primary does not match recovery target timeline Y
@ 2011-10-20 16:00 Jeff Davis <pgsql@j-davis.com>
parent: Adam Tistler <atistler@gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: Jeff Davis @ 2011-10-20 16:00 UTC (permalink / raw)
To: Adam Tistler <atistler@gmail.com>; +Cc: pgsql-general@postgresql.org
On Mon, 2011-09-26 at 08:54 -0400, Adam Tistler wrote:
> I am trying to set up master/slave warm standby streaming replication
> (9.1). I am not doing archiving/log shipping. I have read that you
> cannot reverse roles between the master and slave, and that once a
> slave is "promoted", you need to use pg_basebackup or rsync to copy
> files from the newly promoted master to the old master. I am fine
> with this, however, in my case all I am trying to do is re-enable the
> slave to be in recovery mode. I am doing this by deleting the trigger
> file ( which I had originally created to promote the slave to master )
> and moving recovery.done to recovery.conf, then restarting postgres.
> As a result I get the following error:
>
> FATAL: timeline 2 of the primary does not match recovery target
> timeline 3
Once it's promoted to a primary, you can't set it to start recovering
from another system again (without taking a new base backup).
Did I understand your question correctly?
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: timeline X of the primary does not match recovery target timeline Y
@ 2011-10-20 16:45 Adam Tistler <atistler@gmail.com>
parent: Jeff Davis <pgsql@j-davis.com>
0 siblings, 1 reply; 5+ messages in thread
From: Adam Tistler @ 2011-10-20 16:45 UTC (permalink / raw)
To: Jeff Davis <pgsql@j-davis.com>; +Cc: pgsql-general@postgresql.org
Yes you understood correctly. Would the same apply for a hot standby situation?
On Oct 20, 2011, at 12:00 PM, Jeff Davis wrote:
> On Mon, 2011-09-26 at 08:54 -0400, Adam Tistler wrote:
>> I am trying to set up master/slave warm standby streaming replication
>> (9.1). I am not doing archiving/log shipping. I have read that you
>> cannot reverse roles between the master and slave, and that once a
>> slave is "promoted", you need to use pg_basebackup or rsync to copy
>> files from the newly promoted master to the old master. I am fine
>> with this, however, in my case all I am trying to do is re-enable the
>> slave to be in recovery mode. I am doing this by deleting the trigger
>> file ( which I had originally created to promote the slave to master )
>> and moving recovery.done to recovery.conf, then restarting postgres.
>> As a result I get the following error:
>>
>> FATAL: timeline 2 of the primary does not match recovery target
>> timeline 3
>
> Once it's promoted to a primary, you can't set it to start recovering
> from another system again (without taking a new base backup).
>
> Did I understand your question correctly?
>
> Regards,
> Jeff Davis
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: timeline X of the primary does not match recovery target timeline Y
@ 2011-10-20 17:08 Jeff Davis <pgsql@j-davis.com>
parent: Adam Tistler <atistler@gmail.com>
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Davis @ 2011-10-20 17:08 UTC (permalink / raw)
To: Adam Tistler <atistler@gmail.com>; +Cc: pgsql-general@postgresql.org
On Thu, 2011-10-20 at 12:45 -0400, Adam Tistler wrote:
> Yes you understood correctly. Would the same apply for a hot standby situation?
Right. Hot standby just means that you can query (read-only) an instance
that's still in recovery.
Basically, going from recovery mode (or hot standby, which is also
recovery mode) to "up" (that is, can accept write queries and operate
normally) is not a reversible process. You have to make a new base
backup of another system to start recovering again.
Regards,
Jeff Davis
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2011-10-20 17:08 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-09-26 12:54 timeline X of the primary does not match recovery target timeline Y Adam Tistler <atistler@gmail.com>
2011-09-27 17:15 ` Adam Tistler <atistler@gmail.com>
2011-10-20 16:00 ` Jeff Davis <pgsql@j-davis.com>
2011-10-20 16:45 ` Adam Tistler <atistler@gmail.com>
2011-10-20 17:08 ` Jeff Davis <pgsql@j-davis.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox