python - ejemplos - Se perdió la conexión con el servidor MySQL durante la consulta

consultas en elasticsearch

Question

Tengo una gran mesa y necesito procesar todas las filas en ella. Siempre recibo este mensaje de conexión perdida y no puedo volver a conectar y restaurar el cursor a la última posición que tenía. Este es básicamente el código que tengo aquí:

#
import MySQLdb

class DB:
  conn = None

  def connect(self):
    self.conn = MySQLdb.connect(''hostname'', ''user'', ''*****'', ''some_table'', cursorclass=MySQLdb.cursors.SSCursor)

  def query(self, sql):
    try:
     cursor = self.conn.cursor()
     cursor.execute(sql)
   except (AttributeError, MySQLdb.OperationalError):
     self.connect()
     cursor = self.conn.cursor()
     cursor.execute(sql)
   return cursor
#

#
db = DB()
sql = "SELECT bla FROM foo"
data = db.query(sql)

for row in data:
    do_something(row)
#

Pero siempre obtengo esto:

#
Traceback (most recent call last):
  File "teste.py", line 124, in <module>
   run()
 File "teste.py", line 109, in run
   for row in data:
 File "/usr/lib64/python2.5/site-packages/MySQLdb/cursors.py", line 417, in next
   row = self.fetchone()
 File "/usr/lib64/python2.5/site-packages/MySQLdb/cursors.py", line 388, in fetchone
   r = self._fetch_row(1)
 File "/usr/lib64/python2.5/site-packages/MySQLdb/cursors.py", line 285, in _fetch_row
   return self._result.fetch_row(size, self._fetch_type)
   _mysql_exceptions.OperationalError: (2013, ''Lost connection to MySQL server during query'')
    Exception _mysql_exceptions.OperationalError: (2013, ''Lost connection to MySQL server during query'') in <bound method SSCursor.__del__ of <MySQLdb.cursors.SSCursor object at 0x7f7e3c8da410>> ignored
#

¿Tiene alguna idea?

Answer 1

También puede encontrar este error con aplicaciones que bifurcan procesos secundarios, todos los cuales intentan usar la misma conexión al servidor MySQL. Esto se puede evitar usando una conexión separada para cada proceso hijo.

Forks podría golpearte. Sin embargo, ten cuidado no en este caso.

Answer 2

Asegúrese de cerrar el cursor antes de la conexión. Resolví mi problema con esto:

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

Answer 3

El multiprocesamiento y Django DB no funcionan bien juntos.

Terminé cerrando la conexión Django DB a primera vista en el nuevo proceso.

Entonces, ese no tendrá referencias a la conexión utilizada por el padre.

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)

O

Process.start() llama a una función que comienza con

Algunos otros sugieren usar

from multiprocessing.dummy import Pool as ThreadPool

Resolvió mi problema (2013, Conexión perdida), pero el uso de subprocesos GIL, al hacer IO, lo liberará cuando termine IO.

Comparativamente, Process genera un grupo de trabajadores que se comunican entre sí, lo que puede ser más lento.

Te recomiendo que tengas tiempo. Un consejo es usar joblib que está respaldado por el proyecto scikit-learn. algunos resultados de rendimiento muestran que realiza el Pool nativo () .. aunque deja la responsabilidad al codificador para verificar el verdadero costo del tiempo de ejecución.

Answer 4

En mi caso, me encontré con este problema al obtener un volcado de SQL que había colocado las tablas en el orden incorrecto. El CREATE en cuestión incluía una RESTRICCIÓN ... REFERENCIAS que hacía referencia a una tabla que aún no se había creado.

Localicé la tabla en cuestión, y moví su declaración CREATE al anterior, y el error desapareció.

El otro error que encontré relacionado con este volcado defectuoso fue ERROR 1005 / errno: 150 - "No se puede crear la tabla", una vez más una cuestión de tablas que se están creando fuera de servicio.

Answer 5

Encontré problemas similares también. En mi caso, se resolvió tomando el cursor de esta manera:

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

Answer 6

Establezca la configuración ''max_allowed_packet'' en 64M y reinicie su servidor MySql. Si eso no solucionó sus problemas, el problema puede estar en otra parte.

Tengo una aplicación de CLI PHP multiproceso que hace consultas simultáneas y recientemente me di cuenta de este problema. Ahora es obvio para mí que el servidor MySql considera todas las conexiones desde la misma IP como una conexión ''única'' y, por lo tanto, descarta todas las conexiones cada vez que finaliza una única consulta.

Sin embargo, me pregunto si existe alguna manera de hacer que MySql permita decir 100 conexiones desde la misma IP y considerar cada conexión como una conexión individual.

Answer 7

Esto me CONSTRAINT cuando mi nombre CONSTRAINT tenía el mismo nombre con otro nombre CONSTRAINT .

Cambiar mi nombre CONSTRAINT solucionó esto.

Answer 8

Esto me estaba sucediendo con mariadb porque hice que una columna varchar(255) una unique key ... supongo que es demasiado pesada para una única, ya que el inserto se estaba agotando.

Answer 9

Esto me sucedió cuando intenté actualizar una tabla cuyo tamaño en el disco era más grande que el espacio disponible en el disco. La solución para mí fue simplemente aumentar el espacio disponible en el disco.

Answer 10

Esto también puede suceder si alguien o algo mata su conexión usando el comando KILL .

Answer 11

Hay tres formas de aumentar el max_allowed_packet del servidor mysql:

1. Cambie max_allowed_packet=64M en el archivo /etc/mysql/my.cnf en la máquina del servidor mysql y reinicie el servidor
2. Ejecute sql en el servidor mysql: set global max_allowed_packet=67108864;
3. Python ejecuta sql luego de conectarse a mysql:

connection.execute (''set max_allowed_packet = 67108864'')

Answer 12

Los documentos de mysql tienen toda una página dedicada a este error: http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

de nota son

• También puede obtener estos errores si envía una consulta al servidor que es incorrecta o demasiado grande. Si mysqld recibe un paquete que es demasiado grande o está fuera de servicio, asume que algo ha ido mal con el cliente y cierra la conexión. Si necesita grandes consultas (por ejemplo, si está trabajando con grandes columnas BLOB), puede aumentar el límite de consultas configurando la variable max_allowed_packet del servidor, que tiene un valor predeterminado de 1 MB. Es posible que también necesite aumentar el tamaño máximo de paquete en el extremo del cliente. Se proporciona más información sobre cómo configurar el tamaño del paquete en la Sección B.5.2.10, "Paquete demasiado grande".

• Puede obtener más información sobre las conexiones perdidas iniciando mysqld con la opción --log-warnings = 2. Esto registra algunos de los errores desconectados en el archivo hostname.err

Answer 13

Me estaba encontrando con el mismo problema. Debido a algunos otros problemas, intenté agregar una línea cnx.close() a mis otras funciones. En cambio, eliminé todos estos cierres extraños y configuré mi clase así:

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()

Cualquier función que se llama dentro de esta clase se conecta, confirma y cierra.

Answer 14

Necesita aumentar el tiempo de espera en su conexión. Si no puede o no quiere hacer eso por alguna razón, puede intentar llamar:

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

Esto obtendrá todos los resultados de inmediato, luego su conexión no tendrá tiempo de espera hasta la mitad de iterar sobre ellos.

Answer 15

Yo mi caso, el motivo de la

ERROR 2013 (HY000): Conexión perdida al servidor MySQL durante la consulta

error fue que partes de mi tabla estaban dañadas . Tampoco pude mysqldump mi tabla porque algunas filas la rompieron. El error no estaba relacionado con ningún problema de memoria, etc., como se mencionó anteriormente.

Lo bueno fue que MySQL me devolvió el número de fila, que fue el primero que falló. Fue algo así como

mysqldump: Error 2013: perdió la conexión con el servidor MySQL durante la consulta al volcar la tabla mytable en la fila: 12723

La solución fue copiar los datos en una nueva tabla. En mi caso, perdí 10 filas de datos porque tuve que omitir estas filas dañadas. Primero creé una tabla "tmp" con el esquema del anterior. SHOW CREATE TABLE es tu amigo aquí. P.ej

SHOW CREATE TABLE mydatabase.mytable;

Con el yo creé la nueva tabla. Vamos a llamarlo mytabletmp . Y luego copie las filas que puede copiar, por ejemplo

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

Después de soltar la tabla anterior, cambie el nombre de tmp-table al nombre de la tabla anterior.

También hay información interesante de Peter sobre este problema.