I have a question related to Flyway DB Migrations. How to generally manage multiple projects (microservices) dealing with the same DB schema. The Flyway migration scripts in each of the project does not allow to start if it is modified by the other project. Do they have any documentation or best practices on the same?
4
votes
Ideally each microservice should manage its own data and have separate DB schema. It is a bad practice and breaks the rules of microservice architecture to share DB schema between the services.
– sezerug
Although your point is valid that DB schema should be managed (include migrations) by a single module, it can be shared by many modules. Microservices architecture with shared DB is not something new and I believe is the widely used architecture in more than thousands of usecases.
– user3808122
5 Answers
14
votes
We are in the process of doing this. We have one central project that manages the schema creation/management, and other projects handle their own function creations all via their own flyway versioning. This is done by changing the name of the table that those other projects check their schema version against, and setting baseline on migrate to true. We are using spring/flyway-db configuration so this was simply adding the following to application.properties for each project in addition to the first.
flyway.baselineOnMigrate=true
flyway.table=schema_version_*<some_other_identifier>*
I know your question did not specify a spring configuration explicitly, but I believe this can be configured not matter how you are using flyway. I wanted to post an answer as when I was googling the question myself, your SO question was the top result, and I figured my answer might help someone down the track.
5
votes
For what it is worth, this is what we did. Since the schema was shared by multiple projects we had the schema managed by a single project whose task was to maintain said schema. Centralizing schema creation and maintenance had other benefits in that we had single locus of change. We needn't scan several projects for changes.
I honestly think this is the best solution. I don't believe flyway has inter-project schema dependency management.
1
votes
I have faced same issue, because I was working with 2-3 micro services, So what I did is as below example, running in following sequence
micro-service-1 ( which required migration )
micro-service-2
micro-service-3 ( which required migration )
So I created flyway migration v1__description.sql in micro-service-1 and then in micro-service-3 I created v1_2__description.sql because it is at 3rd in sequence of running projects, this is my release version 1, which are having 2 migration with version 1 and 1.2
micro-service-1 ( V1_description.sql )
micro-service-2 // if in future it reuires migration then we can use, V<<currentVersion>>_1__description.sql
micro-service-3 ( V1_2_description.sql )
0
votes
For Microservice Architecture(or Two different Project),
If two different microservice needs to be connected with the database then we need to make two different schemas because as per microservice architecture is two different microservice is connected to different schemas(different database).
like,
- Microservice-1 --> schema-1
- Microservice-2 --> schema-2
due to this flywayDB maintain each microservice flywayDB migration history on each schema, so due to this case flyway DB works
0
votes
if any one using the Play frame work this problem can be tackle with independent flyway history tables for each microservice mean every mircoservice has its own flyway history table with name according to service. this ll create flyway table for each service add these properties in conf file for changing the flyway table name.
db.default.migration.table=microservice1 for 1 mircoservice
db.default.migration.table=microservice2 for 2 mircoservice
add this property in every microservice conf file this is only for play frame work
