|
Ostatnio pojawił się serwer MySQL z powodu pewnych specjalnych czynników“BŁĄD 1129 (00000): Host 'xxx' jest zablokowany z powodu wielu błędów połączenia. Odblokuj za pomocą 'mysqladmin flush-hosts'”Po rozwiązaniu problemu, w trakcie nauki o parametrze max_connect_errors, pewne sprzeczne opisy różnych danych sieciowych trochę mnie zdezorientowały (co do tego błędu jest zasadniczym powodem, że ten sam adres IP generował zbyt wiele przerwanych połączeń bazy danych (przekraczających maksymalną wartość max_connect_errors) w krótkim czasie, a poniżej jest proces eksploracji moich problemów, analizy i wyjaśniania wątpliwości. Najpierw przeszukałem informacje w Internecie, z których wiele przysięga, że jeśli liczba prób wprowadzenia hasła przekroczy max_connect_errors zmiennych, MySQL zablokuje to logowanie klienta, a potem znalazłem oficjalne informacje o wprowadzeniu max_connect_errors, jak pokazano poniżej, MySQL 5.6/5.7 jest taki sam Jeśli więcej niż tyle kolejnych żądań połączenia z hosta zostanie przerwanych bez udanego połączenia, serwer blokuje ten host przed dalszymi połączeniami. Możesz odblokować zablokowane hosty, oczyszczając pamięć podręczną hosta. Aby to zrobić, wydaj polecenie FLUSH HOSTS lub wykonaj polecenie mysqladmin flush-hosts. Jeśli połączenie zostanie pomyślnie nawiązane w mniej niż max_connect_errors próbach po przerwaniu poprzedniego połączenia, liczba błędów hosta zostaje wyczyszczona do zera. Jednak po zablokowaniu hosta jedynym sposobem na jego odblokowanie jest wyczyszczenie pamięci podręcznej. Domyślnie to 100. Jak pokazano powyżej, tłumaczenie wygląda mniej więcej następująco: Jeśli serwer MySQL otrzyma kolejne żądania od tego samego hosta, a wszystkie te kolejne żądania zostaną przerwane bez pomyślnego nawiązania połączenia, gdy wartość skumulowana tych kolejnych żądań przekroczy wartość max_connect_errors ustawioną, serwer MySQL zablokuje wszystkie kolejne żądania z tego hosta. Wierzę, że gdy zobaczysz te informacje na początku, również zostaniesz zaatakowany“wiele kolejnych żądań połączenia z hosta jest przerwanych bez skutecznego połączenia”Zdezorientowany, w rzeczywistości wynika to z faktu, że połączenie bazy danych zostaje przerwane z powodu nieprawidłowości sieciowych. Szukałem takich informacji w Internecie: Wydaje się, że wokół tej zmiennej panuje zamieszanie. Nie blokuje hostów za powtarzające się nieprawidłowe hasła, lecz za przerwanie połączeń z powodu błędów sieciowych. No to możemy sami eksperymentować i zweryfikować, żeby dowiedzieć się, która jest poprawna. Tworzymy konto testowe w bazie MySQL, a następnie ustawiamy zmienną max_connect_errors na3. Następnie używamy innej maszyny testowej, aby połączyć się z bazą MySQL z błędnym hasłem, jak pokazano poniżej, nawet jeśli wprowadzono poprzednie trzy błędne hasła, czwarte wejście nie napotyka powyższego błędu.Wtedy możesz wykluczyć, że ta zmienna ma związek z błędnym wpisaniem hasła. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Wprowadź hasło: BŁĄD 1045 (28000): Odmowa dostępu dla użytkownika 'test'@'mytestlnx02' (używając hasła: TAK) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Wprowadź hasło: BŁĄD 1045 (28000): Odmowa dostępu dla użytkownika 'test'@'mytestlnx02' (używając hasła: TAK) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Wprowadź hasło: BŁĄD 1045 (28000): Odmowa dostępu dla użytkownika 'test'@'mytestlnx02' (używając hasła: TAK) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Wprowadź hasło: BŁĄD 1045 (28000): Odmowa dostępu dla użytkownika 'test'@'mytestlnx02' (używając hasła: TAK) [root@mytestlnx02 tmp] # W rzeczywistości, jeśli adres IP wpisze błędne hasło, MySQL zapisze je w tabeli host_cache w bazie performance_schema. Jest on kumulatywnie odnotowany w COUNT_AUTHENTICATION_ERRORS polach w następujący sposób:
Według oficjalnych informacji, dziedzina host_cache jest statystycznie uznawana za“Zator”błędów połączeń (ocenianych na podstawie max_connect_errors zmiennych systemowych). Liczone są tylko błędy protokołu handshake i są używane tylko dla uwierzytelnionych hostów (HOST_VALIDATED = TAK). SUM_CONNECT_ERRORS Liczba błędów połączenia, które są uznawane za "blokujące" (oceniane względemmax_connect_errorszmienna systemowa). Liczone są tylko błędy protokołu handshake i tylko dla hostów, które przeszły walidację (HOST_VALIDATED = TAK). MySQLKlient musi zainicjować protokół trzykrotnego handshake, aby nawiązać połączenie z bazą danych; w normalnych okolicznościach ten czas jest bardzo krótki, ale gdy pojawią się nieprawidłowości sieci, przerwy sieciowe i inne czynniki, protokół handshake nie będzie mógł się zakończyć. MySQL ma parametr connect_timeout, czyli czas, w którym serwer MySQL musi czekać na nawiązanie połączenia, czyli w ciągu kilku sekund. Jeśli handshake protokołu nie zostanie zakończony po upływie connect_timeout czasu, klient MySQL otrzyma wyjątek z komunikatem o wyjątku podobnym do: Utrata połączenia z serwerem MySQL przy 'XXX', błąd systemowy: errno, zmienna domyślnie wynosi 10 sekund:
Zbudujmy przypadek, w którym połączenie z bazą danych zostaje przerwane przez wyłączenie czasu sieciowego, używamy poleceń netem i tc w Linuksie, aby zasymulować opóźnienie transmisji sieciowej w złożonym środowisku; po następujących ustawieniach, w tym momencie od serwera testowego do dostępu do serwera MySQL wystąpi opóźnienie wynoszące 11 sekund: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bajtów danych. 64 bajty z 10.20.57.24: icmp_seq=1 TTL=62 Czas=0,251 ms 64 bajty z 10.20.57.24: icmp_seq=2 ttl=62 czas=0,330 ms 64 bajty z 10.20.57.24: icmp_seq=3 tt=62 czas=0,362 ms 64 bajty z 10.20.57.24: icmp_seq=4 ttl=62 czas=0,316 ms 64 bajty z 10.20.57.24: icmp_seq=5 ttl=62 czas=0,281 ms 64 bajty z 10.20.57.24: icmp_seq=6 TTL=62 Czas=0,377 ms ^C --- statystyki pingu 10.20.57.24 --- 6 przesłanych pakietów, 6 odebranych, 0% utrata pakietów, czas 5716 ms 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) bajtów danych. 64 bajty z 10.20.57.24: icmp_seq=1 ttl=62 czas=11000 ms 64 bajty z 10.20.57.24: icmp_seq=2 TTL=62 Czas=11000 ms 64 bajty z 10.20.57.24: icmp_seq=3 TTL=62 Czas=11000 ms 64 bajty z 10.20.57.24: icmp_seq=4 TTL=62 Time=11000 ms 64 bajty z 10.20.57.24: icmp_seq=5 TTL=62 Czas=11000 ms 64 bajty z 10.20.57.24: icmp_seq=6 tt=62 czas=11000 ms 64 bajty z 10.20.57.24: icmp_seq=7 tt=62 czas=11000 ms
Łączymy się z bazą danych MySQL na serwerze testowym gettestlnx02, jak pokazano poniżej (zwróć uwagę, że jeśli łączysz się z tym serwerem przez SSH, działanie na gettestlnx02 będzie obecnie dość wolne). Oczywiście możesz też symulować opóźnienia sieciowe na serwerze MySQL albo zmniejszyć zarówno connect_timeout, jak i sieciowe opóźnienia) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Wprowadź hasło: BŁĄD 2013 (HY000): Utrata połączenia z serwerem MySQL przy 'odczytaniu pakietu autoryzacji', błąd systemowy: 0 [root@gettestlnx02 ~] # Jak pokazano powyżej, z powodu opóźnienia sieciowego przekraczającego 10 sekund, połączenie z MySQL zawiodło; w tym momencie, gdy zapytasz tabelę host_cache na serwerze MySQL, zobaczysz, że SUM_CONNECT_ERRORS stał się 1, a COUNT_HANDSHAKE_ERRORS również się zmienił1.
Następnie rzucamy tak trzy razy i zobaczysz, że SUM_CONNECT_ERRORS staje się 3, a COUNT_HANDSHAKE_ERRORS 3. Następnie używamy poleceń netem i tc, aby anulować symulację opóźnień sieci na serwerze testowym, a następnie przechodzimy do testowego połączenia z bazą MySQL, jak pokazano w następującym teście: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Wprowadź hasło: BŁĄD 1129 (HY000): Host '192.168.27.180' jest zablokowany z powodu wielu błędów połączenia; Odblokuj za pomocą 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Obecnie można go skonstruować“BŁĄD 1129 (HY000): Host '192.168.27.180' jest zablokowany z powodu wielu błędów połączenia; Odblokuj za pomocą 'mysqladmin flush-hosts'”Nieprawda. rozwiązanie Rozwiązano BŁĄD 1129 (00000): Host 'xxx' jest zablokowany z powodu wielu błędów połączenia. Istnieje wiele sposobów na uzyskanie błędu Unblock za pomocą 'mysqladmin flush-hosts', ale niektóre są tymczasowe. Tymczasowy plan zakłada, że wskaźniki nie rozwiązują przyczyny źródłowej. Kluczem jest naprawa błędów sieciowych (które często wymagają konsultacji z administratorami sieci lub systemowymi) Obejście: 1, ustaw wartość zmiennej max_connection_errors na większą
To tymczasowe rozwiązanie jest jedynie warunkiem opóźnienia wywołującym zakaz IP, a w złożonych przypadkach lub dużej równoczeźności konieczne jest ustawienie dużej wartości, w przeciwnym razie łatwo zostanie ono ponownie wywołane. Ponadto zmienne obowiązują tylko w obecnym środowisku i wygasają, jeśli zostaną ponownie uruchomione. 2: zastosowanieGospodarze flush MySQL> Flush hosts; Zapytanie OK, 0 wierszy dotkniętych (0,00 sek) mysql> wybierz * z performance_schema.host_cache; Pusty zestaw (0,00 sek) mysql> Oczywiście możesz też użyć polecenia mysqladmin flush-hosts, aby oczyścić informacje o pamięci podręcznej hosta [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Wprowadź hasło: Czym więc jest host cache? Oficjalne wprowadzenie brzmi następująco: Serwer MySQL utrzymuje w pamięci pamięć podręczną hosta, która zawiera informacje o klientach: adres IP, nazwę hosta oraz informacje o błędach. Serwer wykorzystuje tę pamięć podręczną do połączeń TCP nielokalnych. Nie używa pamięci podręcznej do połączeń TCP nawiązanych przy użyciu adresu interfejsu loopback (127.0.0.1 lub ::1) ani do połączeń nawiązanych za pomocą pliku gniazda Unix, nazwanego pipe lub współdzielonego pamięć. Mówiąc prosto, serwer MySQL utrzymuje pamięć podręczną w pamięci zawierającą informacje o kliencie: adres IP, nazwę hosta, komunikat o błędzie itp. Serwer buforuje informacje o połączeniu TCP nielokalnie. Nie buforuje połączeń TCP nawiązanych przy użyciu adresów interfejsu loopback (127.0.0.1 lub ::1), ani połączeń nawiązanych za pomocą plików socket Unix, nazwanych potoków ani pamięci współdzielonej. Informacje o pamięci podręcznej hosta można wyszukiwać za pomocą tabeli host_cache w bazie performance_schema. 3: Ustaw zmienną host_cache_size na0 W rzeczywistości powiedziałbym, że to najbardziej zawodne rozwiązanie, by serwer MySQL nie logował informacji z pamięci podręcznej hosta. Tę metodę można całkowicie zignorować.
| 
Opublikowano 08.04.2019 11:01:48
|
|
|
|
