|
Recientemente, se encontró un servidor MySQL debido a algunos factores especiales“ERROR 1129 (00000): El host 'xxx' está bloqueado debido a muchos errores de conexión. Desbloquear con 'mysqladmin flush-hosts'”Después de resolver el problema, en el proceso de aprender más sobre el max_connect_errors de parámetros, algunas descripciones contradictorias de diferentes datos de red me confundieron un poco (sobre este error, la razón esencial es que la misma IP generó demasiadas conexiones de base de datos interrumpidas (superando el valor máximo de max_connect_errors) en un corto periodo de tiempo, y lo siguiente es un proceso de explorar mis problemas, analizarlos y aclarar dudas. Primero, busqué información en Internet, muchas de las cuales juran introducir que si el número de intentos de entrada de contraseña supera max_connect_errors variables, MySQL bloqueará este inicio de sesión del cliente, y luego encontré la información oficial sobre la introducción de max_connect_errors, como se muestra a continuación, MySQL 5.6/5.7 es la misma Si se interrumpen más de tantas solicitudes de conexión sucesivas de un host sin una conexión exitosa, el servidor bloquea a ese host para que no puedan seguir conectando. Puedes desbloquear hosts bloqueados vaciando la caché de hosts. Para ello, emite una instrucción FLUSH HOSTS o ejecuta un comando mysqladmin flush-hosts. Si una conexión se establece con éxito en menos de max_connect_errors intentos después de que una conexión anterior haya sido interrumpida, el recuento de errores para el host se elimina a cero. Sin embargo, una vez que un host está bloqueado, vaciar la caché del host es la única forma de desbloquearlo. El valor por defecto es 100. Como se muestra arriba, la traducción es aproximadamente la siguiente: si el servidor MySQL recibe solicitudes consecutivas del mismo host, y todas estas solicitudes consecutivas se interrumpen sin establecer con éxito una conexión, cuando el valor acumulado de estas solicitudes consecutivas es mayor que el valor max_connect_errors establecido, el servidor MySQL bloqueará todas las solicitudes posteriores desde este host. Creo que cuando veas esta información al principio, también serás atacado“Muchas solicitudes de conexión sucesivas de un host se interrumpen sin una conexión exitosa”Confuso, de hecho, esto se debe a que la conexión a la base de datos se interrumpe debido a anomalías en la red. Busqué información así en Internet: Parece que hay confusión con esa variable. No bloquea realmente los hosts por contraseñas inválidas repetidas, sino por conexiones abortadas debido a errores de red. Entonces podemos experimentar y verificarlo nosotros mismos para descubrir cuál es la correcta. Crea una cuenta de prueba en la base de datos MySQL y luego establecemos la variable max_connect_errors como3. Luego usamos otra máquina de prueba para conectarnos a la base de datos MySQL con la contraseña incorrecta, como se muestra a continuación, incluso si se introducen las tres contraseñas incorrectas anteriores, la cuarta entrada no detecta el error anterior.Entonces puedes descartar que esta variable tenga que ver con la entrada de contraseña incorrecta. [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Introduce la contraseña: ERROR 1045 (28000): Acceso denegado para el usuario 'test'@'mytestlnx02' (usando contraseña: SÍ) [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Introduce la contraseña: ERROR 1045 (28000): Acceso denegado para el usuario 'test'@'mytestlnx02' (usando contraseña: SÍ) [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Introduce la contraseña: ERROR 1045 (28000): Acceso denegado para el usuario 'test'@'mytestlnx02' (usando contraseña: SÍ) [root@mytestlnx02 TMP]# mysql -h10.20.57.24 -utest -p Introduce la contraseña: ERROR 1045 (28000): Acceso denegado para el usuario 'test'@'mytestlnx02' (usando contraseña: SÍ) [root@mytestlnx02 tmp] # De hecho, si una IP introduce una contraseña incorrecta, MySQL la registrará en la tabla host_cache bajo la base de datos performance_schema. Se registra de forma acumulativa en COUNT_AUTHENTICATION_ERRORS campos de la siguiente manera:
Según la información oficial, el campo host_cache se considera estadísticamente como“Obstrucción”de errores de conexión (evaluados en función de max_connect_errors variables del sistema). Solo se cuentan los errores de handshake de protocolo y solo se utilizan para hosts autenticados (HOST_VALIDATED = SÍ). SUM_CONNECT_ERRORS El número de errores de conexión que se consideran "bloqueantes" (evaluados en función de lamax_connect_errorsvariable del sistema). Solo se cuentan los errores de handshake de protocolo, y solo para los hosts que han pasado la validación (HOST_VALIDATED = SÍ). MySQLEl cliente necesita iniciar un protocolo de apretón de manos de tres tiempos para establecer una conexión con la base de datos; en circunstancias normales, este tiempo es muy corto, pero una vez que aparecen la anomalía de red, el tiempo de espera y otros factores, hará que el protocolo de apretón de manos no pueda completarse, MySQL tiene un parámetro connect_timeout, es el momento en que el servidor MySQL procesa MySQL para esperar a que se establezca la conexión, en segundos. Si el protocolo de protocolo aún no se completa tras el connect_timeout plazo, el cliente MySQL recibirá una excepción con un mensaje de excepción similar a: Pérdida de conexión al servidor MySQL en 'XXX', error del sistema: errno, la variable por defecto es 10 segundos:
Construyamos un caso en el que la conexión a la base de datos se interrumpe debido a un tiempo de espera de red; usamos los comandos netem y tc en Linux para simular el caso de retardo de transmisión de red en un entorno complejo; tras los siguientes ajustes, en este momento desde el servidor de prueba para acceder al servidor MySQL, habrá un retraso de 11 segundos: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes de datos. 64 bytes desde 10.20.57.24: icmp_seq=1 TTL=62 tiempo=0,251 ms 64 bytes desde 10.20.57.24: icmp_seq=2 TTL=62 tiempo=0,330 ms 64 bytes desde 10.20.57.24: icmp_seq=3 TTL=62 tiempo=0,362 ms 64 bytes desde 10.20.57.24: icmp_seq=4 TTL=62 tiempo=0,316 ms 64 bytes desde 10.20.57.24: icmp_seq=5 TTL=62 tiempo=0,281 ms 64 bytes desde 10.20.57.24: icmp_seq=6 TTL=62 tiempo=0,377 ms ^C --- 20.10.57.24 Estadísticas de ping --- 6 paquetes transmitidos, 6 recibidos, 0% de pérdida de paquetes, tiempo 5716ms RTT min/avg/max/mdev = 0,251/0,319/0,377/0,047 ms [root@gettestlnx02 ~]# tc qdisc add dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes de datos. 64 bytes desde 10.20.57.24: icmp_seq=1 TTL=62 tiempo=11000 ms 64 bytes desde 10.20.57.24: icmp_seq=2 ttl=62 tiempo=11000 ms 64 bytes desde 10.20.57.24: icmp_seq=3 TTL=62 tiempo=11000 ms 64 bytes desde 10.20.57.24: icmp_seq=4 TTL=62 tiempo=11000 ms 64 bytes desde 10.20.57.24: icmp_seq=5 TTL=62 tiempo=11000 ms 64 bytes desde 10.20.57.24: icmp_seq=6 TTL=62 tiempo=11000 ms 64 bytes desde 10.20.57.24: icmp_seq=7 TTL=62 tiempo=11000 ms
Nos conectamos a la base de datos MySQL en el servidor de pruebas gettestlnx02 como se muestra a continuación (ten en cuenta que si te conectas a este servidor vía ssh, será bastante lento de operar en gettestlnx02 en este momento). Por supuesto, también puedes simular la latencia de red en el servidor MySQL, o puedes reducir tanto la latencia connect_timeout como la de red) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Introduce la contraseña: ERROR 2013 (HY000): Pérdida de conexión al servidor MySQL al 'leer paquete de autorización', error del sistema: 0 [root@gettestlnx02 ~] # Como se muestra arriba, debido al retraso de red de más de 10 segundos, la conexión a MySQL falló; en ese momento, cuando consultas la tabla host_cache en el servidor MySQL, verás que la SUM_CONNECT_ERRORS se ha convertido en 1 y la COUNT_HANDSHAKE_ERRORS también ha cambiado1.
Luego lanzamos así tres veces repetidamente, y verás que el SUM_CONNECT_ERRORS se convierte en 3 y el COUNT_HANDSHAKE_ERRORS en 3. Luego usamos comandos netem y tc para cancelar la simulación de latencia de red en el servidor de prueba, y después pasamos a la conexión de prueba a la base de datos MySQL, como se muestra en la siguiente prueba: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Introduce la contraseña: ERROR 1129 (HY000): El host '192.168.27.180' está bloqueado debido a numerosos errores de conexión; desbloquear con 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
En este momento, puede construirse“ERROR 1129 (HY000): El host '192.168.27.180' está bloqueado debido a numerosos errores de conexión; desbloquear con 'mysqladmin flush-hosts'”Incorrecto. solución ERROR 1129 resuelto (00000): El host 'xxx' está bloqueado debido a numerosos errores de conexión. Hay muchas formas de obtener el error Unblock con 'mysqladmin flush-hosts', pero algunas son temporales. El plan temporal es que los indicadores no aborden la causa raíz. La clave es corregir errores de red (que a menudo requieren consultar a administradores de red o de sistema) Solución alternativa: 1, fija el valor de la variable max_connection_errors a un valor mayor
Esta solución temporal es solo una condición de disparo por retraso para prohibir la IP, y en casos complejos o de alta concurrencia, es necesario establecer un valor alto, de lo contrario se activará fácilmente de nuevo. Además, las variables solo se aplican en el entorno actual y expiran si se reinician. 2: usoHospedadores al ras Mysql> anfitriones flush; Consulta OK, 0 filas afectadas (0,00 seg) mysql> seleccione * de performance_schema.host_cache; Juego vacío (0,00 seg) Mysql> Por supuesto, también puedes usar el comando mysqladmin flush-hosts para limpiar la información de caché del host [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Introduce la contraseña: ¿Entonces, qué es la caché de host? La introducción oficial es la siguiente: El servidor MySQL mantiene una caché de host en memoria que contiene información sobre los clientes: dirección IP, nombre del host e información de errores. El servidor utiliza esta caché para conexiones TCP no locales. No utiliza la caché para conexiones TCP establecidas mediante una dirección de interfaz loopback (127.0.0.1 o ::1), ni para conexiones establecidas mediante un archivo socket Unix, tubería llamada o compartida memoria. En términos sencillos, el servidor MySQL mantiene una caché en memoria que contiene información del cliente: dirección IP, nombre de host, mensaje de error, etc. El servidor almacena en caché la información de conexión TCP no local. No almacena en caché las conexiones TCP realizadas usando direcciones de interfaz de bucle (127.0.0.1 o::1), ni las conexiones realizadas mediante archivos de socket Unix, pipelines con nombre o memoria compartida. La información de la caché del host puede consultarse a través de la tabla host_cache en la base de datos performance_schema. 3: Establezca la variable host_cache_size a0 De hecho, diría que esta es la solución menos fiable, simplemente para que el servidor MySQL no registre la información de la caché del host. Este método puede ignorarse por completo.
| 
Publicado en 8/4/2019 11:01:48
|
|
|
|
