For personal use, I don't bother with databases on k8s. They are waaay easier to manage if you just let your host distribution run it as a regular service and Upgrade it through that
this post was submitted on 09 Jul 2023
0 points (NaN% liked)
Selfhosted
39227 readers
384 users here now
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:
- 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!
founded 1 year ago
MODERATORS
I never tried it, but does Debian/Ubuntu or any other actually handle the upgrades of the database files?
I have continuously run a MySQL database Server on Ubuntu LTS for the past 10 years. Not once did I have to perform any kind of manual migration. It's all taken care of during distribution upgrades.
Are we talking database schema migrations or migrating a database between Postgres instances?
If it’s the former, the pattern is usually to run them in init containers or Jobs but I have been wanting to try out SchemaHero for a while which is a tool to orchestrate it and looks pretty neat.
ETA: Thought I was replying to your below comment but Memmy deleted it the first time for some reason, my bad.
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.
if it’s needed run pg_upgrade as jobs in kubernetes.
You don't happen to have a manifest for that on hand? I found a github repo with a bunch of dockerfiles that claim to do that, but they seemed kind of sketchy
Never tried it but kubegres seems like a good implementation for kubernetes. I guess if you just have a single-node cluster there won't be much benefit but it seems a periodic backup to NFS is key (you can run NFS on most anything).
What currently pisses me off is the fact that it's almost impossible to do proper migrations for Postgres in k8s. I'd have to look into kubegres, but all approaches I've seen so far involve basically copying the entire PVC and the data inside into a new structure - and doing so involves hacked together scripts.