[bitnami/postgresql] Better documentation needed on major version upgrades #14926
Comments
|
Here is a full test of #8025 (comment) that ends in failure: |
|
We are open to contributions! If you want you can create a PR with the things you think are necessary to upgrade, we will be happy to review it! |
I don't have much to contribute here since my attempt above ends in an error. I would think that the Bitnami team would have a full reproducible solution here with the latest postgres chart and images (v 14.x/15.x). That's why I opened this issue. |
|
I execute the following command and there is an error in my minikube：
|
|
Hi @hanbinloop, Could you create another issue with this? This issue is related to the PostgreSQL Chart no with Keycloak. |
|
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
|
not stale |
|
I have created a task internally to review this error. We currently have a lot on our plate. For this reason, we will update this thread when we update the documentation. |
Mauraza
added
the
on-hold
|
bump (anti-stale message) |
|
This seems a serious issue. Because of lack of proper documentation and/or built-in solution I was forced to do some hand-made hack like: Needless to say non of them worked out Native postgres upgrade seems a piece of cake compared to this bitnamichart ecosystem.... |
github-actions
bot
added
on-hold
|
Hi all, |
github-actions
bot
added
triage
This helped as a stopgap. Might also be worth noting this comment, though that wasn't necessarily applicable, since I have a source of truth for my secrets. I haven't actually started on a migration path, but after a quick look at the official keycloak docs, I'd imagine it'd go something like:
Certainly doable, but would be nice if the keycloak folks had something like this out of the box. |
|
I successfully updated from Chart v15 to v17 (and so from postgresql 15 to 16) using the following process:
Chart.yaml apiVersion: v2
name: keycloak
type: application
version: 1.0.0
appVersion: "1.0.0"
dependencies:
- name: keycloak
version: 17.3.1
repository: https://charts.bitnami.com/bitnami
- name: postgresql
alias: postgresql-16
version: 13.2.9
repository: https://charts.bitnami.com/bitnamivalues.yaml keycloak:
[...]
postgresql:
enabled: true
image:
registry: docker.io
repository: bitnami/postgresql
tag: 15.3.0-debian-11-r74
[...]
postgresql-16:
architecture: standalone
auth:
username: keycloak
database: keycloak
existingSecret: keycloak-psql-secret
$ kubectl get secret -n keycloak keycloak-psql-secret -o yaml
apiVersion: v1
data:
db-password: ****
password: ****
postgres-password: ****
kind: Secret
[...]
[...]
postgresql:
enabled: false ############################ Disable the current DB
image:
registry: docker.io
repository: bitnami/postgresql
tag: 15.3.0-debian-11-r74
architecture: standalone
auth:
username: keycloak
database: keycloak
existingSecret: keycloak-psql-secret
externalDatabase: ########################### Setup the new one
host: keycloak-postgresql-16
user: keycloak
database: keycloak
existingSecret: keycloak-psql-secretI know It's not ideal, but it's working and is the only way I could safely update it. Also it should not lead to any downtime, except during restart if you're not in HA. You will just have to ensure that no data are created between backup and restore procedures. |
|
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
|
Not stale |
|
Do we already have an idea how to best solve this? My instinct would be to add an init container that checks the current version against the version of the datafiles on disk. I'd have made this behaviour optional. |
|
Am Wed, Dec 06, 2023 at 08:25:19AM -0800 schrieb 4censord:
Do we already have an idea how to best solve this?
My instinct would be to add an init container that checks the current version against the version of the datafiles on disk.
```
If they match
-> Launch the normal postgres container as always
If they do not match
when version_on_disk is exactly one (1) below the container version
create a backup
perform the upgrade
when this fails
restore the backup to the old location
abort
on success
-> Launch the normal postgres container as always
when not
abort
```
I'd have added this as an optional behaviour to the chart.
This sounds great! It might require a bit additional space. Should that
be a separate volume?
|
|
I ran into this using the bitnami/mastodon chart. I landed up disabling the Postgresql installation bundled with mastodon and using a separate Postgresql. Now I have 2 helm charts to update but I suppose now that I've migrated the data to new new version I I could migrate my data back and reenable using the Mastodon provided one. My older Postgresql 15 pod was named mastodon-postgresql-0 and the fresh installed Postresql 16 had a service named postgresql. I was able to exec into mastodon-postgresql-0, dump the database, and import into the new install by running the following: I then updated the Mastodon chart to disable the provided Postgresql and use my external installation for version 16. I didn't know how to make helm upgrade do this. It's essentially what @headyj did in #14926 (comment) above. |
migruiz4
added
the
on-hold
|
I wrote a script for automatic major version upgrade bitnami/postgres-ha based on job under k8s for reference. https://github.com/exfly/bitnami-pg-upgrade |
|
For more complex scenarios (such as in-place major version upgrades), perhaps it would be good to consider an operator rather than this helm chart? Examples: |
this is what I did, as well. it's looking like relying on the embedded postgresql for keycloak isn't viable long-term. I also opted for neither using this chart nor the embedded postgresql on the keycloak chart and just managing postgresql entirely by myself. slightly different steps that I took that's potentially a bit more scriptable:
|
|
@cjvirtucio87 @headyj maybe I am doing these upgrades wrong but after importing the dump into postgres-16 and pointing keycloak to new postgres it is missing all clients and realms from old setup. |
|
It's 2024, everything is cloudy and automated, and hundreds maybe thousands of helm charts depend on bitnami's postgres chart, leaving every administrator to figure out upgrades on their own? Oh, and giving ideas on how to implement this is great but please open own issues to ask about specifics concerning your upgrade scenario (@amorabito) |
and others
Name and Version
bitnami/postgresql 12.2.0
What is the problem this feature will solve?
Currently the upgrading section of
bitnami/postgresqlis simply an external link to the PostgreSQL docs on how to upgrade major versions. This is insufficient for providing a bare minimum level of information on how to upgrade the PostgreSQL major version when using the Bitnami PostgreSQL Helm chart.I am opening this issue to suggest that Bitnami could be more prescriptive and detailed as to how to upgrade the postgresql chart + image major version, giving specific consideration to PostgreSQL being deployed to Kubernetes, beyond simply linking to the PostgreSQL docs.
A well known paint point of PostgreSQL is that major-version upgrades require generally one of two steps to un-break things:
pg_dumpallorpg_upgrade. In the absence of these, the PostgreSQL upgrade will fail withFATAL database files are incompatible with serverand indicate thatThe Bitnami documentation could at the very least make a recommendation between one of these two methods, or provide a complete, working, and minimal example for upgrading.
What is the feature you are proposing to solve the problem?
To more easily upgrade the PostgreSQL major version, either because we have bumped the Bitnami chart major version or explicitly bumped the
postgresql.image.tag.What alternatives have you considered?
The text was updated successfully, but these errors were encountered: