|
Наскоро беше открит MySQL сървър поради някои специални фактори“ГРЕШКА 1129 (00000): Хост 'xxx' е блокиран поради много грешки в връзката. Деблокиране с 'mysqladmin flush-hosts'”След като проблемът беше решен, в процеса на научаване на повече за параметърния max_connect_errors, някои противоречиви описания на различни мрежови данни ме объркаха малко (относно тази грешка, основната причина е, че един и същ IP генерира твърде много прекъснати връзки с база данни (надвишаващи максималната стойност max_connect_errors) за кратък период от време, и следва процес на изследване на моите проблеми, анализ на проблеми и изясняване на съмнения. Първо, потърсих информация в интернет, много от които твърдят, че ако броят на опитите за въвеждане на парола надвиши max_connect_errors променливи, MySQL ще блокира този клиентски вход, и тогава намерих официалната информация за въвеждането на max_connect_errors, както е показано по-долу, MySQL 5.6/5.7 е същият Ако повече от това последователни заявки за връзка от хост бъдат прекъснати без успешна връзка, сървърът блокира този хост от допълнителни връзки. Можете да отблокирате блокираните хостове, като изчистите кеша на хоста. За целта издайте изявление FLUSH HOSTS или изпълнете команда mysqladmin flush-hosts. Ако връзката бъде успешно установена в рамките на по-малко от max_connect_errors опита след прекъсване на предишна връзка, броят на грешките за хоста се изчиства до нула. Въпреки това, след като хостът бъде блокиран, изчистването на кеша на хоста е единственият начин да се разблокира. По подразбиране е 100. Както е показано по-горе, преводът е приблизително следният: Ако MySQL сървърът получи последователни заявки от един и същ хост и всички тези последователни заявки бъдат прекъснати без успешно установяване на връзка, когато кумулативната стойност на тези последователни заявки е по-голяма от max_connect_errors зададената стойност, MySQL сървърът ще блокира всички следващи заявки от този хост. Вярвам, че когато видите тази информация в началото, и вие ще бъдете нападнати“много последователни заявки за връзка от хост се прекъсват без успешна връзка”Объркан, всъщност това е защото връзката с базата данни е прекъсната поради мрежови аномалии. Търсих такава информация в интернет: Изглежда има объркване около тази променлива. Той не блокира хостове за повтарящи се невалидни пароли, а за прекъснати връзки поради мрежови грешки. Тогава можем да експериментираме и да проверим сами, за да разберем кое е вярно. Създадем тестов акаунт в базата данни MySQL и след това задаваме променливата max_connect_errors на3. След това използваме друга тестова машина, за да се свържем с MySQL базата данни с грешна парола, както е показано по-долу, дори ако са въведени предишните три грешни пароли, четвъртият вход не среща горната грешка.Тогава можете да изключите, че тази променлива има нещо общо с грешното въвеждане на парола. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Въведете паролата: ГРЕШКА 1045 (28000): Достъпът е отказан за потребителя 'test'@'mytestlnx02' (с парола: ДА) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Въведете паролата: ГРЕШКА 1045 (28000): Достъпът е отказан за потребителя 'test'@'mytestlnx02' (с парола: ДА) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Въведете паролата: ГРЕШКА 1045 (28000): Достъпът е отказан за потребителя 'test'@'mytestlnx02' (с парола: ДА) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Въведете паролата: ГРЕШКА 1045 (28000): Достъпът е отказан за потребителя 'test'@'mytestlnx02' (с парола: ДА) [root@mytestlnx02 tmp] # Всъщност, ако IP въведе грешна парола, MySQL ще я запише в таблицата host_cache под базата данни performance_schema. То се записва кумулативно в COUNT_AUTHENTICATION_ERRORS полета по следния начин:
Според официалната информация, областта на host_cache се счита статистически за“Запушване”грешки в връзката (оценени въз основа на max_connect_errors системни променливи). Отчитат се само грешки при ръкостискане на протокола и се използват само за удостоверени хостове (HOST_VALIDATED = ДА). SUM_CONNECT_ERRORS Броят на грешките в връзката, които се считат за "блокиращи" (оценени спрямоmax_connect_errorsсистемна променлива). Отчитат се само протоколни грешки при ръкостискане, и то само за хостове, които са преминали валидиране (HOST_VALIDATED = ДА). MySQLКлиентът трябва да инициира трикратен протокол за ръкостискане, за да установи връзка с базата данни; при нормални обстоятелства това време е много кратко, но щом се появят аномалията в мрежата, таймаутът на мрежата и други фактори, това ще направи протоколът за ръкостискане невъзможно да бъде завършен. MySQL има параметър connect_timeout, това е моментът, в който MySQL сървърът обработва mysqld да изчака връзката да бъде установена, за секунди. Ако протоколното ръкостискане все още не е завършено след connect_timeout времеви период, MySQL клиентът ще получи изключение с изключение, подобно на: Загуба на връзка с MySQL сървъра на 'XXX', системна грешка: ерне, променливата по подразбиране е 10 секунди:
Нека създадем случай, в който връзката с базата данни е прекъсната поради мрежов таймаут; използваме командите netem и tc в Linux, за да симулираме случая със забавяне на мрежовото предаване в сложна среда, след следните настройки, в момента от тестовия сървър за достъп до MySQL сървъра ще има забавяне от 11 секунди: [root@gettestlnx02 ~]# пинг 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) байта данни. 64 байта от 10.20.57.24: icmp_seq=1 ttl=62 време=0.251 ms 64 байта от 10.20.57.24: icmp_seq=2 ttl=62 време=0.330 ms 64 байта от 10.20.57.24: icmp_seq=3 ttl=62 време=0.362 ms 64 байта от 10.20.57.24: icmp_seq=4 ttl=62 време=0.316 ms 64 байта от 10.20.57.24: icmp_seq=5 ttl=62 време=0.281 ms 64 байта от 10.20.57.24: icmp_seq=6 ttl=62 време=0.377 ms ^C --- 10.20.57.24 пинг статистика --- 6 предадени пакета, 6 получени, 0% загуба на пакети, време 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 ~]# пинг 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) байта данни. 64 байта от 10.20.57.24: icmp_seq=1 ttl=62 време=11000 ms 64 байта от 10.20.57.24: icmp_seq=2 ttl=62 време=11000 ms 64 байта от 10.20.57.24: icmp_seq=3 ttl=62 време=11000 ms 64 байта от 10.20.57.24: icmp_seq=4 ttl=62 време=11000 ms 64 байта от 10.20.57.24: icmp_seq=5 ttl=62 време=11000 ms 64 байта от 10.20.57.24: icmp_seq=6 ttl=62 време=11000 ms 64 байта от 10.20.57.24: icmp_seq=7 ttl=62 време=11000 ms
Свързваме се с MySQL базата данни на тестовия сървър gettestlnx02, както е показано по-долу (имайте предвид, че ако се свързвате с този сървър чрез ssh, работата на gettestlnx02 ще бъде доста бавна в момента). Разбира се, можеш също да симулираш латентност в мрежата на MySQL сървъра или да намалиш и connect_timeout, и мрежовата латентност) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Въведете паролата: ГРЕШКА 2013 (HY000): Загуба на връзка с MySQL сървъра при 'четене на упълномощаващ пакет', системна грешка: 0 [root@gettestlnx02 ~] # Както е показано по-горе, поради мрежово забавяне от над 10 секунди, връзката с MySQL се провали, а в този момент, когато направите заявка към таблицата host_cache на MySQL сървъра, ще видите, че SUM_CONNECT_ERRORS е станала 1, а COUNT_HANDSHAKE_ERRORS също се е променила1.
След това хвърляме така три пъти и ще видите, че SUM_CONNECT_ERRORS става 3, а COUNT_HANDSHAKE_ERRORS става 3. След това използваме netem и tc команди, за да отменим мрежовата латентност на тестовия сървър, и отиваме към тестовата връзка с MySQL базата данни, както е показано в следния тест: [root@gettestlnx02 ~]# TC QDISC del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Въведете паролата: ГРЕШКА 1129 (HY000): Хост '192.168.27.180' е блокиран поради много грешки в връзката; Разблокирайте с 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
В момента може да бъде конструиран“ГРЕШКА 1129 (HY000): Хост '192.168.27.180' е блокиран поради много грешки в връзката; Разблокирайте с 'mysqladmin flush-hosts'”Грешно. решение Разрешена ГРЕШКА 1129 (00000): Хост 'xxx' е блокиран поради много грешки при връзката. Има много начини да се получи грешката Unblock с 'mysqladmin flush-hosts', но някои са временни. Временният план е, че индикаторите не адресират коренната причина. Ключът е да се коригират мрежови грешки (които често изискват консултации с мрежови администратори или системни администратори) Заобиколно решение: 1, задайте стойността на променливата max_connection_errors на по-голяма стойност
Това временно решение е просто условие, което задейства забавяне, за да бъде забранен IP-то, и в сложни случаи или висока конкурентност е необходимо да се зададе голяма стойност, в противен случай тя лесно ще бъде задействана отново. Освен това, променливите влияят само върху текущата среда и ще изтекат, ако бъдат рестартирани. 2: използванеФлъш хостове MySQL> Flush хостове; Заявка OK, засегнати са 0 реда (0.00 сек) mysql> изберете * от performance_schema.host_cache; Празен комплект (0.00 сек) mysql> Разбира се, можете също да използвате командата mysqladmin flush-hosts, за да почистите кеша на хоста [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Въведете паролата: Какво е кеш на хоста? Официалното въведение е следното: MySQL сървърът поддържа кеш в паметта, който съдържа информация за клиенти: IP адрес, име на хост и информация за грешки. Сървърът използва този кеш за нелокални TCP връзки. Той не използва кеша за TCP връзки, установени чрез loopback интерфейсен адрес (127.0.0.1 или ::1), нито за връзки, установени чрез Unix сокет файл, именуван канал или споделен памет. С прости думи, MySQL сървърът поддържа кеш в паметта, съдържащ клиентска информация: IP адрес, име на хост, съобщение за грешка и др. Сървърът кешира нелокална TCP връзка информация. Той не кешира TCP връзки, направени чрез loopback интерфейсни адреси (127.0.0.1 или ::1), нито връзки, направени чрез Unix socket файлове, именувани конвейери или споделена памет. Информацията за кеша на хоста може да се търси чрез таблицата host_cache в базата данни performance_schema. 3: Задайте променливата host_cache_size на0 Всъщност бих казал, че това е най-ненадеждното решение, само за да се накара MySQL сървърът да не записва информацията от кеша на хоста. Този метод може да бъде напълно игнориран.
| 
Публикувано в 8.04.2019 г. 11:01:48 ч.
|
|
|
|
