Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
It's about PostgreSQL upgrade.
The "pattern" there is to either dump and reinsert the entire DB or upgrade by having two installations (old and new version), which doesn't exactly work well in k8s. It's possible, but seems hacky
I can’t think of any situation other than maybe wanting to get better indexing or changing the storage engine that I would need to re-create and re-insert that way so I’m not sure if you have a constraint that necessitates that or not but now I’m curious and I am always curious to find new or better methods so why do you do it that way?
At home to upgrade Postgres I would just make a temporary copy the data directory as a backup and then just change the version of the container and if it’s needed run pg_upgrade as jobs in kubernetes.
In a work environment there is more likely to be clustering involved so the upgrade path depends on that but it’s similar but there really isn’t a need to re-create the data, the new version starts with the same PVCs using whatever rollout strategy applies. Major version upgrades can sometimes require extra steps but the engine is almost always backwards compatible at least several versions.
I've always used this docker image to do pg upgrades. It runs pg_upgrade to recreate the system tables and copy the user tables (which normally don't have any storage changes). It does require that the database isn't running during the upgrade so you're going to have a bit of downtime. Make sure you redo any changes to any configuration files, especially pg_hba.conf