If you can, never do in place upgrade. Way too many things that can go wrong, be in an unexpected state or the upgrade goes wrong and leaves your system broken.
Install a new machine and migrate to there.
If you have a deployment framework, even better. Roll out new cattle and if needed, migrate. Let (Ansible/salt/puppet etc) do the work for you .
And never ever use a non LTS version for production systems…
Thanks for your feedback.
I’ve shared the process that I usually use in my local machine when I upgrade the Ubuntu version to a new version.
It’s not intended for production system but only for development environment.
Thanks for your suggestion, but for my local development needs, the PostgreSQL’s packages from Ubuntu are perfect. I have the latest stable PostgreSQL release (11.3 now) and my Ubuntu is the cleanest possible with no external repositories.
By the way my Howto article is valid also if you use the postgresql.org repositories.
I wonder if it possible to create an idempotent ansible playbook (or using other tools) that can do upgrade of prod, after it has been tested outside of prod (or if somebody has created something like that for general use)
For example, we use Pyrseas [1] to do schema management, and that tool allows for Idempotent schema upgrade
(meaning that it creates a difference between your full schema definition, and target, and then you to apply just the difference to target, automatically (which is what we do from an ansible playbook).
An ansible playbook for an idempotent PG binary upgrade, would have to involve:
a) detection on the target system,
b) what version of binaries to install,
c) un-installing previous binary (or changing alternatives such that previous bins are still available but not ‘active’)
, and installing new binaries
d) then a merge of PG config files (assuming that the new version has new configs),
e) making a master copy, and testing that master copy was made correctly !
f) applying any changes to master, that might be needed (some time old capabilities that procs rely on, are deprecated), smoke test, and then, if successful, enabling master copy to be prod
Thanks for your feedback.
As I replied before I’ve shared the process that I usually use in my local machine when I upgrade the Ubuntu version to a new version.
It’s not intended for production system but only for development environment.
If you can, never do in place upgrade. Way too many things that can go wrong, be in an unexpected state or the upgrade goes wrong and leaves your system broken.
Install a new machine and migrate to there.
If you have a deployment framework, even better. Roll out new cattle and if needed, migrate. Let (Ansible/salt/puppet etc) do the work for you .
And never ever use a non LTS version for production systems…
Thanks for your feedback. I’ve shared the process that I usually use in my local machine when I upgrade the Ubuntu version to a new version. It’s not intended for production system but only for development environment.
For PostgreSQL it’s probably a good idea to use their repos instead of your distro’s.
https://www.postgresql.org/download/linux/
Additional benefit is that you get to control the major versions, so most blanket “yum upgrade”s should be safe.
Thanks for your suggestion, but for my local development needs, the PostgreSQL’s packages from Ubuntu are perfect. I have the latest stable PostgreSQL release (11.3 now) and my Ubuntu is the cleanest possible with no external repositories.
By the way my Howto article is valid also if you use the postgresql.org repositories.
I wonder if it possible to create an idempotent ansible playbook (or using other tools) that can do upgrade of prod, after it has been tested outside of prod (or if somebody has created something like that for general use)
For example, we use Pyrseas [1] to do schema management, and that tool allows for Idempotent schema upgrade (meaning that it creates a difference between your full schema definition, and target, and then you to apply just the difference to target, automatically (which is what we do from an ansible playbook).
An ansible playbook for an idempotent PG binary upgrade, would have to involve:
a) detection on the target system,
b) what version of binaries to install,
c) un-installing previous binary (or changing alternatives such that previous bins are still available but not ‘active’) , and installing new binaries
d) then a merge of PG config files (assuming that the new version has new configs),
e) making a master copy, and testing that master copy was made correctly !
f) applying any changes to master, that might be needed (some time old capabilities that procs rely on, are deprecated), smoke test, and then, if successful, enabling master copy to be prod
[1] https://pypi.org/project/Pyrseas/
Thanks for your feedback. As I replied before I’ve shared the process that I usually use in my local machine when I upgrade the Ubuntu version to a new version. It’s not intended for production system but only for development environment.