Het probleem was uiteindelijk de forking van uwsgi.
Wanneer u met meerdere processen met een masterproces werkt, initialiseert uwsgi de applicatie in het masterproces en kopieert de applicatie vervolgens naar elk werkproces. Het probleem is dat als u een databaseverbinding opent bij het initialiseren van uw toepassing, u meerdere processen dezelfde verbinding heeft, wat de bovenstaande fout veroorzaakt.
De oplossing is om de lazy . in te stellen configuratie-optie voor uwsgi, die een volledige lading van de applicatie in elk proces dwingt:
lazy
Stel de luie modus in (laad apps in worker in plaats van master).
Deze optie kan gevolgen hebben voor het geheugengebruik, aangezien Copy-on-Write-semantiek niet kan worden gebruikt. Als lui is ingeschakeld, worden alleen werknemers opnieuw geladen door de herlaadsignalen van uWSGI; de meester blijft in leven. Als zodanig worden uWSGI-configuratiewijzigingen niet opgepikt bij het opnieuw laden door de master.
Er is ook een lazy-apps optie:
lazy-apps
Laad apps in elke worker in plaats van in de master.
Deze optie kan gevolgen hebben voor het geheugengebruik, aangezien Copy-on-Write-semantiek niet kan worden gebruikt. In tegenstelling tot lui, heeft dit alleen invloed op de manier waarop applicaties worden geladen, niet op het gedrag van de master bij het opnieuw laden.
Deze uwsgi-configuratie werkte uiteindelijk voor mij:
[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