MySQL-virhelokeissa näen nämä melkoiset varoitukset, kuten nämä:

120611 16:12:30 [Warning] Aborted connection 2619503 to db: "db_name" user: "user_name" host: "webapp_hostname" (Got an error reading communication packets) 

Haven ”ei ole huomannut tietojen menetystä sinänsä, joten mietin, mitä tämä varoitus tarkoittaa tai mikä aiheuttaa sen, ja miten voidaan korjata näiden aiheuttaja. Tämä on RHEL 6.1: llä ja MySQL: llä Enterprise 5.5.

Vastaus

Yksi MySQL-yhteyksien hiljaisista tappajista on MySQL-paketti.

Selvitä ensin, mikä on MySQL-paketti.

MySQL: n sisäisen ymmärtämisen (ISBN 0-596-00957 sivun 99 mukaan -7) , tässä ovat kappaleet 1-3, joissa selitetään MySQL-paketit:

MySQL-verkkoyhteyskoodi kirjoitettiin olettaen, että kyselyt ovat aina kohtuullisen lyhyt, ja siksi palvelin voidaan lähettää ja käsitellä palvelimessa yhdessä osassa, jota kutsutaan MySQL-terminologiassa paketiksi . Palvelin varaa muistin väliaikaiselle puskurille paketin tallentamiseksi, ja se vaatii tarpeeksi, jotta se mahtuu kokonaan. Tämä arkkitehtuuri vaatii varotoimia, jotta vältetään palvelimen muistin loppuminen — paketin koon yläraja, jonka tämä vaihtoehto saavuttaa.

Tähän asetukseen liittyvä kiinnostava koodi löytyy sql / net_serv.cc . Katso my_net_read () ja seuraa kutsua my_real_read () ja kiinnitä erityistä huomiota net_realloc () .

Tämä muuttuja rajoittaa myös monien merkkijonofunktioiden tuloksen pituutta. Katso sql / field.cc ja sql / intem_strfunc.cc lisätietoja.

Tietäen tämän MySQL-paketeista Kehittäjä / DBA voi koota ne niin, että niihin mahtuu useita BLOBeja. yhden paketin sisällä, vaikka ne olisivat vastenmielisesti suuria. Liian pieni paketti aiheuttaa varmasti ongelmia avoimille yhteyksille tässä suhteessa.

mukaan MySQL-dokumentaatio

  • Voit myös saada nämä virheet, jos lähetät virheellisen tai liian kyselyn palvelimelle suuri. Jos mysqld vastaanottaa liian suuren tai epäkunnossa olevan paketin, se olettaa, että asiakkaan kanssa on mennyt pieleen, ja sulkee yhteyden. Jos tarvitset suuria kyselyitä (esimerkiksi jos työskentelet isojen BLOB-sarakkeiden kanssa), voit lisätä kyselyrajaa asettamalla palvelimen max_allowed_packet -muuttujan, jonka oletusarvo on 1MB. Saatat myös joutua lisäämään enimmäismäärää. paketin koko asiakkaan päässä. Lisätietoja paketin koon asettamisesta on kohdassa kohdassa C.5.2.10, ”Paketti on liian suuri”.

  • INSERT- tai REPLACE-käsky, joka lisää paljon rivejä, voi myös aiheuttaa tällaisia virheitä. Kumpikin näistä lauseista lähettää yhden pyynnön palvelimelle lisättävien rivien lukumäärästä riippumatta. ; Näin voit usein välttää virheen vähentämällä lähetettyjen rivien määrää INSERT- tai REPLACE-kohden.

SUOSITUS

Yritä nostaa max_allowed_packet paljon suurempaan määrään, koska oletusarvo on 1M. ld ehdottaa noin 10 kertaa nykyisen tietojoukon suurimman TEXT- tai BLOB-kentän.

Jos haluat asettaa max_allowed_packet -asetukseksi 256M, voit lisätä sen tiedostoihin /etc/my.cnf tai my.ini

[mysqld] max_allowed_packet=256M 

kattamaan mysqldin uudelleenkäynnistykset. Asenna arvo nyt palvelimelle suorittamalla tämä:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Kokeile !!!

Kommentit

  • Erittäin hyvä selitys.
  • @RolandoMySQLDBA Saan edelleen virheitä kohdassa 5.7.28 kokeillessani kaikkia mainittuja ratkaisuja. Vinkkejä vianmääritykseen edelleen

Vastaus

Enimmäkseen oletusarvoisesti max_connections on 100. Yritä lisätä config-parametria / p>

max_connections = 400, kun olet asettanut my.cnf-tiedoston uudelleen, käynnistä palvelin uudelleen tai aseta se dynaamisesti:

 set @@global.max_connections = 400; 

Kokeile vain yllä olevaa suositusta vältä näitä varoitusviestejä ja varmista myös, että verkossasi ei ole pakettipisaroita.

Vastaa

Tapasin tämän ongelman äskettäin siirtyessäni MySQL Enterprise 5.1.x 5.7.x , ilman merkittäviä koodimuutoksia sovelluksessa, alkoi näkyä ” note ”.

Minun tapauksessani ” huomautus ” -näkymän perimmäinen syy oli se, että ohjelma poistui, kun yhteydet olivat vielä auki.Se seikka, että yhteyksiä ei suljettu, oli hieman enemmän mukana eikä liittynyt MySQL: ään, mutta ACE: hen, ketjuihin ja TSS: ään.

Vastaus

Ei mainita tässä, joten otan mukaan tämän ongelman toisen syyn. Minun tapauksessani virheen aiheutti mysql-komentoriviasiakasta käytettäessä interactive_timeout: n 30 sekunnin matala arvo:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Tämä jatkuu koko istunnon ajan, mutta ei palvelimen uudelleenkäynnistystä.

SET GLOBAL interactive_timeout=6000; 

Vastaus

Löysin saman ongelman MariaDB 10.3.24: n kanssa. Vaikuttaa siltä, että varoitus voi tapahtua kaikista yllä olevista syistä ja sitten joistakin. Minun tapauksessani se johtui tietokannan taulukon tietueesta, jossa yhdellä kentällä oli tyhjä sanakirja-arvo.

+ —- + ——– + | id | config | + —- + ——– + | 3 | {} | + —- + ——– +

Testinä vaihdoin ”{}” -asetukseksi ”()” ja se pysäytti viestin. Siinä tapauksessa, että se auttaa jotakuta.

Vastaa

Tämä my.ini-rivi ratkaisi ongelmani:

log_error_verbosity=1 

Viite tämä linkki

Kommentit

  • En ' usko, että olet ratkaissut taustalla olevan ongelman, mutta yksinkertaisesti estänyt sen kirjaamisen.
  • Minulla oli sama viesti ilmoitettuna " Huomaa ". Log_error_verbosity = 2: n käyttö todella ratkaisee " -ongelman " (mutta " Varoitus " tulee osoittaa, ei jättää huomiotta)

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *