# 2013 - Потерянное соединение с сервером MySQL во время запроса [дубликат]

Это происходило со мной с mariadb, потому что я сделал столбец varchar(255) a unique key .. Угадайте, что это слишком тяжело для уникального, так как вставка была отключена.

Я столкнулся с той же проблемой. Из-за некоторых других проблем я попытался добавить строку cnx.close() к моим другим функциям. Вместо этого я удалил все эти посторонние замыкания и установил свой класс следующим образом:

class DBase:

config = {
      'user': 'root',
      'password': '',
      'host': '127.0.0.1',
      'database': 'bio',
      'raise_on_warnings': True,
      'use_pure': False,
      }

def __init__(self):
    import mysql.connector
    self.cnx = mysql.connector.connect(**self.config)
    self.cur = self.cnx.cursor(buffered=True)
    print(self.cnx)
def __enter__(self):
    return DBase()

def __exit__(self, exc_type, exc_val, exc_tb):
    self.cnx.commit()
    if self.cnx:
        self.cnx.close()

Любая функция, вызываемая в этом классе, соединяет, фиксирует и закрывает.

Многопроцессорность и Django DB не работают хорошо.

Я закончил закрытие соединения Django DB первым в новом процессе.

Так что у вас не будет ссылок на соединение, используемое родителем.

from multiprocessing import Pool

multi_core_arg = [[1,2,3], [4,5,6], [7,8,9]]
n_cpu = 4
pool = Pool(n_cpu)
pool.map(_etl_, multi_core_arg)
pool.close()
pool.join()

def _etl_(x):
    from django.db import connection 
    connection.close() 
    print(x)

ИЛИ

Process.start() вызывает функцию, которая начинается с

Некоторые другие предлагают использовать

from multiprocessing.dummy import Pool as ThreadPool

It решена моя проблема (2013, потерянное соединение), но поток использует GIL при выполнении ввода-вывода, чтобы освободить его при завершении ввода-вывода.

Сравнительно, Process порождает группу работников, которые обмениваются друг с другом, что может быть медленнее.

Я рекомендую вам время. Боковые подсказки - использовать joblib , который поддерживается проектом scikit-learn. некоторые результаты производительности показывают, что он выполняет собственный пул () .. хотя он оставляет ответственность за кодер, чтобы проверить истинную стоимость времени выполнения.

Существует три способа увеличить max_allowed_packet сервера mysql:

1. Измените max_allowed_packet=64M в файле /etc/mysql/my.cnf на машине сервера mysql и перезапустите сервер
2. Выполните sql на сервере mysql: set global max_allowed_packet=67108864;
3. Python выполняет sql после подключения к mysql:

connection.execute ('set max_allowed_packet = 67108864 ')

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

В моем случае причина для

ERROR 2013 (HY000): Потерянное соединение с сервером MySQL во время запроса

было в том, что части моего стол был поврежден. Я также не смог mysqldump мой стол, потому что некоторые строки сломали его. Ошибка не связана с проблемами памяти и т. Д., Как указано выше.

Хорошо, что MySQL вернул мне номер строки, который был первым, что не удалось. Это было что-то вроде

mysqldump: Ошибка 2013: Потерянное соединение с сервером MySQL во время запроса при сбрасывании таблицы mytable в строке: 12723

Решение заключалось в копировании данные в новую таблицу. В моем случае я потерял 10 строк данных, потому что мне пришлось пропустить эти поврежденные строки. Сначала я создал таблицу «tmp» со схемой старого. SHOW CREATE TABLE - ваш друг здесь. Например,

SHOW CREATE TABLE mydatabase.mytable;

Когда я создал новую таблицу. Назовем его mytabletmp . Затем скопируйте строки, которые вы можете скопировать, например,

insert into mysqltabletmp select * from mytable where id < 12723;
insert into mysqltabletmp select * from mytable where id > 12733;

. После этой старой таблицы переименуйте tmp-таблицу в имя старой таблицы.

Также есть некоторая приятная информация от Peter относительно этой проблемы.

Перед подключением убедитесь, что вы закрыли курсор. Я решил проблему с этим:

if cur and con:                        
    cur.close() 
    con.close() 

Вам нужно увеличить таймаут в вашем соединении. Если вы не можете или не хотите делать это по какой-либо причине, вы можете попробовать позвонить:

data = db.query(sql).store_result()

Это приведет к немедленному отображению всех результатов, тогда ваше соединение не будет выходить за полпути через итерации по ним.

В документах mysql есть целая страница, посвященная этой ошибке: http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

примечания

• Вы также можете получить эти ошибки, если вы отправляете запрос на сервер, который является неправильным или слишком большим. Если mysqld получает слишком большой или неправильный пакет, он предполагает, что что-то пошло не так с клиентом и закрывает соединение. Если вам нужны большие запросы (например, если вы работаете с большими столбцами BLOB), вы можете увеличить лимит запроса, установив переменную max_allowed_packet сервера, которая имеет значение по умолчанию 1 МБ. Вам также может потребоваться увеличить максимальный размер пакета на стороне клиента. Дополнительная информация об установке размера пакета приведена в разделе B.5.2.10 «Слишком большой пакет».
• Вы можете получить дополнительную информацию о потерянных соединениях, запустив mysqld с помощью -log-warnings = 2. Это регистрирует некоторые из отключенных ошибок в файле hostname.err

Установите для параметра 'max_allowed_packet' значение 64M и перезапустите ваш сервер MySql. Если это не устранило ваши проблемы, проблема может быть в другом месте.

У меня многопоточное приложение PHP CLI, которое выполняет одновременные запросы, и я недавно заметил эту проблему. Теперь мне очевидно, что сервер MySql рассматривает все подключения с одного и того же IP-адреса как «одно» и, следовательно, отбрасывает все соединения всякий раз, когда заканчивается один запрос.

Интересно, однако, что есть способ сделать MySql позвольте сказать 100 подключений от одного и того же IP-адреса и рассмотреть каждое соединение как индивидуальное соединение.

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

Это происходит со мной, когда мое имя CONSTRAINT имеет то же имя с другим именем CONSTRAINT.

Изменение имени CONSTRAINT решило это.

очень просто решить, перейдите на панель управления phpadmin и нажмите на config / затем отредактируйте файл .ini, который вы видите. найдите порт 3306, если это не тот порт, который вы используете для вашего соединения, измените 3306 на порт, который вы используете. на вашем экране входа в систему просто поместите локальный хост для вашего сервера, ваш порт, если он не по умолчанию, или если вы не изменили имя файла my.ini в sql-конфигурации leavit как есть. затем введите свое имя пользователя: root или тот, который вы создали, затем пароль: 1234 или тот, который вы назначили. если вы подключаетесь локально, не проверяйте параметр url. затем введите имя базы данных, которую вы хотите отредактировать. Примечание. После подключения вы увидите список баз данных, которые у вас есть на сервере или сервере, к которому вы подключаетесь.

В моем случае я столкнулся с этой проблемой при поиске дампа SQL, который поместил таблицы в неправильном порядке. В вопросе CREATE включен CONSTRAINT ... ССЫЛКИ, которые ссылаются на таблицу, которая еще не была создана.

Я нашел эту таблицу и переместил ее инструкцию CREATE выше оскорбительной, и ошибка исчез.

Другая ошибка, с которой я столкнулся в этой неисправной дампе, была ERROR 1005 / errno: 150 - «Невозможно создать таблицу», опять же вопрос о создании таблиц не в порядке.

Я тоже сталкивался с подобными проблемами. В моем случае это было решено, получив курсор таким образом:

cursor = self.conn.cursor(buffered=True)

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

Вилки могут поразить вас. Остерегайтесь не в этом случае.