31–40 of 93 posts
Earlier quoted context omitted.
What do you reckon the right place(s) to warn people would be?
Probably in the project readme. You could put a warning in the logs as well (e.g. on container startup), but that wouldn't be as visible.
I personally feel like upgrading a database should be an explicit admin process, and isn't something I want my db container entrypoint automagically handling.
Earlier quoted context omitted.
A default option is to warn about the possibility and then just leave the admins to do their own backups (which they should be doing anyway).
What do you reckon the right place(s) to warn people would be?
Earlier quoted context omitted.
What do you reckon the right place(s) to warn people would be?
As an interactive prompt before mutating the data, with a `-y` to bypass the interactive check (and in the docs for `-y`)
Earlier quoted context omitted.
Seems def interesting to handle backup, wonder if could just be something simple enough that lets you downgrade if upgrade fails
Yeah. Probably going to need to add a bunch more error catching and handling-of-specific-situations. Edge cases being a thing and all. :)
Chapter 26. Backup and Restore > 26.3. Continuous Archiving and Point-in-Time Recovery (PITR) > 26.3.4. Recovering Using a Continuous Archive Backup: https://www.postgresql.org/docs/current/continuous-archiving...
IIRC there are fancier ways than pg_dump to do Postgres backups that aren't postgres native PITR?
gh topic postgresql-backup: https://github.com/topics/postgresql-backup
- pgsql-backup.sh: https://github.com/fukawi2/pgsql-backup/blob/develop/src/pgs...
- https://github.com/SadeghHayeri/pgkit#backup https://github.com/SadeghHayeri/pgkit/blob/main/pgkit/cli/co... :
$ sudo pgkit pitr backup
$ sudo pgkit pitr recover
$ sudo pgkit pitr recover latest
- "PostgreSQL-Disaster-Recovery-With-Barman" https://github.com/softwarebrahma/PostgreSQL-Disaster-Recove... :
> The solution architecture chosen here is a 'Traditional backup with WAL streaming' architecture implementation (Backup via rsync/SSH + WAL streaming). This is chosen as it provides incremental backup/restore & a bunch of other features.
Glossary of backup terms: https://en.wikipedia.org/wiki/Glossary_of_backup_terms
Continuous Data Protection > Continuous vs near continuous: https://en.wikipedia.org/wiki/Continuous_Data_Protection#Con...
Earlier quoted context omitted.
Yeah. Probably going to need to add a bunch more error catching and handling-of-specific-situations. Edge cases being a thing and all. :)
Chapter 26. Backup and Restore: https://www.postgresql.org/docs/current/backup.html Chapter 26. Backup and Restore > 26.3. Continuous Archiving and Point-in-Time Recovery (PITR) > 26.3.4. Recovering Using a Continuous Archive Backup: https://www.postgresql.org/docs/current/continuous-archiving... IIRC there are fancier ways than pg_dump to do Postgres backups that aren't postgres native PITR? gh topic postgresql-back…
Earlier quoted context omitted.
Saving it on one host's local filesystem doesn't feel particularly production-ready. There is a distributed store system for Kubernetes called "Longhorn" that I've heard good things about, but I haven't really looked into it much myself. I just run a pair of VMs with a manual primary/replica setup and have never needed to fail over to the replica yet, but I can imagine some sort of fully orchestrated container soluti…
Heh Heh Heh I'm just pointing out how it's commonly done. Of course people add things like replication, distributed filesystems, (etc) to the mix to suit their needs. :)
Neat :) I personally feel like upgrading a database should be an explicit admin process, and isn't something I want my db container entrypoint automagically handling.
This container came about for the Redash project (https://github.com/getredash/redash), which had been stuck on PostgreSQL 9.5 (!) for years.
Moving to a newer PostgreSQL version is easy enough for new installations, but deploying that kind of change to an existing userbase isn't so pretty.
For people familiar with the command line, PostgreSQL, and Docker then its no big deal.
But a large number of Redash deployments seem to have been done by people not skilled in those things. "We deployed it from the Digital Ocean droplet / AWS image / (etc)".
For those situations, something that takes care of the database upgrade process automatically is the better approach. :)
But just to be clear — the point of this is to migrate an existing Postgres DB from the original version to a newer version? This is about the data volume itself, not automatically upgrading the Postgres binary when a new version is released?
So, you’d basically pass a flag that says --migrate-db when starting the container to kick start changing the data on disk? So when you start a new Postgres 15 container, you could pass it a volume with Postgres 13 data and it would auto update the on disk DB data.