uWSGI, колба, sqlalchemy и postgres: ошибка SSL: ошибка расшифровки или плохая запись mac
Я пытаюсь настроить веб-сервер приложений с помощью uWSGI + Nginx, который запускает приложение Flask с помощью SQLAlchemy для связи с базой данных Postgres.
когда я делаю запросы на веб-сервер, любой другой ответ будет 500 ошибка.
ошибка:
Traceback (most recent call last):
File "/var/env/argos/lib/python3.3/site-packages/sqlalchemy/engine/base.py", line 867, in _execute_context
context)
File "/var/env/argos/lib/python3.3/site-packages/sqlalchemy/engine/default.py", line 388, in do_execute
cursor.execute(statement, parameters)
psycopg2.OperationalError: SSL error: decryption failed or bad record mac
The above exception was the direct cause of the following exception:
sqlalchemy.exc.OperationalError: (OperationalError) SSL error: decryption failed or bad record mac
ошибка запускается простым Flask-SQLAlchemy
способ:
result = models.Event.query.get(id)
uwsgi
под управлением supervisor
, который имеет config:
[program:my_app]
command=/usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini --catch-exceptions
directory=/path/to/my/app
stopsignal=QUIT
autostart=true
autorestart=true
и uwsgi
конфигурация выглядит так:
[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
самое большее, что я могу получить, это то, что это имеет какое-то отношение к разветвлению uwsgi. Но кроме этого, я не совсем понимаю, что нужно делать.
2 ответов
проблема в конечном итоге была вилкой uwsgi.
при работе с несколькими процессами с основным процессом uwsgi инициализирует приложение в главном процессе, а затем копирует приложение для каждого рабочего процесса. Проблема в том, что при открытии подключения к базе данных при инициализации приложения у вас есть несколько процессов, использующих одно и то же соединение, что приводит к ошибке выше.
решение установить lazy
настройки вариант на uwsgi, который вынуждает полную загрузку приложения в каждом процессе:
lazy
установить ленивый режим (загрузка приложений в рабочих вместо master).
этот параметр может иметь последствия использования памяти, так как семантика копирования при записи не может использоваться. Когда lazy включен, только рабочие будут перезагружены сигналами перезагрузки uWSGI; мастер останется в живых. Таким образом, изменения конфигурации uWSGI не учитываются при перезагрузке Христос.
там же :
lazy-apps
загрузка приложений в каждом работнике вместо мастера.
этот параметр может иметь последствия использования памяти, так как семантика копирования при записи не может использоваться. В отличие от lazy, это влияет только на способ загрузки приложений, а не на поведение master при перезагрузке.
эта конфигурация uwsgi закончила работу для меня:
[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
в качестве альтернативы вы можете утилизировать двигатель. Вот как я решил проблему.
такие проблемы могут возникнуть, если есть запрос во время создания приложения, то есть в модуле, который создает само приложение. Если это состояние, двигатель выделяет пул соединений, а затем вилки uwsgi.
путем вызова ' engine.dispose ()', сам пул соединений закрыт, и новые соединения появятся, как только кто-то снова начнет делать запросы. Так что если у вас что в конце модуля, где вы создаете свое приложение, будут созданы новые соединения после вилки UWSGI.