From: | Saul Perdomo <saul(dot)perdomo(at)gmail(dot)com> |
---|---|
To: | Tiffany Thang <tiffanythang(at)gmail(dot)com> |
Cc: | Forums postgresql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Managing major PostgreSQL upgrades |
Date: | 2021-11-16 01:48:14 |
Message-ID: | CAN3jBgF8B+tCM=8466NewDRFjEBikr7iJZmUYMU4W0SEc_F+Fg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hey Tiff,
We're in a similar boat. We currently lean on (mostly custom) ansible
scripting to automate all the repeatable tasks we can, but automation of
major PG version upgrades is something we are yet to tackle -- although we
plan to start this effort in the short term.
Would you mind sharing a bit more about your own current upgrade process?
What's your standard, a dump+restore, a pg_upgrade, or replication-based?
Also if you are able to share any lessons learned (e.g. common pitfalls
you've run into) will all be useful information to identify ahead of time
when drafting an automation strategy.
On Mon., Nov. 15, 2021, 6:45 a.m. Tiffany Thang, <tiffanythang(at)gmail(dot)com>
wrote:
> Hi,
> Every year we spent a lot of time planning and manually performing major
> PostgreSQL upgrade on many of our on-prem and RDS instances. I’m wondering
> if there is a better way of managing these upgrades through automation. Can
> anyone share their experiences?
>
> Thanks.
>
> Tiff
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Chen, Yan-Jack (NSB - CN/Hangzhou) | 2021-11-16 05:14:19 | RE: PostgreSQL debug log doesn't record whole procedure(from receiving request to sending response) |
Previous Message | Tom Lane | 2021-11-15 22:07:45 | Re: pg_restore depending on user functions |