I want to deploy my microservices in docker containers. I want these microservices to be as stateless as possible, only persisting state to a database.
This means that there are these requirements:
That leads to my problem with handling schema creation and migrations:
If I have a service that uses MySQL or Postgres as the data store, how do I create the tables/schemas on first launch? Should I just use CREATE IF NOT EXIST statements and let the instances "fight it out" during boot? I am not able to set an environment variable to ask for table/schema creation for just 1 of the instances.
How do I handle schema migrations with the above constraints? There are numerous actions like dropping/adding columns that cannot be encapsulated in a transaction.
You need to use a tool that is capable of supporting database migrations. The two I'd recommend in the Java space would be:
These are by no means the only tools in this category. What they do is keep a record of the schema changes that have already been applied to your database instance, ensuring that the schema matches the desired state captured in your version control system.
In my personal opinion DB migration shouldn't be a microservice responsibility.
Some time ago I read a lot about Blue/Green deployment and DB migrations and our final decision was to trigger DB migrations when needed.
I don't have the links right now but they are easy googlable.
I mentioned Blue/Green deployment since microservices based approach and containers makes it's much simpler so if you are going this direction you probably should consider Blue/Green deployment and it will be much harder if you decide to run migrations from containers.
You can also consider implementing some circuit breaker like approach so microservice will stop accessing DB in case of DB schema problems.