El problema terminó siendo la bifurcación de uwsgi.
Cuando se trabaja con varios procesos con un proceso maestro, uwsgi inicializa la aplicación en el proceso maestro y luego copia la aplicación en cada proceso de trabajo. El problema es que si abre una conexión de base de datos al inicializar su aplicación, entonces tiene varios procesos compartiendo la misma conexión, lo que provoca el error anterior.
La solución es configurar el lazy opción de configuración para uwsgi, que fuerza una carga completa de la aplicación en cada proceso:
lazy
Establezca el modo perezoso (cargue aplicaciones en trabajadores en lugar de maestro).
Esta opción puede tener implicaciones en el uso de la memoria, ya que no se puede utilizar la semántica de copia en escritura. Cuando lazy está habilitado, solo los trabajadores serán recargados por las señales de recarga de uWSGI; el maestro seguirá vivo. Como tal, los cambios de configuración de uWSGI no son recogidos en la recarga por el maestro.
También hay una lazy-apps opción:
lazy-apps
Cargue aplicaciones en cada trabajador en lugar del maestro.
Esta opción puede tener implicaciones en el uso de la memoria, ya que no se puede utilizar la semántica de copia en escritura. A diferencia de lazy, esto solo afecta la forma en que se cargan las aplicaciones, no el comportamiento del maestro al recargar.
Esta configuración de uwsgi terminó funcionando para mí:
[uwsgi]
socket = /tmp/my_app.sock
logto = /var/log/my_app.log
plugins = python3
virtualenv = /path/to/my/venv
pythonpath = /path/to/my/app
wsgi-file = /path/to/my/app/application.py
callable = app
max-requests = 1000
chmod-socket = 666
chown-socket = www-data:www-data
master = true
processes = 2
no-orphans = true
log-date = true
uid = www-data
gid = www-data
# the fix
lazy = true
lazy-apps = true
