Thanks, all for the responses! They're helpful, particularly: - Using a separate single service to run migrations - django-syzygy looks interesting and might also solve another issue we've been having lately trying to achieve zero-downtime deploys
Best, Harris On Sunday, January 8, 2023 at 11:16:42 AM UTC-5 [email protected] wrote: > 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 [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/17f0e91f-f4d0-4ef5-b6b2-75f418c9c530n%40googlegroups.com.
