Det vanliga MySQL-felet:"Fick ett fel när kommunikationspaketet lästes"

MySQL är den andra kända databasen i världen enligt DB Engine-webbplatsen bakom Oracle. Det som gör MySQL känt är förmodligen för att det är ett mycket snabbt, pålitligt och flexibelt databashanteringssystem. MySQL är också en av de databaser som stöds i ClusterControl. Du kan enkelt distribuera, skala, övervaka och göra en massa saker med ClusterControl.

I dag ska vi inte prata om någon av dessa, men vi kommer att diskutera ett av de vanligaste felen för MySQL och möjliga felsökningstips. När vi arbetade med biljetter, mycket tid när vi kontrollerar felrapporterna eller loggarna, såg vi den här raden  "Fick ett fel när vi läste kommunikationspaket" ganska ofta. Vi tror att det skulle vara fördelaktigt om vi skriver en blogg relaterad till detta fel, inte bara för våra kunder utan även för andra läsare. Låt oss inte vänta längre, det är dags att dyka mer!

MySQL Client/Server Protocol

Först och främst måste vi förstå hur MySQL kommunicerar mellan klient och server. Både klient och server använder MySQL-protokoll som implementeras av Connectors, MySQL Proxy och även kommunikationen mellan master- och slavreplikeringsservrar. MySQL-protokollet stöder funktioner som transparent kryptering via SSL, transparent komprimering, en anslutningsfas och samt en kommandofas.

Både heltal och strängar är de grundläggande datatyperna som används i hela MySQL-protokollet. Närhelst MySQL-klienten och servern vill kommunicera med varandra eller skicka data, kommer den att dela upp datan i paket med en maximal storlek på 16MB och även lägga en pakethuvud till varje bit. Inuti varje paket kommer det att finnas en nyttolast som är där datatyperna (heltal/strängar) spelar sina roller.

Med tanke på att CLIENT_PROTOCOL_41 är aktiverat, för nästan varje kommando som klienten skickar till servern, kommer servern att svara något av följande paket som ett svar:

Hur diagnostiseras problemen

Vanligtvis finns det två typer av anslutningsproblem som är kommunikationsfel eller avbrutna anslutningar. Närhelst något av dessa anslutningsproblem inträffar är följande informationskällor en bra utgångspunkt för felsökning och analys:

• Felloggen

• Den allmänna frågeloggen

• Statusvariablerna Aborted_xxx och Connection_errors_xxx

• Värdens cache

Anslutningsfel och möjliga orsaker

I händelse av att anslutningsfel inträffar och beroende på felen, kommer den att öka statusräknaren för antingen Aborted_clients eller Aborted_connects i statusvariablerna. Som hämtat från MySQL-dokumentationen betyder Aborted_clients antalet anslutningar som avbröts eftersom klienten dog utan att stänga anslutningen ordentligt. När det gäller Aborted_connects betyder det antalet misslyckade försök att ansluta till MySQL-servern.

Om du startar MySQL-servern med alternativet --log-warnings, är chansen stor att du förmodligen skulle se exemplet med följande meddelande i din fellogg. Som du märkte sa meddelandet tydligt att det hänför sig till avbrytningsanslutningen, därför kommer statusräknaren för Aborted_connects att ökas i statusvariabeln:

[Varning] Avbruten anslutning 154669 till db:'wordpress' användare:'wpuser' host:'hostname' (Fick ett fel när kommunikationspaket lästes)

Vanligtvis kan misslyckade anslutningsförsök inträffa på grund av följande orsaker. När du märkte detta tyder det möjligen på att en obehörig person är på väg att göra intrång i databasen och du kanske vill titta på den så snart som möjligt:

• En klient har inga privilegier att komma åt databasen.

• Fel autentiseringsuppgifter har använts.

• Ett anslutningspaket som har felaktig information.

• På grund av gränsen för connect_timeout för att ansluta.

Statusvariabeln för Aborted_clients kommer att ökas av servern om en klient lyckas ansluta men blir frånkopplad eller avslutad på ett felaktigt sätt. Utöver det kommer servern också att logga ett meddelande om Avbruten anslutning till felloggen. För denna typ av fel kan det vanligtvis bero på följande orsak:

• Klienten stänger inte anslutningen ordentligt innan den avslutas (anropar inte mysql_close ()).

• Klienten har överskridit wait_timeout eller interactive_timeout sekunder.

• Klientprogrammet eller applikationen slutade plötsligt mitt under dataöverföringen.

Förutom orsakerna tidigare kan andra troliga orsaker till problem med både avbrutna anslutningar och problem med avbrutna klienter vara relaterade till något av följande:

• TCP/IP-konfigurationen trasig.

• Variabelvärdet är för litet för max_allowed_packet.

• Otillräckligt minnestilldelning för frågor.

• Felaktig hårdvara som ethernet, switchar, kablar, etc.

• Problem med trådbiblioteket.

• Duplexsyndromproblem där överföringen går i burst-pause-burst-pause-läge (om du använder Ethernet-protokollet med Linux, både halv och full duplex).

Hur man åtgärdar MySQL-kommunikationsfel

Nu när vi lärde oss många möjligheter som orsakade MySQL-anslutningsfel. Baserat på vår erfarenhet är det här problemet oftast relaterat till brandväggen eller nätverksproblem. Det är också rimligt att säga att det inte är lätt att diagnostisera denna typ av problem. Icke desto mindre kan följande lösning vara till hjälp för dig för att lösa det här felet:

• Om din applikation förlitar sig på wait_timeout för att stänga anslutningen, är det värt att ändra applikationslogiken så att den ordentligt stängd i slutet av en operation.

• Se till att värdet för max_allowed_packet ligger inom det acceptabla intervallet så att klienten inte får något fel relaterat till "paketet för stort".

• För anslutningsfördröjningsproblem som kan bero på DNS, är det värt att kontrollera om du har skip-name- upplösning aktiverad.

• Om du använder en PHP-applikation eller någon annan programmering är det bästa att se till att det inte avbryts anslutningarna som vanligtvis är inställda på max_execution_time.

• Om du märkte många TIME_WAIT-meddelanden från netstat är det värt att bekräfta att anslutningarna hanteras väl på ansökan slut.

• Om du använder Linux och misstänker att problemet beror på nätverket är det bäst att kontrollera nätverksgränssnittet genom att använda ifconfig-a-kommandot och undersök utdata på MySQL-servern för eventuella fel.

• För ClusterControl-användare kan du aktivera revisionslogg från klustret -> Säkerhet -> Granskningslogg. Genom att aktivera den här funktionen kan det hjälpa dig att begränsa dig för att hitta vilken fråga som är boven.

• Nätverksverktyg som tcpdump och Wireshark kan vara användbara för att identifiera potentiella nätverksproblem, tidsgränser och resursproblem för MySQL.

• Kontrollera regelbundet hårdvaran genom att se till att det inte finns några felaktiga enheter, speciellt för Ethernet, hubbar, switchar, kablar etc. Det är värt att byta ut den felaktiga apparaten för att säkerställa att anslutningen är bra hela tiden.

Slutsats

Det finns många anledningar som kanske kan leda till problem med MySQL-anslutningspaket. Närhelst detta problem uppstår kommer det definitivt att påverka verksamheten och den dagliga verksamheten. Även om den här typen av problem inte är lätt att diagnostisera och oftast beror på nätverket eller brandväggen, är det värt att ta hänsyn till alla steg som har föreslagits tidigare för att åtgärda problemet. Vi hoppas verkligen att det här blogginlägget kan hjälpa dig på något sätt, särskilt när du står inför det här problemet.