-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Currently database migrations are executed by the service itself at every connector startup.
This can be considered an anti-pattern in many environments, especially in the clustered ones. Migrations are time consuming also if they do nothing, so the runtime startup time suffers from this (in other projects it was measured around the 20-30% of the startup time).
Plus, that could make multi-replica connector zero-downtime deployment problematic.
My proposal would be to keep using flyway as tool for the migrations, but to run it offline through the flyway-cli, there's also an docker image that could become handy expecially in production environments.
by doing that, it will be possible to decide when the migrations should be executed, likely before a version upgrade, ensuring that the migrations to be applied are not disruptive (they should never be!).