On Mar 26, 2015, at 8:17 AM, Graeme B. Bell <grb@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
