postgresql – uWSGI,Flask,sqlalchemy和postgres：SSL错误：解

发布时间：2020-12-13 16:38:06 所属栏目：百科来源：网络整理

导读：我正在尝试使用uWSGI Nginx设置一个应用程序网络服务器，它使用SQLAlchemy运行一个Flask应用程序来与Postgres数据库通信。当我向网络服务器发出请求时，所有其他响应将是500错误。错误是： Traceback (most recent call last): File "/var/env/argos/lib/p

我正在尝试使用uWSGI Nginx设置一个应用程序网络服务器，它使用SQLAlchemy运行一个Flask应用程序来与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由管理员管理，它有一个配置：

[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的分叉有关。但除此之外，我还不清楚需要做些什么。

这个问题最终是uwsgi的问题。

当使用主进程处理多个进程时，uwsgi将在主进程中初始化应用程序，然后将应用程序复制到每个工作进程。问题是如果您在初始化应用程序时打开数据库连接，则会有多个进程共享相同的连接，从而导致上述错误。

解决方案是设置懒惰configuration option for uwsgi，这迫使应用程序在每个进程中完全加载：

lazy

Set lazy mode (load apps in workers instead of master).

This option may have memory usage implications as Copy-on-Write semantics can not be used. When lazy is enabled,only workers will be reloaded by uWSGI’s reload signals; the master will remain alive. As such,uWSGI configuration changes are not picked up on reload by the master.

还有一个懒惰应用程序选项：

lazy-apps

Load apps in each worker instead of the master.

This option may have memory usage implications as Copy-on-Write semantics can not be used. Unlike lazy,this only affects the way applications are loaded,not master’s behavior on reload.

这个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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!