solucionar - mysql no inicia windows 10
ERROR 2013(HY000): se perdió la conexión con el servidor MySQL en el ''paquete de autorización de lectura'', error del sistema: 0 (8)
Estoy teniendo el siguiente error
ERROR 2013 (HY000): Lost connection to MySQL server at
''reading authorization packet'', system error: 0
al intentar conectar a mi servidor MySQL.
Qué estoy haciendo:
- Tengo una replicación Master - Slave en MySQL que funciona y solo agregué capacidades de equilibrio de carga usando F5.
- He configurado el F5 de acuerdo a su sitio.
Pero cuando intento conectarme a mi servidor MySQL usando la IP con la que se configuró el F5, obtengo
ERROR 2013 (HY000): Lost connection to MySQL server at
''reading authorization packet'', system error: 0
¿Algunas ideas?
Actualización sobre mi progreso: CERO
- Recibo el mismo error. No obtengo entradas en / var / log / secure como si alguien intentara autenticar desde la dirección IP donde había creado mi servidor de equilibrio de carga.
No hay enties en el registro de errores de mysql.
El comando - no devuelve nada
mysql> SHOW GLOBAL STATUS LIKE ''Aborted_connections'';
Empty set (0.00 sec)
Ya he modificado mi archivo my.cnf y my.cnf el
[mysqld]
skip-name-resolve
Cambie el tiempo de conexión a 10.
Así que parece que no obtengo respuesta para el servidor que he creado en mi F5
Finalmente convencí al administrador de F5 para que me pasara el registro del servidor F5 y extraje todo lo que necesito para formarlo.
Aquí está la salida:
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside initial connection
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside responding with server WELCOME packet
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- clientside authenticated flag not set
Jan 28 15:46:39 tmm err tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- mysql client: attempting to do something before authentication
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <LB_SELECTED>: BIG-IP MySQL Proxy -- serverside selected pool /Common/foss-mysql-slave_pool node SLAVE-IP
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_CLOSED>: BIG-IP MySQL Proxy -- clientside connection closed from MASTER-IP(XXXXXXX)
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <SERVER_CLOSED>: BIG-IP MySQL Proxy -- serverside connection closed from node SLAVE-IP(XXXXXXXX)
¡He reemplazado la ip por razones de seguridad!
solo como extra - y creo que aquí está el problema - mi versión mysql es 5.1.69-log Thx All
En mi caso, sucedió cuando había mucha conexión con el servidor MySQL (15,000 conexiones) y la memoria libre era de aproximadamente 120M. Después de agregar más memoria al servidor, el error desapareció.
Esto generalmente es causado por una conexión abortada. Puedes verificar esto verificando el estado:
mysql> SHOW GLOBAL STATUS LIKE ''Aborted_connects'';
Si este contador sigue aumentando a medida que obtiene las conexiones perdidas, es una señal de que tiene un problema durante la conexión.
Un remedio que parece funcionar en muchos casos es aumentar el tiempo de espera. Un valor sugerido es de 10 segundos:
mysql> SET GLOBAL connect_timeout = 10;
Otra causa común de los tiempos de espera de conexión es la búsqueda de DNS inversa que es necesaria al autenticar clientes. Se recomienda ejecutar MySQL con la variable de configuración en my.cnf:
[mysqld]
skip-name-resolve
Esto significa que sus declaraciones GRANT deben basarse en la dirección IP en lugar del nombre de host.
También encontré este informe de 2012 en el sitio f5.com (ahora protegido por inicio de sesión, pero lo obtuve a través del caché de Google )
Es probable que el proxy no funcione a menos que esté ejecutando BIG-IP 11.1 y MySQL 5.1, que fueron las versiones con las que probé. El protocolo MySQL tiene la costumbre de cambiar.
Le sugiero que se ponga en contacto con el servicio de asistencia técnica de F5 y confirme que está utilizando una combinación de versiones compatible.
He luchado mucho con este error. Probé cada respuesta que encontré en internet.
Al final, conecté mi computadora al punto de acceso de mi teléfono celular y todo funcionó. Resultó que el internet de mi compañía estaba bloqueando la conexión con MySQL.
Esta no es una solución completa, pero tal vez alguien enfrenta el mismo problema. Vale la pena comprobar la conexión.
Mi caso fue que el servidor no aceptó la conexión de esta IP. El servidor es un servidor SQL de Google Apps Engine, y debe configurar los hosts remotos permitidos que pueden conectarse al servidor.
La adición del (nuevo) host a la página de administración de GAE solucionó el problema.
Otra posibilidad puede ser restablecer la conexión desde las envolturas TCP (/etc/hosts.deny y /etc/hosts.allow). Solo verifique lo que viene desde el telnet al puerto 3306: si no es nada, entonces hay algo en el medio que impide que la comunicación ocurra.
Resolví esto parando mysql varias veces.
$ mysql.server stop
Shutting down MySQL
.. ERROR! The server quit without updating PID file (/usr/local/var/mysql/xxx.local.pid).
$ mysql.server stop
Shutting down MySQL
.. SUCCESS!
$ mysql.server stop
ERROR! MySQL server PID file could not be found! (note: this is good)
$ mysql.server start
Todo bien desde aquí. Sospecho que mysql se había iniciado más de una vez.
Utilizo varias conexiones mysql (conectando a diferentes conjuntos de bases de datos) en localhost.
Esto me sucedió después de que apagué mi computadora y mysql no se cerró correctamente. Después de iniciar mi máquina, pude conectarme con éxito a varias conexiones de db, excepto una (usé esto mucho antes de apagar mi máquina). De acuerdo con las instrucciones de este post, doblé connect_timeout pero no pude conectarme a esa conexión de base de datos.
Reinicié mi máquina y puedo conectarme con éxito ahora. Esto le ayudará a desbloquearse, pero sería genial si se puede solucionar sin reiniciar la máquina.
Otra preocupación es que: connection_timeout me pareció retrasar un problema relacionado pero recibí el error inmediatamente en localhost cuando no hay una red en la ecuación.
Más raramente, puede suceder cuando el cliente está intentando la conexión inicial con el servidor. En este caso, si su valor de connect_timeout se establece en solo unos segundos, puede resolver el problema incrementándolo a diez segundos, tal vez más si tiene una conexión muy larga o lenta. Puede determinar si está experimentando esta causa más infrecuente utilizando MOSTRAR ESTADO COMO "aborted_connections". Aumentará en uno por cada intento de conexión inicial que el servidor aborta. Puede ver "leer el paquete de autorización" como parte del mensaje de error; Si es así, eso también sugiere que esta es la solución que necesita.
Intente aumentar connect_timeout en su archivo my.cnf
Otro estilo:
MySQL: se perdió la conexión con el servidor MySQL al ''leer el paquete de comunicación inicial''
En algún momento, fue imposible para los clientes remotos conectarse al servidor MySQL.
El cliente (alguna aplicación en una plataforma de Windows) dio una descripción vaga, como la
Connection unexpectedly terminated.Al iniciar sesión de forma remota con el cliente MySQL, apareció el siguiente error:
ERROR 2013 (HY000): Lost connection to MySQL server at ''reading initial communication packet'', system error: 0
En FreeBSD esto sucede porque no se encontró ninguna coincidencia en /etc/hosts.allow. Agregando la siguiente línea antes de la línea que dice ALL:ALL soluciona esto:
mysqld: ALL: allow
En sistemas Unix que no sean FreeBSD, vale la pena revisar los archivos /etc/hosts.allow y /etc/hosts.deny. Si está restringiendo las conexiones, asegúrese de que esta línea esté en /etc/hosts.allow :
mysqld: ALL
o compruebe si el host se encuentra en /etc/hosts.deny.
En Arch Linux, se puede agregar una línea similar a /etc/hosts.allow :
mysqld: ALL