Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: postgres hot-standby questions.
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: <848F3721-4A21-4260-9640-8F698E3EE376@skogoglandskap.no>
Date: Thu, 26 Mar 2015 09:07:37 -0600
Cc: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>,
 Simon Riggs <simon@2ndQuadrant.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C08D5DD-0702-4136-BBE3-21CBE064ADDE@elevated-dev.com>
References: <848F3721-4A21-4260-9640-8F698E3EE376@skogoglandskap.no>
To: "Graeme B. Bell" <grb@skogoglandskap.no>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

On Mar 26, 2015, at 8:17 AM, Graeme B. Bell <grb@skogoglandskap.no> wrote:
>=20
> shutdown A (Master)
> shutdown B (Standby)
> (A and B  should be identical in terms of WAL and logical data at this po=
int).
> swap M/S configurations around
> start B (Master)

First, note that you don't actually have to shut down B and swap master/sla=
ve configs. You can use trigger_file in recovery.conf.

In general, with async replication, you don't know that every last transact=
ion is replicated at any moment. (And of course with synch replication, you=
 add points of failure.) I don't actually know the answer to your questions=
, because in my use, the connection between server & replica is high-bandwi=
dth low-latency. My routine is to shut down all services that access the db=
, then shut down the db. The progression of service shutdown pretty much gu=
arantees that if the connection is up, the replica is up to date well befor=
e the master is shut down. So all I have to do is, after access is shut dow=
n use one of the many methods to check replication lag, just as a double-ch=
eck that replication was working.

It does seem to me it would be a good idea to 1) document explicitly in 17.=
5 "Shutting Down the Server" what happens with async replication (I suspect=
 all your guesses are correct) and 2) provide some option to wait for repli=
cation to finish.

The thing about 2 is that we probably don't want it to be automatic or defa=
ult, because the nature of asynch replicas is that it's not uncommon to hav=
e ones far away, over slower less-reliable links, which may take an unknown=
 amount of time to come up to date. It's not uncommon to want to bring the =
master down for a point update or some config change, and immediately bring=
 it back up, in which case we don't want the shutdown delayed. It's also no=
t uncommon to have multiple replicas, some close by that should probably be=
 always up-to-date, and some far away for protection against big disasters,=
 which may lag. So the "wait for replica" option to shut down would need a =
way to specify *which* replica/s we wanted to wait for.

--=20
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin