Re: Steps to switch from Master to standby mode :

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: prakhar jauhari <prak840(at)gmail(dot)com>
Cc: Strahinja Kustudić <strahinjak(at)nordeus(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Steps to switch from Master to standby mode :
Date: 2013-05-20 00:36:48
Message-ID: CA+HiwqEqOxvE9Ur-+_oAMx4dSoVBO_qNhm0-LzBjwHYHzRbsQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, May 15, 2013 at 3:12 PM, prakhar jauhari <prak840(at)gmail(dot)com> wrote:
> So to allow a standby to recover WAL files that are missing (using archives
> or directly copying wall from the new master to the new standby) in order to
> complete the timeline change, is a wrong approach, I mean is this not safe
> in term of data not being corrupted? Because i tried this and this seems to
> change the timeline on the new standby. For this i added following to my
> recovery file:
>
> restore_command = 'cp <pg_data_dir>/archivedir/%f %p'
> recovery_target_timeline = 'latest'
>
> regards,
> Prakhar.

Hello Prakhar,

Before PostgreSQL 9.3, to switch over from the old master to new
standby (the case in which it failed due to timeline mismatch), you
need to do what you have mentioned you did. The new standby would be
able to transition from old timeline to the new one (in fact the
newest/latest) using timeline history file that is present in the
archive which is updated by the new master to specify at what point in
WAL it branched off from the old timeline to the new timeline. The new
standby is able to follow that information to arrive at a consistent
state. Do try this and report errors if you find any.

Though, you would want to switch to 9.3 to do such things without a
WAL archive.

--
Amit Langote

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Samuel Stearns 2013-05-20 01:32:36 Update pg_type possible problems
Previous Message Armand du Plessis 2013-05-19 16:12:49 Re: Transaction ID wrap limit is log entries