Re: Data migrations ran multiple times during deploy

We experience the same problems and those races are probably inevitable

1. django-syzygy (quroum) may solves this issue as it will use a semaphore to prevent any migrations before seeing "X migrates". this will prevent any races. On the same note, it will introduce migrate --pre which should avoid incompatibilities between new application and old database schema

2. two phase deployment: one app container will deploy the new code (but having no traffic going into it), migrate and redirects all new traffic the new app. secondly, upgrade all other app to new code and reinserting to the deployment load balancer.

On Friday, January 6, 2023 at 2:42:32 PM UTC+2 harrisl...@gmail.com wrote:

Hi, all! Curious about how folks do data migrations as we ran into an issue recently:

Our production deployment consists of three containers running the application. When each container comes up it runs a series of startup tasks include `./manage.py migrate`. Usually it's fine to run this whenever because it's idempotent and Postgres should reject simultaneous schema changes.

So I was surprised recently when we performed a deploy that included a data migration that created some objects and it created the objects multiple times. I'm assuming what happened is that the containers each kicked off a migration command simultaneously (thus all three containers saw that the migration hadn't been run yet) and Postgres didn't block any of the transactions as conflicting.

How do you all avoid this?

Thanks!

Harris

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2cc54299-65c4-4004-86d5-54d94b88e461n%40googlegroups.com.