|
Recentemente, un server MySQL è stato incontrato per alcuni fattori particolari“ERRORE 1129 (00000): L'host 'xxx' è bloccato a causa di molti errori di connessione. Sblocca con 'mysqladmin flush-hosts'”Dopo aver risolto il problema, nel processo di approfondire il parametro max_connect_errors, alcune descrizioni contraddittorie di dati di rete diversi mi hanno un po' confuso (riguardo a questo errore, la ragione essenziale è che lo stesso IP ha generato troppe connessioni di database interrotte (superando il valore massimo di max_connect_errors) in un breve periodo di tempo, e il seguente è un processo di esplorazione dei miei problemi, analisi e chiarimento dei dubbi. Prima di tutto, ho cercato alcune informazioni su Internet, molte delle quali giurano di introdurre che se il numero di tentativi di inserimento password supera max_connect_errors variabili, MySQL bloccherà questo login client, e poi ho trovato le informazioni ufficiali sull'introduzione di max_connect_errors, come mostrato qui sotto, MySQL 5.6/5.7 è lo stesso Se più di questo numero di richieste di connessione successive da un host vengono interrotte senza una connessione riuscita, il server blocca quell'host da ulteriori connessioni. Puoi sbloccare host bloccati svuotando la cache degli host. Per farlo, emetti un'istruzione FLUSH HOSTS o esegui un comando flush-hosts di mysqladmin. Se una connessione viene stabilita con successo entro meno di max_connect_errors tentativi dopo l'interruzione di una connessione precedente, il conteggio degli errori per l'host viene cancellato a zero. Tuttavia, una volta bloccato un host, lo svuotamento della cache dell'host è l'unico modo per sbloccarlo. Il valore predefinito è 100. Come mostrato sopra, la traduzione è approssimativamente la seguente: se il server MySQL riceve richieste consecutive dallo stesso host e tutte queste richieste consecutive vengono interrotte senza stabilire con successo una connessione, quando il valore cumulativo di queste richieste consecutive è maggiore del valore max_connect_errors set, il server MySQL bloccherà tutte le richieste successive da questo host. Credo che quando vedrai queste informazioni all'inizio, verrai anche attaccato“molte richieste di connessione successive da un host vengono interrotte senza una connessione riuscita”Confuso, infatti, ciò è dovuto al fatto che la connessione al database viene interrotta a causa di anomalie di rete. Ho cercato queste informazioni su Internet: Sembra esserci confusione su questa variabile. Non blocca davvero gli host per password ripetute e non valide, ma per connessioni abortite a causa di errori di rete. Allora possiamo sperimentare e verificare noi stessi per scoprire quale sia corretto. Crea un account di test nel database MySQL, e poi impostiamo la variabile max_connect_errors a3. Poi usiamo un'altra macchina di test per collegarci al database MySQL con la password errata, come mostrato di seguito, anche se vengono inserite le precedenti tre password sbagliate, il quarto input non riscontra l'errore sopra indicato.Poi puoi escludere che questa variabile abbia a che fare con l'inserimento della password sbagliata. [root@mytestlnx02 TMP]# MySQL -H10.20.57.24 -UTEST -P Inserisci la password: ERRORE 1045 (28000): Accesso negato per l'utente 'test'@'mytestlnx02' (usando password: SÌ) [root@mytestlnx02 TMP]# MySQL -H10.20.57.24 -UTEST -P Inserisci la password: ERRORE 1045 (28000): Accesso negato per l'utente 'test'@'mytestlnx02' (usando password: SÌ) [root@mytestlnx02 TMP]# MySQL -H10.20.57.24 -UTEST -P Inserisci la password: ERRORE 1045 (28000): Accesso negato per l'utente 'test'@'mytestlnx02' (usando password: SÌ) [root@mytestlnx02 TMP]# MySQL -H10.20.57.24 -UTEST -P Inserisci la password: ERRORE 1045 (28000): Accesso negato per l'utente 'test'@'mytestlnx02' (usando password: SÌ) [root@mytestlnx02 TMP] # Infatti, se un IP inserisce una password errata, MySQL la registrerà nella tabella host_cache sotto il database performance_schema. Viene registrato in modo cumulativo in COUNT_AUTHENTICATION_ERRORS campi come segue:
Secondo le informazioni ufficiali, il campo host_cache è statisticamente considerato come“Ostruzione”degli errori di connessione (valutati in base a max_connect_errors variabili di sistema). Vengono conteggiati solo gli errori di handshake del protocollo e vengono utilizzati solo per host autenticati (HOST_VALIDATED = SÌ). SUM_CONNECT_ERRORS Il numero di errori di connessione considerati "bloccanti" (valutati rispetto almax_connect_errorsvariabile di sistema). Vengono conteggiati solo gli errori di handshake del protocollo, e solo per gli host che hanno superato la validazione (HOST_VALIDATED = SÌ). MySQLIl client deve avviare un protocollo di handshake a tre tempi per stabilire una connessione con il database; in circostanze normali, questo tempo è molto breve, ma una volta che compaiono anomalie di rete, timeout e altri fattori, il protocollo di handshake non sarà completato; MySQL ha un parametro connect_timeout, è il tempo in cui il server MySQL processa MySQL di aspettare l'instaurazione della connessione, in pochi secondi. Se la stretta di mano del protocollo non viene ancora completata dopo il periodo di connect_timeout, il client MySQL riceverà un'eccezione con un messaggio di eccezione simile a: Connessione persa al server MySQL a 'XXX', errore di sistema: errno, la variabile di default è 10 secondi:
Costruiamo un caso in cui la connessione al database viene interrotta a causa del timeout di rete, usiamo i comandi netem e tc in Linux per simulare il ritardo di trasmissione di rete in un ambiente complesso; dopo le seguenti impostazioni, in questo momento dal server di test per accedere al server MySQL, ci sarà un ritardo di 11 secondi: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) byte di dati. 64 byte da 10.20.57.24: icmp_seq=1 TTL=62 tempo=0,251 ms 64 byte da 10.20.57.24: icmp_seq=2 TTL=62 tempo=0,330 ms 64 byte da 10.20.57.24: icmp_seq=3 TTL=62 tempo=0,362 ms 64 byte da 10.20.57.24: icmp_seq=4 TTL=62 tempo=0,316 ms 64 byte da 10.20.57.24: icmp_seq=5 ttl=62 tempo=0,281 ms 64 byte da 10.20.57.24: icmp_seq=6 TTL=62 tempo=0,377 ms ^C --- 20.10.57.24 statistiche di ping --- 6 pacchetti trasmessi, 6 ricevuti, 0% di perdita di pacchetti, tempo 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) byte di dati. 64 byte da 10.20.57.24: icmp_seq=1 TTL=62 tempo=11000 ms 64 byte da 10.20.57.24: icmp_seq=2 TTL=62 tempo=11000 ms 64 byte da 10.20.57.24: icmp_seq=3 TTL=62 tempo=11000 ms 64 byte da 10.20.57.24: icmp_seq=4 TTL=62 tempo=11000 ms 64 byte da 10.20.57.24: icmp_seq=5 TTL=62 tempo=11000 ms 64 byte da 10.20.57.24: icmp_seq=6 ttl=62 tempo=11000 ms 64 byte da 10.20.57.24: icmp_seq=7 TTL=62 tempo=11000 ms
Ci connettiamo al database MySQL sul server di test gettestlnx02 come mostrato di seguito (nota che se ti connetti a questo server tramite ssh, sarà piuttosto lento operare su gettestlnx02 in questo momento.) Ovviamente, puoi anche simulare la latenza di rete sul server MySQL, oppure puoi ridurre sia la latenza di connect_timeout che quella di rete) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Inserisci la password: ERRORE 2013 (HY000): Connessione persa al server MySQL a 'lettura del pacchetto di autorizzazione', errore di sistema: 0 [root@gettestlnx02 ~] # Come mostrato sopra, a causa del ritardo di rete di oltre 10 secondi, la connessione a MySQL è fallita; in questo momento, quando si interroga la tabella host_cache sul server MySQL, si vede che la SUM_CONNECT_ERRORS è diventata 1 e che anche la COUNT_HANDSHAKE_ERRORS è cambiata1.
Poi lanciiamo così tre volte ripetutamente, e vedrai che il SUM_CONNECT_ERRORS diventa 3, e il COUNT_HANDSHAKE_ERRORS diventa 3. Poi usiamo i comandi netem e tc per annullare la simulazione di latenza di rete sul server di test, e poi passiamo alla connessione di test al database MySQL, come mostrato nel seguente test: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Inserisci la password: ERRORE 1129 (HY000): L'host '192.168.27.180' è bloccato a causa di molti errori di connessione; sblocca con 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Al momento, può essere costruito“ERRORE 1129 (HY000): L'host '192.168.27.180' è bloccato a causa di molti errori di connessione; sblocca con 'mysqladmin flush-hosts'”Sbagliato. soluzione ERRORE 1129 risolto (00000): L'host 'xxx' è bloccato a causa di molti errori di connessione. Ci sono molti modi per ottenere l'errore Unblock con 'mysqladmin flush-hosts', ma alcuni sono temporanei. Il piano temporaneo prevede che gli indicatori non affrontino la causa principale. La chiave è correggere errori di rete (che spesso richiedono la consulenza di amministratori di rete o di sistema) Soluzione alternativa: 1, imposta il valore della variabile max_connection_errors a un valore maggiore
Questa soluzione temporanea è solo una condizione di ritardo che attiva il divieto dell'IP e, in casi complessi o con alta concorrenza, è necessario fissare un valore elevato, altrimenti verrà facilmente attivato di nuovo. Inoltre, le variabili hanno effetto solo sull'ambiente corrente e scadranno se vengono riavviate. 2: usoOspiti a flush mysql> flush hosts; Query OK, 0 righe interessate (0,00 sec) mysql> seleziona * da performance_schema.host_cache; Set vuoto (0,00 sec) MySQL> Ovviamente, puoi anche usare il comando flush-hosts di mysqladmin per pulire le informazioni della cache dell'host [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Inserisci la password: Quindi, cos'è la cache dell'host? L'introduzione ufficiale è la seguente: Il server MySQL mantiene una cache host in memoria che contiene informazioni sui client: indirizzo IP, nome host e informazioni sugli errori. Il server utilizza questa cache per connessioni TCP non locali. Non utilizza la cache per le connessioni TCP stabilite tramite un indirizzo di interfaccia loopback (127.0.0.1 o ::1), né per le connessioni stabilite tramite un file socket Unix, un pipe chiamato o condiviso Memoria. In termini semplici, il server MySQL mantiene una cache in memoria contenente informazioni sul client: indirizzo IP, nome host, messaggio di errore, ecc. Il server memorizza in cache le informazioni di connessione TCP non locali. Non memorizza in cache le connessioni TCP effettuate utilizzando indirizzi di interfaccia loopback (127.0.0.1 o::1), né connessioni effettuate tramite file socket Unix, pipeline denominate o memoria condivisa. Le informazioni sulla cache dell'host possono essere interrogate tramite la tabella host_cache nel database performance_schema. 3: Imposta la variabile host_cache_size a0 In effetti, direi che questa è la soluzione meno affidabile, solo per far sì che il server MySQL non registri le informazioni della cache dell'host. Questo metodo può essere completamente ignorato.
| 
Pubblicato su 08/04/2019 11:01:48
|
|
|
|
