Question regarding multiple instances run alembic head upgrade at the same time, Does it cause risk condition?

[zch-cc]

Hi I have a quick question. I have a service which run alembic head upgrade every time it starts. Typically it works fine since if the db is already in the newest state, the migration does nothing. Since I put the program in auto sclaing group, so there could be multiple instances running alembic head upgrade at the same time, I want to ask if this cause risk condition? If it does, what is the best way to avoid it? One thought is to have another table with one entry to act like lock, only if you get the lock you perform the upgrade. Is there other ways to handle it? Thanks

[zzzeek]

yah that's totally not correct, you'd have multiple connections all trying to run the same CREATE / ALTER statements etc. and conflicting. you need to run just one connection at a time with DDL in it, you can't mix those things up.

usually the part of the program that runs migrations is separate from the part of the program that handles requests, so the "run the migrations" part would not be in an "auto scaled" system. it would be part of whatever your framework uses for building up initial setup.

[rd-ewaryst-schulz]

I would love to have the functionality described above in alembic! I worked for years with spring-boot services with liquibase that supports this scenario and had no headaches about deployments of auto-scaled services. IMHO it's just a matter of a lock-table for the migration... but of course it's not complicated to put such a mechanism around the migration-code, perhaps it may be beneficial, e.g., if you need some more "exclusive" setup that only one instance should do while the others are waiting before continuing.

[zzzeek]

right, you can do this in your own env.py in a way that works for your setup. within alembic proper it's not something we want to have to support.