On Tue, Jun 14, 2016 at 2:03 PM, Jim Nasby <Jim.Nasby@xxxxxxxxxxxxxx> wrote: > On 4/19/16 11:01 PM, Tory M Blue wrote: >>>> >>>> >> Slon is also starting to not be viable as it takes some indexes over >>>> >> 7 >>>> >> hours to complete. So this upgrade path seemed to really be nice. >>> >>> > >>> > >>> > If you're standing up a new replica from scratch on the latest version, >>> > I'm >>> > not really sure why that matters? >> >> Not sure why the 7-13 hours causes an issue? Because if I'm upgrading >> via slon process, I have to add and drop a node. If I'm dropping my >> secondary (slave) I have to move reporting to the master, so now the >> master is handing normal inserts and reports. Next item, I'm without >> a replica for 13+ hours, that's not good either. > > > Don't drop and add a node, just do a master switchover. AFAIK that's nearly > instant as long as things are in sync. > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com > 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 Right, that's what we do, but then to upgrade, we have to drop/add the node, because it's being upgraded. If I'm updating the underlying OS, I have to kill it all. If I'm doing a postgres upgrade, using an old version of slon, without using pg_upgrade, I have to drop the db, recreate it, which requires a drop/add. I'm trying to figure out how to best do it using pg_upgrade instead of the entire drop/add for postgres upgrades (which are needed if you are using slon as an upgrade engine for your db). Tory -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
