Skip site navigation (1) Skip section navigation (2)

Re: The other major HS TODO: standby promotion

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The other major HS TODO: standby promotion
Date: 2010-09-06 01:35:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Sep 4, 2010 at 5:02 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> (a) seems easily enough solved by giving two steps: giving the DBA a way
> to check where in the replication stream each standby is (I think we
> already have this)

Yep, pg_last_xlog_receive_location would help.

> The second method would be by giving standbys a way to "subscribe" to a
> new timeline.  This seems like the better approach, as it would
> logically be part of the re-mastering command.  What changes would be
> required to do this?

Wait for new master to archive the timeline history file, set
recovery_target_timeline to 'latest' in unpromoted standbys and
restart them. Which would make them restore WAL files with previous
timeline from the archive and read WAL files with current one.

> (c) can actually already be dealt with by setting an archive_command on
> each standby.  Beyond that, I don't think that we really need to do
> anything; DBAs can have a choice between archiving logs to allow for
> remastering of all standbys, or saving space and bandwidth, and forcing
> some standbys to be re-cloned if you run out of time.  It would be nice,
> eventually, to have a way to tell PostgreSQL to retain more or less WAL
> segments without restarting the server, but I don't see this as critical.

Or the register/unregister of standbys facility is required?

And we would need to change primary_conninfo in all the unpromoted
standbys before restarting them.


Fujii Masao
NTT Open Source Software Center

In response to

pgsql-hackers by date

Next:From: Michael HaggertyDate: 2010-09-06 02:59:18
Subject: Re: git: uh-oh
Previous:From: Andrew ChernowDate: 2010-09-05 23:56:42
Subject: Re: returning multiple result sets from a stored procedure

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group