W dziennikach błędów MySQL widzę kilka takich ostrzeżeń:
120611 16:12:30 [Warning] Aborted connection 2619503 to db: "db_name" user: "user_name" host: "webapp_hostname" (Got an error reading communication packets) Nie zauważyłem żadnej utraty danych jako takiej, więc zastanawiam się, co oznacza to ostrzeżenie lub co je powoduje i czy można rozwiązać problem, który je powoduje. Dotyczy to RHEL 6.1 i MySQL Enterprise 5.5.
Odpowiedź
Jednym z cichych zabójców MySQL Connections jest pakiet MySQL.
Najpierw zastanówmy się, czym jest pakiet MySQL.
Zgodnie z stroną 99 w „Understanding MySQL Internals” (ISBN 0-596-00957 -7) , oto akapity 1-3 wyjaśniające pakiety MySQL:
Kod komunikacji sieciowej MySQL został napisany przy założeniu, że zapytania są zawsze dość krótki, dlatego może być wysłany do serwera i przetworzony przez niego w jednej porcji, która w terminologii MySQL nazywana jest pakietem . Serwer przydziela pamięć na tymczasowy bufor do przechowywania pakietu i żąda ilości wystarczającej do całkowitego dopasowania. Ta architektura wymaga środków ostrożności, aby uniknąć sytuacji, w której serwerowi zabraknie pamięci — ograniczenie rozmiaru pakietu, które realizuje ta opcja.
Kod, który nas interesuje w odniesieniu do tej opcji, znajduje się w sql / net_serv.cc . Przyjrzyj się my_net_read () , a następnie wykonaj wywołanie do my_real_read () i zwróć szczególną uwagę na net_realloc () .
Ta zmienna ogranicza również długość wyniku działania wielu funkcji łańcuchowych. Zobacz sql / field.cc i sql / intem_strfunc.cc , aby uzyskać szczegółowe informacje.
Wiedząc o pakietach MySQL, programiści / DBA mogą je dopasować do wielu BLOB w jednym pakiecie, nawet jeśli są okropnie duże. Zdecydowanie zbyt mały pakiet spowoduje problemy dla otwartych połączeń pod tym względem.
Zgodnie z Dokumentacja MySQL
-
Możesz również otrzymać te błędy, jeśli wyślesz zapytanie do serwera, które jest nieprawidłowe lub zbyt duży. Jeśli mysqld otrzyma pakiet, który jest zbyt duży lub uszkodzony, zakłada, że coś poszło nie tak z klientem i zamyka połączenie. Jeśli potrzebujesz dużych zapytań (na przykład, jeśli pracujesz z dużymi kolumnami BLOB), możesz zwiększyć limit zapytań, ustawiając zmienną max_allowed_packet serwera, która ma domyślną wartość 1 MB. Może być również konieczne zwiększenie maksymalnej rozmiar pakietu po stronie klienta. Więcej informacji na temat ustawiania rozmiaru pakietu znajduje się w Sekcji C.5.2.10, „Pakiet za duży”.
-
Instrukcja INSERT lub REPLACE, która wstawia bardzo wiele wierszy, również może powodować tego rodzaju błędy. Każda z tych instrukcji wysyła pojedyncze żądanie do serwera, niezależnie od liczby wstawianych wierszy ; w ten sposób często można uniknąć błędu, zmniejszając liczbę wierszy wysyłanych na WSTAWIENIE lub WYMIENIENIE.
ZALECENIE
Spróbuj zwiększyć max_allowed_packet na znacznie większą liczbę, ponieważ wartość domyślna to 1 mln. ld sugeruje około 10 razy większe pole TEXT lub BLOB, które masz w bieżącym zbiorze danych.
Aby ustawić max_allowed_packet na 256M, możesz dodać go do /etc/my.cnf lub my.ini
[mysqld] max_allowed_packet=256M na wypadek przyszłych ponownych uruchomień mysqld. Aby zainstalować wartość teraz na serwerze, uruchom to:
SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; Spróbuj !!!
Komentarze
- Bardzo dobre wyjaśnienie.
- @RolandoMySQLDBA Nadal otrzymuję błąd w wersji 5.7.28 po wypróbowaniu wszystkich wymienionych rozwiązań. Wszelkie wskazówki dotyczące dalszego rozwiązywania problemów
Odpowiedź
Zwykle domyślnie max_connections będzie wynosić 100. Spróbuj zwiększyć parametr konfiguracyjny
max_connections = 400, po ustawieniu w my.cnf zrestartuj serwer lub ustaw go dynamicznie:
set @@global.max_connections = 400; Po prostu wypróbuj powyższe zalecenie, aby unikaj tych komunikatów ostrzegawczych, a także upewnij się, że w Twojej sieci nie ma porzuconych pakietów.
Odpowiedź
Niedawno napotkałem ten problem po przejściu z MySQL Enterprise 5.1.x do 5.7.x , bez znaczących zmian w kodzie aplikacji zaczęła się pojawiać „ uwaga ”.
W moim przypadku główną przyczyną pojawienia się „ notatki ” był program kończący pracę z wciąż otwartymi połączeniami.Okoliczność, że połączenia nie były zamykane, była nieco bardziej skomplikowana i nie dotyczyła MySQL, ale ACE, wątków i TSS.
Odpowiedź
Nie wspomniano tutaj, więc dołączam inną przyczynę tego problemu. W moim przypadku podczas korzystania z klienta wiersza poleceń mysql błąd był spowodowany niską wartością 30 sekund interactive_timeout:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Utrzymuje się to w sesjach, ale nie podczas restartu serwera.
SET GLOBAL interactive_timeout=6000; Odpowiedź
Napotkałem ten sam problem w MariaDB 10.3.24. Wygląda na to, że Ostrzeżenie może wystąpić z wszystkich powyższych powodów, a także z niektórych. W moim przypadku było to spowodowane zapisem w jednej z tabel bazy danych, który miał pustą wartość słownikową dla jednego z pól.
+ —- + ——– + | id | config | + —- + ——– + | 3 | {} | + —- + ——– +
W ramach testu zmieniłem „{}” na „()” i to zatrzymało wiadomość. Na wszelki wypadek, gdyby to komuś pomogło.
Odpowiedź
Ta linia my.ini rozwiązała mój problem:
log_error_verbosity=1 Odniesienie ten link
Komentarze
- Nie ' nie sądzę, że rozwiązałeś podstawowy problem, ale po prostu przestałem go rejestrować.
- Ten sam komunikat był zgłaszany jako " Uwaga ". Używanie log_error_verbosity = 2 w rzeczywistości rozwiązuje " problem " (ale " Ostrzeżenie " należy adresować, a nie ignorować)