Solución:
A veces, si ve “OperationalError: (2006, ‘El servidor MySQL ha desaparecido’)”, es porque está emitiendo una consulta que es demasiado grande. Esto puede suceder, por ejemplo, si está almacenando sus sesiones en MySQL y está tratando de poner algo realmente grande en la sesión. Para solucionar el problema, debe aumentar el valor de la configuración max_allowed_packet en MySQL.
El valor predeterminado es 1048576.
Entonces, vea el valor actual para el predeterminado, ejecute el siguiente SQL:
select @@max_allowed_packet;
Para establecer temporalmente un nuevo valor, ejecute el siguiente SQL:
set global max_allowed_packet=10485760;
Para solucionar el problema de forma más permanente, cree un archivo /etc/my.cnf con al menos lo siguiente:
[mysqld]
max_allowed_packet = 16M
Después de editar /etc/my.cnf, deberá reiniciar MySQL o reiniciar su máquina si no sabe cómo.
Según la documentación de MySQL, su mensaje de error aparece cuando el cliente no puede enviar una pregunta al servidor, muy probablemente porque el servidor mismo ha cerrado la conexión. En el caso más común, el servidor cerrará una conexión inactiva después de un período (predeterminado) de 8 horas. Esto se puede configurar en el lado del servidor.
La documentación de MySQL brinda una serie de otras posibles causas que podría valer la pena investigar para ver si se ajustan a su situación.
Una alternativa a llamar connect() en cada función (que podría terminar creando innecesariamente nuevas conexiones) sería investigar usando el ping() método en el objeto de conexión; esto prueba la conexión con la opción de intentar una reconexión automática. Luché por encontrar documentación decente para el ping() método en línea, pero la respuesta a esta pregunta podría ayudar.
Tenga en cuenta que la reconexión automática puede ser peligrosa cuando se manejan transacciones, ya que parece que la reconexión provoca una reversión implícita (y parece ser la razón principal por la que la reconexión automática no es una característica de la implementación de MySQLdb).
Esto puede deberse a que las conexiones de base de datos se copian en sus subprocesos secundarios desde el subproceso principal. Enfrenté el mismo error al usar la biblioteca de multiprocesamiento de Python para generar diferentes procesos. Los objetos de conexión se copian entre procesos durante la bifurcación y conduce a MySQL OperationalErrors cuando se realizan llamadas a la base de datos en el subproceso secundario.
Aquí hay una buena referencia para resolver esto: multiprocesamiento de Django y conexiones de bases de datos