Simon Riggs <simon@xxxxxxxxxxxxxxx> writes: > On Tue, Jun 7, 2011 at 8:41 PM, Ray Stell <stellr@xxxxxxxxxx> wrote: > >> On Tue, Jun 07, 2011 at 11:59:07AM -0700, A J wrote: >>> We then rely on filesystem tools (or other third party tools) to get the >>> original master in sync with the new master efficiently and then make it join as >>> slave. >> >> the doc would not be corrupted by an additional few words that stated as such: >> >> "To return to normal operation, a standby server must be recreated using >> external tools such as rsync, either on the former primary system when >> it comes up, or on a third, possibly new, system." > > You need repmgr: http://www.repmgr.org/ Well, I am not sure on the 9.x versions but, we used to do reversible master/standby with log shipping on the 8.x versions quite routinely, sometimes reshaping clusters of multiple standbys., designating a new master, restarting the old master in recovery mode and repointing the remaining standbys.. The procedure was similar to... apps down and locked out pg_rotate_xlog() on master verify final log received on standbys and consumed bring up new master kill immediate on old master and remaining standbys configure old master as standby w/recovery.conf and point to new xlog repository repoint other standbys to new repository and restart There was no need to reinitialize from scratch or rsync the old master or other standbys. Somewhere between 8.2 and 8.4 there was a change that would require you to increment the recovery target timeline during this operation. It took me a bit of head scratching to get it right. This capability was apparently little known and used, perhaps due to uncertainty that it was viable, given the undocumented nature of this. Disclaimer: I do not know if this still works on 9.x using either log shipping or streaming replication. I covered this strategy briefly during my talk at the 2010 Pg-East conference in Philly. YMMV > -- > Simon Riggs http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > -- > Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin > -- Jerry Sievers Postgres DBA/Development Consulting e: gsievers19@xxxxxxxxxxx p: 305.321.1144 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
