uWSGI graceful reload coordination with database schema migrations

Integration boundary

uWSGI's master/worker graceful reload and an application's database migration tooling operate independently. During a deployment that includes a schema change, the master process stops routing new requests to old workers after receiving SIGHUP, yet those workers continue processing in-flight requests for up to worker-reload-mercy seconds. Meanwhile, the migration tool may apply a non-backward-compatible schema change at any point in that window.

Constraint

uWSGI provides no built-in drain-mode hook that pauses request acceptance at the load-balancer layer while allowing in-flight work to finish. The --hook-post-fork and --hook-touch-reload callbacks execute in the master process and cannot directly coordinate with application-level transaction boundaries or signal the database migration tool to wait.

Unresolved behavior

Applications must therefore implement their own connection-pool recycling (for example, SQLAlchemy pool_recycle or Django CONN_MAX_AGE) and ensure migrations are either fully backward-compatible or applied atomically outside the reload window. The exact timing of when old workers release database connections relative to the migration commit remains version-dependent.

• What patterns exist for synchronizing a non-backward-compatible schema migration with uWSGI's graceful reload without extending downtime?
• Can the master FIFO or stats socket be used to detect when all pre-reload workers have exited so the migration can proceed safely?
• How should worker-reload-mercy be sized relative to the longest expected request and the migration lock timeout?