Esto se toma casi al pie de la letra de mi respuesta aquí , pero sé que desaprobamos las respuestas de solo enlace en SO, así que imagino que ustedes también lo hacen :-)
Si tiene este problema y usa una versión de Windows anterior a Windows 7, probablemente esta no sea la respuesta a su problema.
¿Por qué está pasando esto?
La causa de este problema es IPv4 vs IPv6.
Cuando usa un nombre de host en lugar de una dirección IP, el cliente MySQL primero ejecuta una AAAA
búsqueda de host (IPv6) para el nombre, e intenta esta dirección primero si resuelve con éxito el nombre en una dirección IPv6. Si alguno de los pasos falla (resolución de nombre o conexión), recurrirá a IPv4, ejecutará una A
búsqueda e intentará este host en su lugar.
Lo que esto significa en la práctica es que si la localhost
búsqueda de IPv6 es exitosa pero MySQL no está vinculada al loopback de IPv6, deberá esperar un ciclo de tiempo de espera de conexión antes de que ocurra el repliegue de IPv4 y la conexión sea exitosa.
Esto no era un problema anterior a Windows 7, porque la localhost
resolución se realizó a través del archivo de hosts y solo estaba preconfigurada 127.0.0.1
; no venía con su contraparte IPv6 ::1
.
Sin embargo, desde Windows 7, la localhost
resolución está integrada en el solucionador de DNS, por las razones descritas aquí . Esto significa que la búsqueda de IPv6 ahora tendrá éxito, pero MySQL no está vinculado a esa dirección IPv6, por lo que la conexión fallará y verá el retraso descrito en esta pregunta.
Eso es bueno. ¡Solo dime cómo solucionarlo ya!
Tienes pocas opciones. Al mirar alrededor de Internet, la "solución" general parece ser usar la dirección IP explícitamente en lugar del nombre, pero hay un par de razones para no hacerlo, ambas relacionadas con la portabilidad, ambas posiblemente no importantes:
Si mueve su script a otra máquina que solo admite IPv6, su script ya no funcionará.
Si mueve su script a un entorno de alojamiento basado en * nix, la cadena mágica localhost
significaría que el cliente MySQL preferiría usar un socket Unix si está configurado, esto es más eficiente que la conectividad basada en IP loopback
¿Suenan bastante importantes?
No lo son Debería diseñar su aplicación para que este tipo de cosas se defina en un archivo de configuración. Si mueve su script a otro entorno, es probable que también sea necesario configurar otras cosas.
En resumen, el uso de la dirección IP no es la mejor solución, pero lo más probable es que sea una solución aceptable.
Entonces, ¿cuál es la mejor solución?
La mejor manera sería cambiar la dirección de enlace que utiliza el servidor MySQL. Sin embargo, esto no es tan simple como a uno le gustaría. A diferencia de Apache, Nginx y casi cualquier otra aplicación de servicio de red sensata que se haya creado, MySQL solo admite una única dirección de enlace, por lo que no se trata solo de agregar otra. Afortunadamente, los sistemas operativos admiten un poco de magia aquí, por lo que podemos habilitar MySQL para usar tanto IPv4 como IPv6 simultáneamente.
Debe ejecutar MySQL 5.5.3 o posterior, y debe iniciar MySQL con el --bind-address=
argumento de la línea de comandos. Tienes 4 opciones de documentos , dependiendo de lo que quieras hacer:
La que probablemente está familiarizado con, y el que lo más probable es (efectivamente) usando, 0.0.0.0
. Esto se une a todas las direcciones IPv4 disponibles en la máquina. Probablemente, esto no sea lo mejor, incluso si no le importa IPv6, ya que sufre los mismos riesgos de seguridad ::
.
Una dirección IPv4 o IPv6 explícita (por ejemplo, 127.0.0.1
o ::1
para loopback). Esto une el servidor a esa dirección y solo a esa dirección.
La cuerda mágica ::
. Esto vinculará MySQL a cada dirección de la máquina, tanto las direcciones de interfaz física como de bucle invertido, en modo IPv4 e IPv6. Esto es potencialmente un riesgo de seguridad, solo haga esto si necesita que MySQL acepte conexiones de hosts remotos.
Use una dirección IPv6 asignada a IPv4 . Este es un mecanismo especial integrado en IPv6 para la compatibilidad con versiones anteriores durante la transición 4 -> 6, y le permite vincularse a una dirección IPv4 específica y es equivalente a IPv6. Es poco probable que esto le sea útil para otra cosa que no sea la dirección de "doble loopback" ::ffff:127.0.0.1
. Esta es probablemente la mejor solución para la mayoría de las personas, ya que solo se vincula al loopback pero permite conexiones IPv4 e IPv6.
¿Necesito modificar el archivo de hosts?
NO . No modifique el archivo de hosts. El solucionador de DNS sabe qué hacer localhost
, redefinirlo en el mejor de los casos no tendrá ningún efecto y, en el peor de los casos, confundirá al resolutor.
¿Qué hay de --skip-name-resolve
?
Esto también puede solucionar el problema, por una razón relacionada pero ligeramente diferente.
Sin esta opción de configuración, MySQL intentará resolver todas las direcciones IP de conexión del cliente a un nombre de host mediante una PTR
consulta DNS. Si su servidor MySQL ya está habilitado para usar IPv6 pero las conexiones aún están tardando mucho, puede ser porque el PTR
registro DNS ( ) inverso no está configurado correctamente.
Deshabilitar la resolución de nombre solucionará este problema, pero tiene otras ramificaciones, en particular que cualquier permiso de acceso configurado para usar un nombre DNS en la Host
condición ahora fallará.
Si va a hacer esto, deberá configurar todas sus concesiones para usar direcciones IP en lugar de nombres.