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 av...@secondnature.ai 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 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/17f0e91f-f4d0-4ef5-b6b2-75f418c9c530n%40googlegroups.com.
