4 ms·
What do you mean when you say 'database migration'? In my mind, there could be a few things: 1) Migrating the database from server A to server B where the ser
by MPSimmons 8y ago
What do you mean when you say 'database migration'?
In my mind, there could be a few things:
1) Migrating the database from server A to server B where the server is on Kubernetes
A1) Don't do this. Don't run a (traditional) database server in Kubernetes. Sure, you can do this - there are all kinds of volume support for all kinds of things. Everything I've ever heard and read has told me that containers aren't a good for for this type of long-term service that gets refreshed infrequently.
2) Migrating the database from server A to server B where you have to tell all of the clients what the database is
A2) This should probably be done via service discovery or even just by a short TTL on a CNAME in DNS.
3) Something else?
- subway 8y agoDatabase migrations typically refer to schema/ddl changes to an application along side deployment of a new version. Everything I've ever heard and read has told me that containers aren't a good for for this type of long-term service that gets refreshed infrequently. That was a safe rule of thumb 5 years ago. Since then support for scheduling a persistent volume to be available along side your long running container has become a bog standard and boring feature.
- bonesss 8y ago> Don't run a (traditional) database server in Kubernetes. With node affinities and persistent volumes this might not be A Bad Thing, per se... For something mission critical I'd keep the DB on a VM, though. One interesting development in the Kubernetes space are plugins which expose VMs outside of the cluster to Kubernetes as though it were just another container. That may provide the best of both worlds: a traditional VM and automated scheduling.