Problem okazał się rozwidleniem uwsgi.
Podczas pracy z wieloma procesami z procesem głównym, uwsgi inicjuje aplikację w procesie głównym, a następnie kopiuje aplikację do każdego procesu roboczego. Problem polega na tym, że jeśli otworzysz połączenie z bazą danych podczas inicjowania aplikacji, wtedy wiele procesów współdzieli to samo połączenie, co powoduje powyższy błąd.
Rozwiązaniem jest ustawienie lazy opcja konfiguracji dla uwsgi, która wymusza pełne ładowanie aplikacji w każdym procesie:
lazy
Ustaw tryb leniwy (ładuj aplikacje do pracowników zamiast do głównego).
Ta opcja może mieć wpływ na użycie pamięci, ponieważ nie można użyć semantyki kopiowania przy zapisie. Gdy opcja lenistwa jest włączona, tylko pracownicy będą przeładowywani przez sygnały przeładowania uWSGI; mistrz pozostanie przy życiu. W związku z tym zmiany w konfiguracji uWSGI nie są pobierane po ponownym załadowaniu przez mastera.
Jest też lazy-apps opcja:
lazy-apps
Załaduj aplikacje do każdego pracownika zamiast do głównego.
Ta opcja może mieć wpływ na użycie pamięci, ponieważ nie można użyć semantyki kopiowania przy zapisie. W przeciwieństwie do lenistwa, ma to wpływ tylko na sposób ładowania aplikacji, a nie na zachowanie mastera po ponownym załadowaniu.
Ta konfiguracja uwsgi zakończyła się dla mnie pracą:
[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
