Обсуждение: timeline X of the primary does not match recovery target timeline Y

I am trying to set up master/slave warm standby streaming replication (9.1).  I am not doing archiving/log shipping.  I
haveread 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
triggerfile ( 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
streamingreplication.  As I stated above, I am not archiving/restoring on either the master or slave, I am simply
relyingon streaming replication.... is this the wrong approach?? 




Thanks in advance for the help.

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

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
>

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