In line Jim On Sun, Apr 3, 2016 at 10:13 AM, Jim Nasby <Jim.Nasby@xxxxxxxxxxxxxx> wrote: > On 3/24/16 12:43 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. >> Not sure how I can incorporate with my slon cluster, I guess that will >> be the next thing I research. > > > Not sure I'm following, but you can pg_upgrade your replicas at the same > time as you do the master... or you can do them after the fact. > -- I'm not sure how that statement is true. I'm fundamentally changing the data in the master. My gut says you are thinking, just shut everything down until you have upgraded all 4-5 servers. I'm hoping that's not what you are thinking here. If I update my Master, my slave and query slaves are going to be wondering what the heck is going on. Now I can stop slon, upgrade and restart slon (if Postgres upgrade handles the weird pointers and stuff that slon does on the slave nodes (inside the slon schema), but depending on how long this process takes I'm down for a period of time, that's not acceptable. so I have to upgrade my standby unit, which now fundamentally is different than the master. This is what my statement was referencing, with slon running, how do I use pg_upgrade to upgrade the cluster without downtime. Again slon requires a drop add if I'm rebuilding via slon but as I stated that's almost unbearable at this juncture with how long indexes take.. Thanks Tory -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
