|
Nesen MySQL serveris tika sastapts dažu īpašu faktoru dēļ“KĻŪDA 1129 (00000): Resursdators 'xxx' ir bloķēts daudzu savienojuma kļūdu dēļ. Atbloķēt ar "mysqladmin flush-hosts"”Pēc problēmas atrisināšanas, uzzinot vairāk par parametru max_connect_errors, daži pretrunīgi dažādu tīkla datu apraksti mani nedaudz mulsināja (par šo kļūdu galvenais iemesls ir tas, ka tas pats IP īsā laika periodā radīja pārāk daudz pārtrauktu datu bāzes savienojumu (pārsniedzot maksimālo vērtību max_connect_errors), un tālāk ir manu problēmu izpētes, problēmu analīzes un šaubu noskaidrošanas process. Pirmkārt, es meklēju informāciju internetā, no kuriem daudzi zvēr ieviest, ka, ja paroles ievades mēģinājumu skaits pārsniedz max_connect_errors mainīgos, MySQL bloķēs šo klienta pieteikšanos, un tad es atradu oficiālo informāciju par max_connect_errors ieviešanu, kā parādīts zemāk, MySQL 5.6 / 5.7 ir vienāds Ja bez veiksmīga savienojuma tiek pārtraukti vairāki secīgi savienojuma pieprasījumi no resursdatora, serveris bloķē šo resursdatoru no turpmākiem savienojumiem. Jūs varat atbloķēt bloķētos resursdatorus, izskalojot resursdatora kešatmiņu. Lai to izdarītu, izdodiet FLUSH HOSTS paziņojumu vai izpildiet mysqladmin flush-hosts komandu. Ja savienojums tiek veiksmīgi izveidots mazāk nekā max_connect_errors mēģinājumos pēc iepriekšējā savienojuma pārtraukšanas, resursdatora kļūdu skaits tiek notīrīts līdz nullei. Tomēr, tiklīdz resursdators ir bloķēts, resursdatora kešatmiņas skalošana ir vienīgais veids, kā to atbloķēt. Noklusējums ir 100. Kā parādīts iepriekš, tulkojums ir aptuveni šāds: Ja MySQL serveris saņem secīgus pieprasījumus no tā paša resursdatora un visi šie secīgie pieprasījumi tiek pārtraukti, veiksmīgi neizveidojot savienojumu, kad šo secīgo pieprasījumu kumulatīva vērtība ir lielāka par max_connect_errors iestatīto vērtību, MySQL serveris bloķēs visus turpmākos pieprasījumus no šī resursdatora. Es uzskatu, ka tad, kad jūs redzēsiet šo informāciju sākumā, jums arī uzbruks“Daudzi secīgi savienojuma pieprasījumi no resursdatora tiek pārtraukti bez veiksmīga savienojuma”Patiesībā tas ir neskaidrs, jo datu bāzes savienojums tiek pārtraukts tīkla novirzes dēļ. Es meklēju šādu informāciju internetā: Šķiet, ka ap šo mainīgo ir neskaidrības. Tas īsti nebloķē saimniekdatorus atkārtotām nederīgām parolēm, bet gan pārtrauktiem savienojumiem tīkla kļūdu dēļ. Nu, tad mēs varam eksperimentēt un pārbaudīt to paši, lai uzzinātu, kurš no tiem ir pareizs. Izveidojiet testa kontu MySQL datu bāzē, un pēc tam mēs iestatām mainīgo max_connect_errors uz3. Tad mēs izmantojam citu testa mašīnu, lai izveidotu savienojumu ar MySQL datu bāzi ar nepareizu paroli, kā parādīts zemāk, pat ja tiek ievadītas iepriekšējās trīs nepareizās paroles, ceturtā ievade nesaskaras ar iepriekš minēto kļūdu.Tad jūs varat izslēgt, ka šim mainīgajam ir kāds sakars ar nepareizu paroles ievadīšanu. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Ievadiet paroli: KĻŪDA 1045 (28000): piekļuve liegta lietotājam 'test'@'mytestlnx02' (izmantojot paroli: JĀ) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Ievadiet paroli: KĻŪDA 1045 (28000): piekļuve liegta lietotājam 'test'@'mytestlnx02' (izmantojot paroli: JĀ) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Ievadiet paroli: KĻŪDA 1045 (28000): piekļuve liegta lietotājam 'test'@'mytestlnx02' (izmantojot paroli: JĀ) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Ievadiet paroli: KĻŪDA 1045 (28000): piekļuve liegta lietotājam 'test'@'mytestlnx02' (izmantojot paroli: JĀ) [root@mytestlnx02 tmp] # Faktiski, ja IP ievada nepareizu paroli, MySQL to ierakstīs host_cache tabulā zem performance_schema datu bāzes. To kumulatīvi reģistrē COUNT_AUTHENTICATION_ERRORS laukos šādi:
Saskaņā ar oficiālo informāciju host_cache lauks statistiski tiek uzskatīts par“Bloķēšana”pieslēguma kļūdu skaits (novērtēts, pamatojoties uz max_connect_errors sistēmas mainīgajiem lielumiem). Tiek skaitītas tikai protokola rokasspiediena kļūdas, un tās tiek izmantotas tikai autentificētiem resursdatoriem (HOST_VALIDATED = JĀ). SUM_CONNECT_ERRORS Savienojuma kļūdu skaits, kas tiek uzskatītas par "bloķējošām" (novērtēts, salīdzinot armax_connect_errorssistēmas mainīgais). Tiek skaitītas tikai protokola rokasspiediena kļūdas un tikai tiem resursdatoriem, kas izturējuši validāciju (HOST_VALIDATED = JĀ). MySQLKlientam ir jāuzsāk trīs reizes rokasspiediena protokols, lai izveidotu savienojumu ar datu bāzi, normālos apstākļos šis laiks ir ļoti īss, bet, tiklīdz parādās tīkla novirze, tīkla taimauts un citi faktori, tas izraisīs rokasspiediena protokolu, lai nevarētu pabeigt, MySQL ir parametrs connect_timeout, tas ir laiks, lai MySQL servera process mysqld gaidītu, līdz savienojums tiks izveidots, sekundēs. Ja protokola rokasspiediens joprojām nav pabeigts pēc connect_timeout laika perioda, MySQL klients saņems izņēmumu ar izņēmuma ziņojumu, kas līdzīgs šādam: Zaudēts savienojums ar MySQL serveri pie 'XXX', sistēmas kļūda: Kļūda, mainīgais pēc noklusējuma ir 10 sekundes:
Izveidosim gadījumu, kad datu bāzes savienojums tiek pārtraukts, ko izraisa tīkla taimauts, mēs izmantojam netem un tc komandas Linux, lai simulētu tīkla pārraides aizkavēšanās gadījumu sarežģītā vidē, pēc šādiem iestatījumiem, šobrīd no testa servera, lai piekļūtu MySQL serverim, būs 11 sekunžu aizkavēšanās: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) baiti datu. 64 baiti no 10.20.57.24: icmp_seq=1 ttl=62 laiks=0.251 ms 64 baiti no 10.20.57.24: icmp_seq=2 ttl=62 laiks=0.330 ms 64 baiti no 10.20.57.24: icmp_seq=3 ttl=62 laiks=0.362 ms 64 baiti no 10.20.57.24: icmp_seq=4 ttl=62 laiks=0.316 ms 64 baiti no 10.20.57.24: icmp_seq=5 ttl=62 laiks=0.281 ms 64 baiti no 10.20.57.24: icmp_seq=6 ttl=62 laiks=0.377 ms ^C --- 10.20.57.24 ping statistika --- Pārraidītas 6 paketes, saņemtas 6, 0% pakešu zudums, laiks 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) baiti datu. 64 baiti no 10.20.57.24: icmp_seq=1 ttl=62 laiks=11000 ms 64 baiti no 10.20.57.24: icmp_seq=2 ttl=62 laiks=11000 ms 64 baiti no 10.20.57.24: icmp_seq=3 ttl=62 laiks=11000 ms 64 baiti no 10.20.57.24: icmp_seq=4 ttl=62 laiks=11000 ms 64 baiti no 10.20.57.24: icmp_seq=5 ttl=62 laiks=11000 ms 64 baiti no 10.20.57.24: icmp_seq=6 ttl=62 laiks=11000 ms 64 baiti no 10.20.57.24: icmp_seq=7 ttl=62 laiks=11000 ms
Mēs izveidojam savienojumu ar MySQL datu bāzi testa serverī gettestlnx02, kā parādīts zemāk (ņemiet vērā, ka, ja izveidojat savienojumu ar šo serveri, izmantojot ssh, šobrīd būs diezgan lēni darboties ar gettestlnx02.) Protams, jūs varat arī simulēt tīkla latentumu MySQL serverī vai arī samazināt gan connect_timeout, gan tīkla latentumu) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Ievadiet paroli: KĻŪDA 2013 (HY000): Zaudēts savienojums ar MySQL serveri pie "lasīšanas autorizācijas pakete", sistēmas kļūda: 0 [root@gettestlnx02 ~] # Kā parādīts iepriekš, tīkla aizkaves dēļ, kas pārsniedz 10 sekundes, savienojums ar MySQL neizdevās, šobrīd, vaicājot host_cache tabulu MySQL serverī, tad jūs redzēsiet, ka SUM_CONNECT_ERRORS ir kļuvis par 1, un arī COUNT_HANDSHAKE_ERRORS ir mainījies1.
Tad mēs šādi trīs reizes atkārtoti metam, un jūs redzēsiet, ka SUM_CONNECT_ERRORS kļūst par 3, un COUNT_HANDSHAKE_ERRORS kļūst par 3. Tad mēs izmantojam netem un tc komandas, lai atceltu tīkla latentuma simulāciju testa serverī, un pēc tam dodamies uz testa savienojumu ar MySQL datu bāzi, kā parādīts šajā testā: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Ievadiet paroli: KĻŪDA 1129 (HY000): resursdators '192.168.27.180' ir bloķēts daudzu savienojuma kļūdu dēļ; Atbloķēt ar 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Šajā laikā to var veidot“KĻŪDA 1129 (HY000): resursdators '192.168.27.180' ir bloķēts daudzu savienojuma kļūdu dēļ; Atbloķēt ar 'mysqladmin flush-hosts'”Nepareizi. šķīdums Atrisināta KĻŪDA 1129 (00000): Resursdators 'xxx' ir bloķēts daudzu savienojuma kļūdu dēļ. Ir daudz veidu, kā iegūt kļūdu Atbloķēt ar "mysqladmin flush-hosts", taču daži ir īslaicīgi. Pagaidu plāns ir tāds, ka rādītāji nerisina galveno cēloni. Galvenais ir novērst tīkla kļūdas (kurām bieži ir jākonsultējas ar tīkla administratoriem vai sistēmas administratoriem) Risinājums: 1, iestatiet mainīgā max_connection_errors vērtību uz lielāku vērtību
Šis pagaidu risinājums ir tikai aizkavēšanās nosacījums, lai IP būtu aizliegts, un sarežģītos gadījumos vai augstā vienlaicīgumā ir nepieciešams noteikt lielu vērtību, pretējā gadījumā tas tiks viegli iedarbināts. Turklāt mainīgie lielumi stājas spēkā tikai pašreizējā vidē un beigsies, ja tie tiek restartēti. 2: lietošanaFlush resursdatori mysql> flush resursdatori; Vaicājums Labi, ietekmētas 0 rindas (0,00 sek.) mysql> atlasiet * no performance_schema.host_cache; Tukšs komplekts (0,00 sek.) mysql> Protams, varat arī izmantot komandu mysqladmin flush-hosts, lai iztīrītu resursdatoru kešatmiņas informāciju [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Ievadiet paroli: Tātad, kas ir resursdatora kešatmiņa? Oficiālais ievads ir šāds: MySQL serveris atmiņā uztur resursdatora kešatmiņu, kurā ir informācija par klientiem: IP adrese, resursdatora nosaukums un informācija par kļūdām. Serveris izmanto šo kešatmiņu nelokāliem TCP savienojumiem. Tas neizmanto kešatmiņu TCP savienojumiem, kas izveidoti, izmantojot cilpas interfeisa adresi (127.0.0.1 vai ::1), vai savienojumiem, kas izveidoti, izmantojot Unix ligzdas failu, nosauktu cauruli vai koplietotu atmiņa. Vienkārši sakot, MySQL serveris uztur kešatmiņu atmiņā, kas satur klienta informāciju: IP adresi, resursdatora nosaukumu, kļūdas ziņojumu utt. Serveris kešatmiņā saglabā nelokālo TCP savienojuma informāciju. Tas nekešatmiņā nesaglabā TCP savienojumus, kas izveidoti, izmantojot cilpas interfeisa adreses (127.0.0.1 vai::1), vai savienojumus, kas izveidoti, izmantojot Unix ligzdu failus, nosauktus cauruļvadus vai koplietojamo atmiņu. Resursdatora kešatmiņas informāciju var vaicāt, izmantojot performance_schema datu bāzes tabulu host_cache. 3: iestatiet mainīgo host_cache_size uz0 Patiesībā es teiktu, ka tas ir visneuzticamākais risinājums, lai MySQL serveris nereģistrētu resursdatora kešatmiņas informāciju. Šo metodi var pilnībā ignorēt.
| 
Publicēts 08.04.2019 11:01:48
|
|
|
|
