2016-11-17 3 views
6

Я использую SQLAlchemy с двумя базами данных MySQL. Одна из них - моя база данных разработки, размещенная локально на моей машине, а другая - сервер MySQL, предоставляемый ClearDB на Heroku для производства.Диагностика 2013 Потерянное соединение с MySQL

У меня есть длинный сеанс работы с базой данных, когда он выполняет операцию синхронизации с другой службой. На моей локальной машине это заканчивается нормально, но на производстве я получаю ошибку (2013, «Потерянное соединение с сервером MySQL во время запроса»).

Я читал другие сообщения, которые говорят, что это может быть либо размер запроса слишком большой, либо переменная обновления пула, которую необходимо отрегулировать. Я не считаю, что полезная нагрузка транзакции относительно велика и установка переменной pool_recycle при вызове SQLAlachemy create_engine, похоже, не работала.

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

Как было предложено в комментариях, обе системы возвращают те же значения для select @@interactive_timeout, @@wait_timeout: 28800, 28800.

Благодаря

+1

Просьба исправить этот SQL-запрос как для вашей базы данных разработчиков, так и для производственной базы данных. 'select @@ interactive_timeout, @@ wait_timeout'. Пожалуйста, отредактируйте свой вопрос, чтобы рассказать нам, какие значения у вас есть в ваших двух базах данных. Иногда производственные базы данных имеют более короткие таймауты, чем базы данных разработчиков. –

+0

А я действительно хотел включить эти цифры, когда начал публиковать это ... но забыл. Я обновил свой вопрос. Спасибо @ O.Jones – freebie

+0

Вы выбрали переменные в интерактивном сеансе клиента? Если это так, вам нужно сделать 'SELECT @@ global.interactive_timeout, @@ global.wait_timeout'. В интерактивном сеансе «wait_timeout» уровня сеанса настраивается на «интерактивный тайм-аут», поэтому он бесполезен. – elenst

ответ

2

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

ClearDB отслеживает соединения и убивает их, когда они открыты более минуты. Первоначально я не смог найти это docuemnted.

Исправление было фактически установкой параметра pool_recycle на pool_recycle=60 при создании двигателя. Моя предыдущая попытка этого я использовал произвольное число (потому что я не знал тайм-аута ClearDB) выше этого.

 Смежные вопросы

  • Нет связанных вопросов^_^