Each service instance can run database migrations today. This should not be allowed, to prevent data duplication and corruption.
Detailed overview
Currently, any instance of the service can run database initialization. This is fine for a single-instance deployment, but once we raise two instances of the service, one will fail to take over the initialization or mess up the database.
Before migrating from Spring's JPA solution, we can implement improvements that allow only one instance to run the database migration. We can observe a simple RUN_MIGRATIONS environment variable/flag (or a more appropriate name) from the service.
When running in a multi-instance deployment setup, we can set this variable to false by default but set it to true for a single instance that will run the migration.
It's a naive solution, but it could bridge the gap before the database migration code is moved to a long-term/stable solution.
milosmns
commented
6 months ago
Provide a brief summary of the planned work
Each service instance can run database migrations today. This should not be allowed, to prevent data duplication and corruption.
Detailed overview
Currently, any instance of the service can run database initialization. This is fine for a single-instance deployment, but once we raise two instances of the service, one will fail to take over the initialization or mess up the database.
Before migrating from Spring's JPA solution, we can implement improvements that allow only one instance to run the database migration. We can observe a simple
RUN_MIGRATIONSenvironment variable/flag (or a more appropriate name) from the service.When running in a multi-instance deployment setup, we can set this variable to
falseby default but set it totruefor a single instance that will run the migration.It's a naive solution, but it could bridge the gap before the database migration code is moved to a long-term/stable solution.
Hint/location:
List the acceptance criteria
Include any additional notes (optional)
No response