[bitnami/postgresql-ha] How to properly handle major version upgrades?

[joachimnielandt]

I am currently testing out the postgresql-HA chart and was wondering how a major version upgrade of PostgreSQL would be handled properly in the default scenario? It is my understanding that the postgres version can be easily modified in the chart's values, but when the data folders are instantiated a major version change (and chart update) results in broken containers. Makes sense, as the data folders have to be updated to match the new postgres version. Will this be handled by the chart in the future, or is there a clean way of doing this manually?

[sameersbn]

@CountZukula IMO the safest way to migrate between major versions is to do a Backup and Restore.

[joachimnielandt]

For most databases that would suffice, but when faced with large datasets I might prefer an in-place upgrade. I understand that this would not be supported in the future of this chart?

[sameersbn]

@CountZukula You are right in that regard. Re: future support, @juan131 @javsalgar could you please chime in here.

[stale]

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.

[sameersbn]

@juan131 any ideas?

[juan131]

Hi @sameersbn

I guess we could try to add some mechanisms to upgrade the schema in the data whenever we detect there's persisted data (using pg_upgrade). However, we should implement this in a way we can skip it since we don't want to play with users data automatically unless they're conscious about it.

We're doing sth similar for MariaDB (see https://github.com/bitnami/bitnami-docker-mariadb/blob/master/10.1/debian-9/rootfs/libmysql.sh#L376 and https://github.com/bitnami/bitnami-docker-mariadb/blob/master/10.1/debian-9/rootfs/libmysql.sh#L718)

[TJM]

Our procedure is roughly:

• Scale APP instances to 0 (kubectl scale sts/artifactory --replicas 0)
• Deploy new release of the latest version of the chart (change release name) in parallel with the old one
• Migrate data:

kubectl exec -it artifactory-db-postgresql-0 -- bash -c 'export PGPASSWORD=${POSTGRES_PASSWORD}; time pg_dump -h artifactory-postgresql -U artifactory | psql -U artifactory'

... where we were moving from the built-in artifactory helm chart's postgresql 9.6.x to the latest 12.x. This is effectively a backup/restore, but I never had to write a file anywhere or worry about kubectl cp'ing it or whatever.,

EDIT: To clarify the above command... artifactory-db-postgresql-0 (release name artifactory-db) is the new instance, while artifactory-postgresql is the old instance (service name) of the "included" postgresql helm chart in artifactory helm chart (release name: artifactory).

• Update application's helm chart configuration to point to new DB, which sets the replicaCount back where it should be
• Delete old PVC

Future upgrades might require appending the PG major version to the release name, to allow both the old and new versions to run at the same time, and a subsequent change of database url in the application helm chart.

[juan131]

Thanks so much for sharing this workaround to backup/restore your existing release data!! We really appreciate it.
I am sure it'll be very helpful for other users!!

[carrodher]

Unfortunately, this issue was created a long time ago and although there is an internal task to fix it, it was not prioritized as something to address in the short/mid term. It's not a technical reason but something related to the capacity since we're a small team.

Being said that, contributions via PRs are more than welcome in both repositories (containers and charts). Just in case you would like to contribute.

During this time, there are several releases of this asset and it's possible the issue has gone as part of other changes. If that's not the case and you are still experiencing this issue, please feel free to reopen it and we will re-evaluate it.