Upgrading 9.1.17 to which version?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrading 9.1.17 to which version?

nigel.andersen
Hi,
 
I've just inherited an ancient install of 9.1.17 after our tech guy left, on what turns out to be a rapidly dying server and being a total newb to PostgreSQL (and not much more advanced on Linux) I'm a little stuck on the way ahead.
 
I've managed to secure a decent new server for a new install of PostgreSQL which runs CentOS 7.6 (Minimal). CentOS 7.6's standard PostgreSQL package seems to be 9.2.24 which is obviously no longer supported so probably doesn't get us much further ahead in the short term. As part of this upgrade we'd also like to implement support for pg_trgm which apparently needs >=9.6.
 
I spent most of yesterday trying to get 9.6.13 installed from the PostgreSQL Yum repository and finally got it working with the initdb stuff stored on a non-default dedicated partition (RAID10 array) only to find that psql didn't work and was complaining about a missing libpq.so.5. Not sure if that's a common problem?
 
My (admittedly loose) logic tells me that upgrading from 9.1.x to 9.6.x is probably a safer option than making the leap up to 10.x or 11.x but I wonder whether that might be an easier/more reliable option from an install and point of view and certainly preferable in the long term. Any advice on where to go?
 
Thanks
 
Nigel
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

David G Johnston
On Thu, May 16, 2019 at 9:36 AM <[hidden email]> wrote:
Hi,
 
I've just inherited an ancient install of 9.1.17 after our tech guy left, on what turns out to be a rapidly dying server and being a total newb to PostgreSQL (and not much more advanced on Linux) I'm a little stuck on the way ahead.
 
I've managed to secure a decent new server for a new install of PostgreSQL which runs CentOS 7.6 (Minimal). CentOS 7.6's standard PostgreSQL package seems to be 9.2.24 which is obviously no longer supported so probably doesn't get us much further ahead in the short term.
 
 
Any advice on where to go?

Get a second machine, set it up to be as identical to the existing machine as you can - aside from it not being near death - and migrate "production" to it.

Then on the machine described above install v10 and whatever else you need for staging/testing and then once everything checks out migrate the production database to the new machine and point production resources to it.

Lastly, but first, consider finding an experienced professional to evaluate you exact current circumstances and execute the above - or whatever they recommend.  The first item warrants doing that at the least.  You can delay deciding on how to approach the second option until after your production environment is stable.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

Ron-2
In reply to this post by nigel.andersen
On 5/16/19 4:36 AM, [hidden email] wrote:
Hi,
 
I've just inherited an ancient install of 9.1.17 after our tech guy left, on what turns out to be a rapidly dying server and being a total newb to PostgreSQL (and not much more advanced on Linux) I'm a little stuck on the way ahead.
 
I've managed to secure a decent new server for a new install of PostgreSQL which runs CentOS 7.6 (Minimal). CentOS 7.6's standard PostgreSQL package seems to be 9.2.24 which is obviously no longer supported so probably doesn't get us much further ahead in the short term. As part of this upgrade we'd also like to implement support for pg_trgm which apparently needs >=9.6.
 
I spent most of yesterday trying to get 9.6.13 installed from the PostgreSQL Yum repository and finally got it working with the initdb stuff stored on a non-default dedicated partition (RAID10 array) only to find that psql didn't work and was complaining about a missing libpq.so.5. Not sure if that's a common problem?

What packages did you install?

 
My (admittedly loose) logic tells me that upgrading from 9.1.x to 9.6.x is probably a safer option than making the leap up to 10.x or 11.x

No, not really.

but I wonder whether that might be an easier/more reliable option from an install and point of view and certainly preferable in the long term. Any advice on where to go?

11.x would be best, since it's EOL is furthest in the future.
9.6 would be best, because it's had more bug-fix releases.

:)

--
Angular momentum makes the world go 'round.
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

Fabio Ugo Venchiarutti-2


On 16/05/2019 18:20, Ron wrote:

> On 5/16/19 4:36 AM, [hidden email] wrote:
>> Hi,
>> I've just inherited an ancient install of 9.1.17 after our tech guy
>> left, on what turns out to be a rapidly dying server and being a total
>> newb to PostgreSQL (and not much more advanced on Linux) I'm a little
>> stuck on the way ahead.
>> I've managed to secure a decent new server for a new install of
>> PostgreSQL which runs CentOS 7.6 (Minimal). CentOS 7.6's standard
>> PostgreSQL package seems to be 9.2.24 which is obviously no longer
>> supported so probably doesn't get us much further ahead in the short
>> term. As part of this upgrade we'd also like to implement support for
>> pg_trgm which apparently needs >=9.6.
>> I spent most of yesterday trying to get 9.6.13 installed from the
>> PostgreSQL Yum repository and finally got it working with the initdb
>> stuff stored on a non-default dedicated partition (RAID10 array) only
>> to find that psql didn't work and was complaining about a missing
>> libpq.so.5. Not sure if that's a common problem?
>
> What packages did you install?
>
>> My (admittedly loose) logic tells me that upgrading from 9.1.x to
>> 9.6.x is probably a safer option than making the leap up to 10.x or 11.x
>
> No, not really.
>
>> but I wonder whether that might be an easier/more reliable option from
>> an install and point of view and certainly preferable in the long
>> term. Any advice on where to go?
>
> 11.x would be best, since it's EOL is furthest in the future.
> 9.6 would be best, because it's had more bug-fix releases.
>

Aren't all important bugfixes backported to every non-EOL affected
majors at once?


Correct me if I'm wrong but I thought that's the reason minors are
released at unison for all majors.



> :)
>
> --
> Angular momentum makes the world go 'round.

--
Regards

Fabio Ugo Venchiarutti
OSPCFC Network Engineering Dpt.
Ocado Technology

--


Notice:  This email is confidential and may contain copyright material of
members of the Ocado Group. Opinions and views expressed in this message
may not necessarily reflect the opinions and views of the members of the
Ocado Group. 

 

If you are not the intended recipient, please notify us
immediately and delete all copies of this message. Please note that it is
your responsibility to scan this message for viruses. 

 

Fetch and Sizzle
are trading names of Speciality Stores Limited and Fabled is a trading name
of Marie Claire Beauty Limited, both members of the Ocado Group.

 


References to the “Ocado Group” are to Ocado Group plc (registered in
England and Wales with number 7098618) and its subsidiary undertakings (as
that expression is defined in the Companies Act 2006) from time to time.  
The registered office of Ocado Group plc is Buildings One & Two, Trident
Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.


Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

David G Johnston
On Thu, May 16, 2019 at 10:38 AM Fabio Ugo Venchiarutti <[hidden email]> wrote:
On 16/05/2019 18:20, Ron wrote:
> On 5/16/19 4:36 AM, [hidden email] wrote:
>> but I wonder whether that might be an easier/more reliable option from
>> an install and point of view and certainly preferable in the long
>> term. Any advice on where to go?
>
> 11.x would be best, since it's EOL is furthest in the future.
> 9.6 would be best, because it's had more bug-fix releases.
>

Aren't all important bugfixes backported to every non-EOL affected
majors at once?

More bug-fix-only releases means that more time has gone by to find and fix the bugs in older versions without a corresponding increase in undiscovered bugs that results from moving to the next major release.

David J.

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

Adrian Klaver-4
In reply to this post by Fabio Ugo Venchiarutti-2
On 5/16/19 10:38 AM, Fabio Ugo Venchiarutti wrote:
>
>

>>
>> 11.x would be best, since it's EOL is furthest in the future.
>> 9.6 would be best, because it's had more bug-fix releases.
>>
>
> Aren't all important bugfixes backported to every non-EOL affected
> majors at once?
>
>
> Correct me if I'm wrong but I thought that's the reason minors are
> released at unison for all majors.

True. The possible issue is that the newest version has been out for the
shortest period of time and contains new code that may not have been
exercised enough yet to catch all as yet hidden bugs. Older versions
have been run longer and under more scenarios so the expectation is more
of the bugs have been flushed out.

>
>
>
>> :)
>>
>> --
>> Angular momentum makes the world go 'round.
>


--
Adrian Klaver
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

nigel.andersen
In reply to this post by nigel.andersen

>Get a second machine, set it up to be as identical to the existing machine as you can - aside from it not >being near death - and migrate "production" to it.

>Then on the machine described above install v10 and whatever else you need for staging/testing and then >once everything checks out migrate the production database to the new machine and point production >resources to it.

>Lastly, but first, consider finding an experienced professional to evaluate you exact current >circumstances and execute the above - or whatever they recommend.  The first item warrants doing that at >the least.  You can delay deciding on how to approach the second option until after your production >environment is stable.

>David J.

Thanks for that. It's effectively what I've done by re-incarnating a disused dev server that had an identical install as the prod db server. I dumped the db's last night and loaded them up without any issue. It's a slower machine but it hasn't got disks that are going AWOL and at least gives me some breathing space to setup the new server and test migrate the databases across to a newer version of PostgreSQL today/over the weekend.


Reply | Threaded
Open this post in threaded view
|

Re: Upgrading 9.1.17 to which version?

nigel.andersen
In reply to this post by nigel.andersen

>>I spent most of yesterday trying to get 9.6.13 installed from the PostgreSQL Yum repository and finally >>got it working with the initdb stuff stored on a non-default dedicated partition (RAID10 array) only to >>find that psql didn't work and was complaining about a missing libpq.so.5. Not sure if that's a common >>problem?
>
>What packages did you install?

Initially, postgresql96.x86_64, postgresql96-server.x86_64, postgresql96-contrib.x86_64 all via Yum. Then when psql was complaining about the missing library, I also tried installing postgresql96-libs.x86_64 via yum, which reported "nothing to do". Despite naming the four packages, yum only appeared to actually install two of them, postgresql96-server and postgresql96-contrib. A search for libpq.so.5 after the various attempts to install showed nothing on the server. I then downloaded the postgresql96-libs-9.6.13-1PGDG.rhel7.x86_64.rpm direct from the repository and tried to install that on it's own via rpm but that reported that it was already installed.

In the end, I yum removed all postgresql related files and deleted any postgresql related files/directories on the file system then manually installed the libs rpm outside yum, before re-installing the original three packages and hey presto, all working fine this time around and yum list installed shows them all in the list of installed packages.
 
>>My (admittedly loose) logic tells me that upgrading from 9.1.x to 9.6.x is probably a safer option than >>making the leap up to 10.x or 11.x
>>
>No, not really.

Yup, moving straight to 11.x would definitely be a better long term bet and I may well try migrating one of these db's across to it now I've eeked out a bit of breathing space. 

>>but I wonder whether that might be an easier/more reliable option from an install and point of view and >>certainly preferable in the long term. Any advice on where to go?

>11.x would be best, since it's EOL is furthest in the future.
>9.6 would be best, because it's had more bug-fix releases.