Upgrading 9.1.17 to which version?

2019-05-16 Thread 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

 

 




Re: Upgrading 9.1.17 to which version?

2019-05-17 Thread 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.




Re: Upgrading 9.1.17 to which version?

2019-05-17 Thread 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.