My professional interests are cloud and big data technologies, machine learning, and software development. I like to read source code and research papers to understand how stuff works.
Pronoun: He
Database upgrades can be done in different ways, I suppose.
A simple and flexible way would be to "lock" the database container and migrate the data over to a new one. If we are talking minor or maintenance version upgrades you might get away with mounting the same data directory. If the storage format changed, you can create a SQL dump and import it again. In both cases you'd first have to stop any changes to the existing DB, perform the backup, start a new container with a new version and include the backup.
If your database supports ways that don't involve a downtime, e.g. running replication across versions, you could upgrade one node at a time. Nevertheless all this can be quite annoying to manage so if possible I'd stick to a managed database.
Consultant, Full Stack Dev, Game addict. Tech Lead @ MOBIKO. Loving Nodejs, Typescript and Vue. Interested in Clean Code, agile methods and Software Engineering
thank you for your in-depth answer. Maybe I should give docker a try again and see, if the problems are as big as I imagined. Your post gives me some hope that it's possible to use it in production.
My professional interests are cloud and big data technologies, machine learning, and software development. I like to read source code and research papers to understand how stuff works.
Pronoun: He
TBH, you should use what works best for you! If you're fine with running a DB installed by ansible scripts on virtual machines, then do it. If you're facing problems that Docker can solve then go for it. But don't use something just because it's available ;)
If you'd like, feel free to share some more details on the setup and the problems you're facing :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi!
Schema upgrades can be done independent of Docker, by using migration tools. See Testing Your Database Migrations With Flyway and Testcontainers for more details :)
Database upgrades can be done in different ways, I suppose.
A simple and flexible way would be to "lock" the database container and migrate the data over to a new one. If we are talking minor or maintenance version upgrades you might get away with mounting the same data directory. If the storage format changed, you can create a SQL dump and import it again. In both cases you'd first have to stop any changes to the existing DB, perform the backup, start a new container with a new version and include the backup.
If your database supports ways that don't involve a downtime, e.g. running replication across versions, you could upgrade one node at a time. Nevertheless all this can be quite annoying to manage so if possible I'd stick to a managed database.
Hi Frank,
thank you for your in-depth answer. Maybe I should give docker a try again and see, if the problems are as big as I imagined. Your post gives me some hope that it's possible to use it in production.
Thank you very much for your time and effort!
TBH, you should use what works best for you! If you're fine with running a DB installed by ansible scripts on virtual machines, then do it. If you're facing problems that Docker can solve then go for it. But don't use something just because it's available ;)
If you'd like, feel free to share some more details on the setup and the problems you're facing :)