In line Jim
On Sun, Apr 3, 2016 at 10:13 AM, Jim Nasby <Jim.Nasby@bluetreble.com> 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