Den almindelige MySQL-fejl:"Fik en fejl ved læsning af kommunikationspakke"

MySQL er den anden berømte database i verden ifølge DB Engine-webstedet bag Oracle. Det, der gør MySQL berømt, er sandsynligvis, fordi det er et meget hurtigt, pålideligt og fleksibelt Database Management System. MySQL er også en af ​​de understøttede databaser i ClusterControl. Du kan nemt implementere, skalere, overvåge og gøre en masse ting med ClusterControl.

I dag vil vi ikke tale om nogen af ​​dem, men vi vil diskutere en af ​​de almindelige fejl for MySQL og mulige fejlfindingstip. Når vi arbejdede med billetter, meget tid, når vi tjekker fejlrapporterne eller logfilerne, så vi denne linje "Fik en fejl ved at læse kommunikationspakken" ret ofte. Vi tror, ​​det ville være en fordel, hvis vi skriver en blog relateret til denne fejl, ikke kun for vores kunder, men også for andre læsere. Lad os ikke vente længere, det er tid til at dykke mere!

MySQL Client/Server Protocol

Først og fremmest skal vi forstå, hvordan MySQL kommunikerer mellem klient og server. Både klient og server bruger MySQL-protokol, som er implementeret af Connectors, MySQL Proxy og også kommunikationen mellem master- og slavereplikeringsservere. MySQL-protokollen understøtter funktioner som gennemsigtig kryptering via SSL, gennemsigtig komprimering, en forbindelsesfase og samt en kommandofase.

Både heltal og strenge er de grundlæggende datatyper, der bruges i hele MySQL-protokollen. Når MySQL-klienten og -serveren ønsker at kommunikere med hinanden eller sende dataene, vil den opdele dataene i pakker med en maksimal størrelse på 16 MB og vil også sætte en pakkehoved foran hver chunk. Inde i hver pakke vil der være en nyttelast, hvor datatyperne (heltal/strenge) spiller deres rolle.

I betragtning af at CLIENT_PROTOCOL_41 er aktiveret, vil serveren svare enhver af følgende pakker for næsten hver kommando, som klienten sender til serveren:

Sådan diagnosticeres problemerne

Der er typisk to typer forbindelsesproblemer, som er kommunikationsfejl eller afbrudte forbindelser. Når nogen af ​​disse forbindelsesproblemer opstår, er følgende informationskilder det gode udgangspunkt for fejlfinding og analyse:

• Fejlloggen

• Den generelle forespørgselslog

• Statusvariablerne Aborted_xxx og Connection_errors_xxx

• Værtens cache

Forbindelsesfejl og mulige årsager

I tilfælde af at der opstår forbindelsesfejl, og afhængigt af fejlene, vil det øge statustælleren for enten Aborted_clients eller Aborted_connects i statusvariablerne. Som taget fra MySQL-dokumentationen betyder Aborted_clients antallet af forbindelser, der blev afbrudt, fordi klienten døde uden at lukke forbindelsen korrekt. Hvad angår Aborted_connects, betyder det antallet af mislykkede forsøg på at oprette forbindelse til MySQL-serveren.

Hvis du starter MySQL-serveren med --log-warnings-indstillingen, er chancerne for, at du sandsynligvis vil se eksemplet med følgende meddelelse i din fejllog. Som du har bemærket, sagde meddelelsen tydeligt, at den relaterer sig til afbrydelsesforbindelsen, og derfor vil Aborted_connects-statustælleren blive forøget i statusvariablen:

[Advarsel] Afbrudt forbindelse 154669 til db:'wordpress' bruger:'wpuser' vært:'værtsnavn' (Fik en fejl ved læsning af kommunikationspakker)

Normalt kan der forekomme mislykkede forbindelsesforsøg af følgende årsager. Når du bemærkede dette, indikerer det muligvis, at en uautoriseret person er ved at bryde databasen, og du vil måske se på den hurtigst muligt:

• En klient har ingen rettigheder til at få adgang til databasen.

• Der er brugt forkert legitimationsoplysninger.

• En forbindelsespakke, der har forkerte oplysninger.

• På grund af den nåede grænse for connect_timeout for at oprette forbindelse.

Statusvariablen for Aborted_clients vil blive øget af serveren, hvis en klient formår at oprette forbindelse, men bliver afbrudt eller afsluttet på en forkert måde. Ud over det vil serveren også logge en meddelelse om Afbrudt forbindelse til fejlloggen. For denne type fejl kan det almindeligvis skyldes følgende årsag:

• Klienten lukker ikke forbindelsen korrekt før den afsluttes (kalder ikke mysql_close ()).

• Klienten har overskredet wait_timeout eller interactive_timeout sekunder.

• Klientprogrammet eller applikationen sluttede pludselig midt i dataoverførslen.

Ud over de tidligere årsager kan andre sandsynlige årsager til problemer med både afbrudte forbindelser og problemer med afbrudte klienter være relateret til en af ​​følgende:

• TCP/IP-konfiguration rodet.

• Variabelværdien er for lille til max_allowed_packet.

• Utilstrækkelig hukommelsesallokering til forespørgsler.

• Defekt hardware som ethernets, switches, kabler osv.

• Problemer med trådbiblioteket.

• Duplex syndrom problem, hvor overførslen går i burst-pause-burst-pause-tilstand (hvis du bruger ethernet-protokol med Linux, både halv og fuld duplex).

Sådan rettes MySQL-kommunikationsfejl

Nu hvor vi lærte en masse muligheder, der forårsagede MySQL-forbindelsesfejl. Baseret på vores erfaring er dette problem for det meste relateret til firewall- eller netværksproblemer. Det er også rimeligt at sige, at det ikke er let at diagnosticere denne form for problemer. Ikke desto mindre kan følgende løsning være nyttig for dig til at løse denne fejl:

• Hvis din applikation er afhængig af wait_timeout for at lukke forbindelsen, er det værd at ændre applikationslogikken, så den ordentligt lukket ved afslutningen af ​​enhver operation.

• Sørg for, at værdien for max_allowed_packet er inden for det acceptable område, så klienten ikke modtager nogen fejl relateret til "pakken er for stor".

• For problemer med forbindelsesforsinkelse, der kan skyldes DNS, er det værd at tjekke, om du har skip-name- løsning aktiveret.

• Hvis du bruger et PHP-program eller en anden programmering, er det bedste at sørge for, at det ikke afbrydes forbindelserne som typisk er sat til max_execution_time.

• Hvis du har bemærket mange TIME_WAIT-meddelelser fra netstat, er det værd at bekræfte, at forbindelserne er godt administreret på ansøgning slut.

• Hvis du bruger Linux og har mistanke om, at problemet skyldes netværket, er det bedst at tjekke netværksgrænsefladen ved at bruge ifconfig-a-kommandoen og undersøge outputtet på MySQL-serveren for eventuelle fejl.

• For ClusterControl-brugere kan du aktivere Revisionslog fra Klyngen -> Sikkerhed -> Revisionslog. Ved at aktivere denne funktion kan det hjælpe dig med at finde ud af, hvilken forespørgsel der er synderen.

• Netværksværktøjer som tcpdump og Wireshark kan være nyttige til at identificere potentielle netværksproblemer, timeouts og ressourceproblemer for MySQL.

• Kontrollér regelmæssigt hardwaren ved at sikre, at der ikke er defekte enheder, specielt til ethernet, hubs, switches, kabler osv. Det er værd at udskifte det defekte apparat for at sikre, at forbindelsen er god hele tiden.

Konklusion

Der er mange årsager, der måske kan føre til problemer med MySQL-forbindelsespakke. Når dette problem opstår, vil det helt sikkert påvirke forretningen og den daglige drift. Selvom denne type problem ikke er let at diagnosticere, og det meste af tiden skyldes netværket eller firewallen, er det værd at tage alle de trin, der er blevet foreslået tidligere, i betragtning for at løse problemet. Vi håber virkelig, at dette blogindlæg kan hjælpe dig på en eller anden måde, især når du står over for dette problem.