Puncte:0

Eroare generală: 2006 Serverul MySQL a dispărut. Toate setarile in regula

drapel it

Am 2 servere linux. 1 rulează apache2 cu o aplicație PHP, iar celălalt rulează mysql 5.7. (deci o conexiune la distanță la DB)

Aplicațiile PHP au încercat să creeze un BIGBLOB dintr-un fișier (90MB) și să îl stocheze în SQL.

Dar primesc aceste erori: (Acest lucru se întâmplă doar pe un BLOB MAI MARE) PHP:

[PDOException] SQLSTATE[HY000]: Eroare generală: 2006 Serverul MySQL a dispărut

MYSQL:

2022-03-24T14:22:41.443626Z 268701 [Notă] Conexiune întreruptă 268701 la db: „bug” utilizator: „utilizator” gazdă: „subdomain.hostname.com” (A apărut o eroare la citirea pachetelor de comunicare)

Am căutat pe internet. Am făcut următoarele actualizare: max_allowed_packet la 1 GB, Am verificat: wait_timeout și interactive_timeout sunt în regulă (28880 secunde) Am adăugat memorie SWAP. Nimic nu funcționează. Vreo idee?

P.S: Se pare că conexiunea se întrerupe undeva după 30 de secunde. dar nu pot spune sigur și de ce.

Acestea sunt setările MySQL:

mysql> arată variabile globale precum „%timeout%”;
+-----------------------------+----------+
| Nume_variabilă | Valoare |
+-----------------------------+----------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| have_statement_timeout | DA |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 120 |
| net_write_timeout | 120 |
| rpl_stop_slave_timeout | 31536000 |
| slave_net_timeout | 60 |
| wait_timeout | 28800 |
+-----------------------------+----------+

 pachet_max_permis | 1073741824 |

RAM:

              total folosit gratuit partajat buff/cache disponibil
Mem: 7976 1056 256 1 6663 6630
Schimb: 10239 8 10231
Wilson Hauck avatar
drapel jp
Ați putea posta TEXT din ultimele 50 de rânduri ale jurnalului de erori din instanța „eșuată”?
Wilson Hauck avatar
drapel jp
Aceasta ar putea fi o adresă URL utilă de examinat, cu multe cauze posibile enumerate. https://severalnines.com/database-blog/common-mysql-error-got-error-reading-communication-packet
sav1sav avatar
drapel it
Ce jurnal de erori exact :)? De asemenea, am verificat acel link înainte. Nu a ajutat.
Wilson Hauck avatar
drapel jp
Rulați SELECT @@log_error; conținutul este locul unde este numit fișierul.
drapel ua
Să vedem VARIABILELE „%size”.
drapel ua
5.7 a fost lansat în 2016; care este relevanța „2006”?
drapel ua
Acesta ar trebui să fie migrat la dba.stackexchange.com
Puncte:0
drapel ua

„Dispărut” este de obicei cauzat de o interogare foarte lungă care depășește o anumită setare. Totuși, aceasta miroase a o problemă diferită. Dimensiunea implicită pentru citirea unui rând este de doar câțiva MB. În plus, cred că există o limită strictă de 16 MB. Adică, creșterea „..._size” nu va fi suficientă.

Ce vei face cu un BLOB de 90 MB? Luați în considerare să-l lăsați într-un fişierși puneți meta informații în baza de date. Chiar și pentru jpeg-uri de dimensiunea MB, acest lucru este mai practic și mai eficient decât să găsești într-o bază de date.

Discutați în continuare BLOB, plus furnizați AFIȚI CREATE TABLE și unele dintre interogările pe care intenționați să le utilizați. Atunci s-ar putea să am un sfat suplimentar.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.