|
Недавно был обнаружен 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 для обработки MySQL через секунды, пока соединение будет установлено. Если протокольное рукопожатие всё ещё не завершено после 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 мс 64 байта от 10.20.57.24: icmp_seq=2 ttl=62 времени = 0.330 мс 64 байта от 10.20.57.24: icmp_seq=3 ttl=62 времени = 0.362 мс 64 байта от 10.20.57.24: icmp_seq=4 ttl=62 времени = 0,316 мс 64 байта от 10.20.57.24: icmp_seq=5 ttl=62 времени = 0.281 мс 64 байта от 10.20.57.24: icmp_seq=6 ttl=62 времени = 0.377 мс ^C --- 10.20.57.24 пинг-статистика --- 6 переданных пакетов, 6 полученных, 0% потери пакетов, время 5716 мс RTT min/avg/max/mdev = 0,251/0,319/0,377/0,047 мс [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 мс 64 байта от 10.20.57.24: icmp_seq=2 ttl=62 времени = 11000 мс 64 байта с 10.20.57.24: icmp_seq=3 ttl=62 времени = 11000 мс 64 байта от 10.20.57.24: icmp_seq=4 ttl=62 времени = 11000 мс 64 байта с 10.20.57.24: icmp_seq=5 ttl=62 времени = 11000 мс 64 байта от 10.20.57.24: icmp_seq=6 ttl=62 времени = 11000 мс 64 байта от 10.20.57.24: icmp_seq=7 ttl=62 времени = 11000 мс
Мы подключаемся к базе данных 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, именованных конвейеров или общей памяти. Информацию о кэше хоста можно запросить через таблицу host_cache в базе данных performance_schema. 3: Установить переменную host_cache_size в0 На самом деле, я бы сказал, что это самое ненадёжное решение — чтобы сервер MySQL не регистрировал информацию о кэше хоста. Этот метод можно полностью игнорировать.
| 
Опубликовано 08.04.2019 11:01:48
|
|
|
|
