From: Scott Ribe <scott_ribe@elevated-dev.com>
To: Graeme B. Bell <grb@skogoglandskap.no>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Subject: Re: postgres hot-standby questions.
Date: Thu, 26 Mar 2015 09:07:37 -0600
Message-ID: <3C08D5DD-0702-4136-BBE3-21CBE064ADDE@elevated-dev.com> (raw)
In-Reply-To: <848F3721-4A21-4260-9640-8F698E3EE376@skogoglandskap.no>
References: <848F3721-4A21-4260-9640-8F698E3EE376@skogoglandskap.no>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
On Mar 26, 2015, at 8:17 AM, Graeme B. Bell <grb@skogoglandskap.no> wrote:
>
> shutdown A (Master)
> shutdown B (Standby)
> (A and B should be identical in terms of WAL and logical data at this point).
> swap M/S configurations around
> start B (Master)
First, note that you don't actually have to shut down B and swap master/slave configs. You can use trigger_file in recovery.conf.
In general, with async replication, you don't know that every last transaction 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-bandwidth 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 guarantees that if the connection is up, the replica is up to date well before the master is shut down. So all I have to do is, after access is shut down use one of the many methods to check replication lag, just as a double-check 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 replication to finish.
The thing about 2 is that we probably don't want it to be automatic or default, because the nature of asynch replicas is that it's not uncommon to have 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 not 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.
--
Scott Ribe
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: scott_ribe@elevated-dev.com, grb@skogoglandskap.no, simon@2ndQuadrant.com
Subject: Re: postgres hot-standby questions.
In-Reply-To: <3C08D5DD-0702-4136-BBE3-21CBE064ADDE@elevated-dev.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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