|
Récemment, un serveur MySQL a été rencontré pour des raisons particulières“ERREUR 1129 (00000) : L’hôte « xxx » est bloqué à cause de nombreuses erreurs de connexion. Débloquer avec 'mysqladmin flush-hosts'”Après la résolution du problème, en apprenant davantage sur le max_connect_errors de paramètres, certaines descriptions contradictoires de différentes données réseau m’ont un peu embrouillé (à propos de cette erreur, la raison essentielle est que la même IP a généré trop de connexions de base de données interrompues (dépassant la valeur maximale de max_connect_errors) en peu de temps, et ce qui suit est un processus d’exploration de mes problèmes, d’analyse et de clarification des doutes. Tout d’abord, j’ai cherché quelques informations sur Internet, dont beaucoup jurent d’introduire que si le nombre de tentatives de saisie de mot de passe dépasse max_connect_errors variables, MySQL bloquera cette connexion client, puis j’ai trouvé les informations officielles concernant l’introduction de max_connect_errors, comme montré ci-dessous, MySQL 5.6/5.7 est identique Si plus de ce nombre de requêtes de connexion successives d’un hôte sont interrompues sans connexion réussie, le serveur bloque cet hébergement pour toute nouvelle connexion. Vous pouvez débloquer les hôtes bloqués en vidant le cache hôte. Pour ce faire, émettez une instruction FLUSH HOSTS ou exécutez une commande mysqladmin flush-hosts. Si une connexion est établie avec succès en moins de max_connect_errors tentatives après une interruption précédente, le nombre d’erreurs pour l’hôte est effacé à zéro. Cependant, une fois qu’un hôte est bloqué, vider le cache hôte est la seule façon de le débloquer. Le taux par défaut est 100. Comme montré ci-dessus, la traduction est à peu près la suivante : si le serveur MySQL reçoit des requêtes consécutives du même hôte, et que toutes ces requêtes consécutives sont interrompues sans établir de connexion réussie, lorsque la valeur cumulative de ces requêtes consécutives est supérieure à la valeur de l’ensemble max_connect_errors, le serveur MySQL bloquera toutes les requêtes suivantes de cet hôte. Je crois que lorsque vous verrez ces informations au début, vous serez aussi attaqué“De nombreuses requêtes de connexion successives d’un hôte sont interrompues sans connexion réussie”Confus, en fait, c’est parce que la connexion à la base de données est interrompue à cause d’anomalies réseau. J’ai cherché ce genre d’informations sur Internet : Il semble y avoir de la confusion autour de cette variable. Il ne bloque pas vraiment les hôtes pour des mots de passe invalides répétés, mais pour des connexions interrompues dues à des erreurs réseau. Eh bien, alors nous pourrons expérimenter et vérifier nous-mêmes pour déterminer laquelle est la bonne. Créez un compte de test dans la base MySQL, puis nous définissons la variable max_connect_errors à3. Ensuite, nous utilisons une autre machine de test pour se connecter à la base de données MySQL avec le mauvais mot de passe, comme montré ci-dessous, même si les trois mots de passe précédents sont saisis, la quatrième entrée ne rencontre pas l’erreur ci-dessus.Vous pouvez alors exclure que cette variable a un lien avec la saisie du mauvais mot de passe. [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Saisissez le mot de passe : ERREUR 1045 (28000) : Accès refusé pour l’utilisateur 'test'@'mytestlnx02' (avec mot de passe : OUI) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Saisissez le mot de passe : ERREUR 1045 (28000) : Accès refusé pour l’utilisateur 'test'@'mytestlnx02' (avec mot de passe : OUI) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Saisissez le mot de passe : ERREUR 1045 (28000) : Accès refusé pour l’utilisateur 'test'@'mytestlnx02' (avec mot de passe : OUI) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Saisissez le mot de passe : ERREUR 1045 (28000) : Accès refusé pour l’utilisateur 'test'@'mytestlnx02' (avec mot de passe : OUI) [root@mytestlnx02 TMP] # En fait, si une IP entre un mot de passe incorrect, MySQL l’enregistrera dans la table host_cache sous la base de données performance_schema. Il est enregistré cumulativement dans COUNT_AUTHENTICATION_ERRORS champs comme suit :
Selon les informations officielles, le domaine host_cache est statistiquement considéré comme“Blocage”des erreurs de connexion (évaluées sur la base de max_connect_errors variables système). Seules les erreurs de poignée de main de protocole sont comptabilisées et sont utilisées uniquement pour les hôtes authentifiés (HOST_VALIDATED = OUI). SUM_CONNECT_ERRORS Le nombre d’erreurs de connexion considérées comme « bloquantes » (évaluées par rapport à lamax_connect_errorsvariable système). Seules les erreurs de poignée de main du protocole sont comptabilisées, et uniquement pour les hôtes ayant réussi la validation (HOST_VALIDATED = OUI). MySQLLe client doit initier un protocole de poignée de main à trois tentatives pour établir une connexion avec la base de données, dans des circonstances normales, ce temps est très court, mais dès que l’anomalie réseau, le délai d’expiration et d’autres facteurs apparaissent, cela empêchera le protocole de poignée de main de se terminer, MySQL a un paramètre connect_timeout, c’est le temps pour que le serveur MySQL traite mysqld en quelques secondes. Si la poignée de main du protocole n’est toujours pas terminée après la période connect_timeout, le client MySQL recevra une exception avec un message d’exception similaire à : Connexion perdue au serveur MySQL à 'XXX', erreur système : errno, la variable est par défaut à 10 secondes :
Construisons un cas où la connexion à la base de données est interrompue à cause d’un délai d’expiration réseau ; nous utilisons les commandes netem et tc sous Linux pour simuler le délai de transmission réseau dans un environnement complexe, après les paramètres suivants, à ce moment-là, du serveur de test pour accéder au serveur MySQL, il y aura un délai de 11 secondes : [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) octets de données. 64 octets à partir de 10.20.57.24 : icmp_seq=1 TTL=62 temps=0,251 ms 64 octets à partir de 10.20.57.24 : icmp_seq=2 TTL=62 temps=0,330 ms 64 octets à partir de 10.20.57.24 : icmp_seq=3 TTL=62 temps=0,362 ms 64 octets à partir de 10.20.57.24 : icmp_seq=4 TTL=62 temps=0,316 ms 64 octets à partir de 10.20.57.24 : icmp_seq=5 TTL=62 temps=0,281 ms 64 octets à partir de 10.20.57.24 : icmp_seq=6 TTL=62 temps=0,377 ms ^C --- statistiques de ping du 20.10.57.24 --- 6 paquets transmis, 6 reçus, 0 % de perte de paquets, temps 5716 ms RTT min/mg/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) octets de données. 64 octets depuis 10.20.57.24 : icmp_seq=1 TTL=62 temps=11000 ms 64 octets à partir de 10.20.57.24 : icmp_seq=2 TTL=62 temps=11000 ms 64 octets à partir de 10.20.57.24 : icmp_seq=3 TTL=62 temps=11000 ms 64 octets à partir du 20.10.57.24 : icmp_seq=4 TTL=62 temps=11000 ms 64 octets à partir de 10.20.57.24 : icmp_seq=5 ttl=62 temps=11000 ms 64 octets depuis 10.20.57.24 : icmp_seq=6 TTL=62 temps=11000 ms 64 octets à partir de 10.20.57.24 : icmp_seq=7 TTL=62 temps=11000 ms
Nous nous connectons à la base de données MySQL sur le serveur de test gettestlnx02 comme indiqué ci-dessous (notez que si vous vous connectez à ce serveur via ssh, il sera assez lent à utiliser sur gettestlnx02 pour le moment.) Bien sûr, vous pouvez aussi simuler la latence réseau sur le serveur MySQL, ou réduire à la fois la latence connect_timeout et la latence réseau) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Saisissez le mot de passe : ERREUR 2013 (HY000) : Perte de connexion au serveur MySQL lors de la lecture du paquet d’autorisation, erreur système : 0 [root@gettestlnx02 ~] # Comme montré ci-dessus, en raison du délai réseau de plus de 10 secondes, la connexion à MySQL a échoué, à ce moment-là, lorsque vous interrogez la table host_cache sur le serveur MySQL, vous verrez que le SUM_CONNECT_ERRORS est devenu 1, et que le COUNT_HANDSHAKE_ERRORS a également changé1.
Ensuite, on lance ainsi trois fois à répétition, et vous verrez que le SUM_CONNECT_ERRORS devient 3, et le COUNT_HANDSHAKE_ERRORS devient 3. Ensuite, nous utilisons les commandes netem et tc pour annuler la simulation de latence réseau sur le serveur de test, puis nous allons à la connexion de test vers la base de données MySQL, comme montré dans le test suivant : [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Saisissez le mot de passe : ERREUR 1129 (HY000) : L’hôte '192.168.27.180' est bloqué à cause de nombreuses erreurs de connexion ; Débloquer avec 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
À ce stade, il peut être construit“ERREUR 1129 (HY000) : L’hôte '192.168.27.180' est bloqué à cause de nombreuses erreurs de connexion ; Débloquer avec 'mysqladmin flush-hosts'”Erreur. solution Résolu ERREUR 1129 (00000) : L’hôte « xxx » est bloqué à cause de nombreuses erreurs de connexion. Il existe de nombreuses façons d’obtenir l’erreur de déblocage avec 'mysqladmin flush-hosts', mais certaines sont temporaires. Le plan temporaire est que les indicateurs ne traitent pas la cause profonde. L’essentiel est de corriger les erreurs réseau (qui nécessitent souvent de consulter des administrateurs réseau ou des administrateurs système) Solution de contournement : 1, fixe la valeur de la variable max_connection_errors à une valeur plus grande
Cette solution temporaire n’est qu’une condition déclenchant un délai pour que la PI soit interdite, et dans les cas complexes ou en concurrence élevée, il est nécessaire de fixer une valeur élevée, sinon elle sera facilement déclenchée à nouveau. De plus, les variables ne prennent effet que sur l’environnement actuel et expirent si elles sont redémarrées. 2: utilisationhôtes flush mysql> hôtes flush ; Requête OK, 0 lignes affectées (0,00 sec) mysql> sélectionner * depuis performance_schema.host_cache ; Jeu vide (0,00 sec) mysql> Bien sûr, vous pouvez aussi utiliser la commande mysqladmin flush-hosts pour nettoyer les informations de cache de l’hôte [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Saisissez le mot de passe : Alors, qu’est-ce que le cache hôte ? L’introduction officielle est la suivante : Le serveur MySQL maintient un cache hôte en mémoire contenant des informations sur les clients : adresse IP, nom hôte et informations d’erreur. Le serveur utilise ce cache pour des connexions TCP non locales. Il n’utilise pas le cache pour les connexions TCP établies via une adresse d’interface en boucle (127.0.0.1 ou ::1), ni pour les connexions établies via un fichier socket Unix, un tuyau nommé ou un partage mémoire. En termes simples, le serveur MySQL maintient un cache en mémoire contenant les informations du client : adresse IP, nom d’hôte, message d’erreur, etc. Le serveur met en cache les informations de connexion TCP non locales. Il ne met pas en cache les connexions TCP effectuées à l’aide d’adresses d’interface en boucle (127.0.0.1 ou ::1), ni les connexions réalisées via des fichiers socket Unix, des pipelines nommés ou de la mémoire partagée. Les informations du cache hôte peuvent être interrogées via la table host_cache dans la base de données performance_schema. 3: Fixer la variable host_cache_size à0 En fait, je dirais que c’est la solution la moins fiable, simplement pour empêcher le serveur MySQL de loger les informations du cache hôte. Cette méthode peut être complètement ignorée.
| 
Publié sur 08/04/2019 11:01:48
|
|
|
|
