MySQL OperationalError при запуске сервера Flask (Apache) в течение нескольких дней

У меня есть сервер Flask под Apache, который я использую в качестве API-интерфейса для приложения, и когда сервер работает в течение 2 - 3 дней, он внезапно перестает работать и поднимает OperationalError: MySQL Connection not available.

Ошибка всегда выполняется с помощью метода login, потому что она открывается первым при открытии приложения (но все методы следуют одному и тому же шаблону).

Сначала я думал, что проблема происходит, потому что я не использовал buffered=True в курсоре, который вызывает метод fetchone. Но я добавил этот параметр после прочтения этого.

Это мой файл sites-available conf (я хотел сказать, что я пробовал множество комбинаций параметров threads и processes, и эта комбинация является той, которая поддерживает работу сервера в наибольшей степени время, обычно 2 - 3 дня):

Я запускаю Apache/2.4.10 под armbian (Debian) в банановой Pi.

Я действительно не знаю, почему сервер перестает работать некоторое время, я думаю, что пробовал почти все.

EDIT: Я добавил также cursor.close(), прежде чем выбросить ошибку 403 в метод login. Но это не актуально, поскольку я единственный, кто регистрируется в приложении, и я всегда ввожу правильные учетные данные.

РЕДАКТИРОВАТЬ 2: Как сказал мне @stamaimer, если я добавлю connection.ping(), прежде чем получить какой-либо курсор, он будет работать хорошо, но этот подход кажется мне взломанным способом и не знаю, является ли это хорошим решением или даже почему сервер MySQL отключает соединение.

Ответы

Ответ 1

Основываясь на @9000s answer, ping должен работать нормально при вызове с параметром reconnect=True, см. соответствующий код. Это вызовет ping, и в случае неудачного ping попытайтесь подключиться к базе данных.

Хотя это должно исправить ошибку, вы должны немного разобраться, чтобы найти основную проблему, которая является нефункциональным подключением к MySQL.

Как уже упоминалось, это может быть результатом нескольких источников, поэтому, возможно, вы можете использовать следующий список, чтобы вести поиск:

Существуют ли другие сообщения об ошибках в журнале, прежде чем вы отправили сообщение?
Вы подключаетесь к MySQL через TCP/IP или через сокет? Возможно, попробуйте другой вариант, если он работает, а другой - нет, это может помочь выявить проблему.
Увеличьте max_timeout до большого значения, просто чтобы убедиться, что он имеет эффект.
Вы также можете увеличить max_allowed_packet, поскольку это помогло в других случаях.
Проверьте журналы сервера MySQL на наличие возможных проблем с потерянными соединениями.
Также проверьте syslog операционной системы, потому что MySQL может быть убит из-за низкой памяти, который может быть исправлен установив лучшие значения в config.

Надеемся, что это поможет вам найти основную причину.

Ответ 2

Этот пример как-то груб, но, надеюсь, показывает логику вокруг обработки отключений. Специфика зависит от способа получения соединений в конкретной структуре.

В приведенном ниже коде предполагается использование retry; при необходимости вы можете использовать другую логику повтора.

Он также предполагает, что вы используете пул соединений с вашим приложением, предоставляемым инфраструктурой. Обычно вы можете попросить его повторно подключиться или, по крайней мере, закрыть незанятые соединения, чтобы другой запрос на соединение создавал новый.

def reconnect_on_failure(func):
    @retry(OperationalError, delay=0.25, backoff=1.5, max_delay=5)
    @wraps(func)
    def reconnecting_func(*args, **kwargs):
        try:
            return func(*args, **kwargs)
        except OperationalError as e:
            if 'connect' in e.msg.lower():
                force_reconnection_somehow()  # Look at your connection pool API.
                raise  # We want to retry on it
            raise Exception('Unhandled MySQL error', e)  # Will not retry.
    return reconnecting_func


@reconnect_on_failure
def something(...):
    connection = get_connecton_somehow()  # Look at the framework API.
    # A transaction implicitly begins with the first statement executed.
    cursor = connection.cursor()
    result = cursor.execute(...)  # do stuff
    connection.commit()

Вместо чрезмерно широкого Exception вы можете использовать более узкий класс, например. для вашего приложения; идея заключается в том, что повышение чего-либо, кроме OperationalError, не приведет к запуску повторных попыток, и оно немедленно поднимет Exception, чтобы сообщить о проблеме.

ИЗМЕНИТЬ из Grender: Я добавил @wraps decorator, чтобы избежать AssertionError как показано здесь.