MySQL: Błąd odczytu pakietów komunikacyjnych

14

Dostaję to ostrzeżenie w mysql,

[Warning] Aborted connection 21 to db: 'MyDB' user: 'MyUser' host: 'localhost' (Got an error reading communication packets)

Przejrzałem kilka tematów w google i według niektórych sugestii zwiększyłem max_allowed_packetz 128 to 512 to 1024wciąż tego samego zachowania.

Używam Drupal 7, i tak istnieje wiele typów danych kropelka, ale 1024 Mbod max_allowed_packetpowinna być na tyle moim zdaniem.

Jakieś inne obejście, jak pokonać to ostrzeżenie?

EDYTOWAĆ:

Dodano niektóre ustawienia jako sugestie / odpowiedzi @ Rolando, nadal otrzymuję to samo ostrzeżenie.

Moja konfiguracja mysql wygląda następująco:

[client]
port        = 3306
socket      = /tmp/mysql.sock
default-character-set = utf8

[mysqld]
port        = 3306
socket      = /tmp/mysql.sock
skip-external-locking
key_buffer_size = 16K 
max_allowed_packet = 1024M 
table_open_cache = 128 
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 192K
# Query cache disabled
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 100
thread_concurrency = 10
tmp_table_size = 128M
max_heap_table_size = 128M
log_error                = /var/log/mysql/mysql-error.log
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 2

log_warnings = 2

server-id   = 1
binlog-format = row
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1
log_bin = mysql-bin
log-slave-updates
relay-log=mysqld-relay-bin
expire_logs_days        = 10
max_binlog_size         = 100M

innodb_data_home_dir = /var/db/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/db/mysql
innodb_buffer_pool_size = 8G
character-set-server = utf8
#innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 2047M
innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 8
innodb_lock_wait_timeout = 50
innodb_flush_method = O_DIRECT

[mysqldump]
quick
quote-names
max_allowed_packet = 16M
default-character-set = utf8

[mysql]
default-character-set = utf8

[myisamchk]
key_buffer_size = 32M
sort_buffer_size = 32M

[mysqlhotcopy]
interactive-timeout

[mysqld_save]
syslog

Moja aplikacja korzysta tylko z InnoDB, ale istnieje niewiele baz danych, takich jak mysql, które są dostarczane ze standardowymi instalacjami mysql. Są to tylko te, które używają silnika MyISAM, ale chyba nie powinienem się tym przejmować.

Jak widać, mam również replikację, ostrzeżenie jest takie samo jak na replikowanym serwerze, którego konfiguracja jest identyczna jak ta.


źródło
Czy wszystkie twoje stoły to InnoDB?
RolandoMySQLDBA
@RolandoMySQLDBA, Cześć, Tak, wszystkie tabele są innodb, zrobiłem zgodnie z twoją odpowiedzią na inne pytanie takie jak to na tej stronie, ale wciąż otrzymuję ostrzeżenie.
@RolandoMySQLDBA, zredagowałem swoje pytanie i zrobiłem to, co zasugerowałeś, wciąż otrzymuję to ostrzeżenie. Mam tutaj mysql.cnf, czy mógłbyś rzucić na to okiem, być może czegoś brakuje
Zacząłem otrzymywać ten błąd na MySQL 5.5.35 z Drupalem 6. Nigdy nie zrozumiałem problemu, ale zniknął po aktualizacji do 5.7.7. Teraz powrócił z 5.7.9. Wyizolowałem zapytanie wstawiania (mniej niż 6000 znaków tekstu), które kończy się w 5.7.7, ale powoduje przerwanie w 5.7.9. Nie udaje się to tylko wtedy, gdy jest wykonywane zdalnie, a nie lokalnie. Tak więc, ten sam klient, obie wersje serwera działające obok siebie na tym samym komputerze, ten sam tryb sql_mode, ten sam zestaw znaków, ogromny max_allowed_packet. Jestem lisa. Czy kiedykolwiek to rozwiązałeś?
user19292

Odpowiedzi:

10

Cieszę się, że powiedziałeś, że wszystkie twoje dane to InnoDB, więc mogę odpowiedzieć w następujący sposób: Jeśli max_allowed_packet jest maksymalny przy 1G i nadal masz problemy, tak naprawdę są tylko dwa miejsca:

  1. innodb_log_buffer_size : rozmiar w bajtach bufora używanego przez InnoDB do zapisywania w plikach dziennika na dysku. Wartość domyślna to 8 MB. Duży bufor dziennika pozwala na uruchamianie dużych transakcji bez konieczności zapisywania dziennika na dysku przed zatwierdzeniem transakcji. Tak więc, jeśli masz duże transakcje, zwiększenie bufora dziennika oszczędza dyskowe operacje we / wy.
  2. innodb_log_file_sile : Rozmiar w bajtach każdego pliku dziennika w grupie dziennika. Łączny rozmiar plików dziennika musi być mniejszy niż 4 GB. Wartość domyślna to 5 MB. Rozsądne wartości wynoszą od 1 MB do 1 / N-tej wielkości puli buforów, gdzie N jest liczbą plików dziennika w grupie. Im większa wartość, tym mniejsza potrzeba opróżniania punktu kontrolnego w puli buforów, co oszczędza dyskowe operacje we / wy. Ale większe pliki dziennika oznaczają również, że odzyskiwanie jest wolniejsze w przypadku awarii.

Zajmowałem się czymś około 2 lata temu

PROPOZYCJE

Musisz zwiększyć dzienniki transakcji InnoDB . Oto kroki, aby bezpiecznie zwiększyć innodb_log_buffer_size i innodb_log_file_sile :

Krok 01: Dodaj je do /etc/my.cnf

[mysqld]
innodb_log_buffer_size = 32M
innodb_log_file_size = 2047M

Krok 02: Uruchom to w mysql

mysql> SET GLOBAL innodb_fast_shutdown = 0;

Krok 03: Zamknij mysql

service mysql stop

Krok 04: Odsuń stare dzienniki na bok

mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

Krok 05: Uruchom mysql

service mysql start

Otóż ​​to.

Infrastruktura InnoDB powinna teraz mieć wystarczającą ilość miejsca do rejestrowania dla obiektów BLOB o różnych rozmiarach.

Spróbuj !!!

RolandoMySQLDBA
źródło
Dziękuję bardzo za odpowiedź, edytowałem moje pytanie, aby dodać mysql.cnfplik. Zrobiłem tak, jak sugerowałeś, ale wciąż otrzymuję ostrzeżenia. Widzę max_allowed_packetw mysqldumpto tylko 16Mb, ale myślę, że nie jest przyczyną. key_buffer_sizejest po prostu 16Kbi znowu powinno być coś z tym MyISAMi nie używam MyISAMsilnika pamięci masowej w aplikacji.
Ponadto - dla każdego, kto napotka taki problem podczas pracy z serwerem Apache, musiałem zrestartować tę usługę. Dziękuję bardzo za to - nie miałem pojęcia.
dgo
1

Po przeczytaniu komentarza @ user19292 w styczniu '16 na temat tego starego pytania zaktualizowałem wersję z 5.7.9 do 5.7.12 i problem zniknął.

IsraelWebDev
źródło
2
Używam 5.7.23 i mam ten sam problem
Jesus Uzcanga,
1
To samo dotyczy błędu z 5.7.26. W twoim przypadku aktualizacja prawdopodobnie również resetuje konfiguracje, więc mogło to rozwiązać Twój problem.
Sliq
0

Właśnie spędziłem około 5-6 godzin zmieniając opcje i wypróbowując różne wersje MySQL, zawsze dostaję błąd.

Myślę, że to edredon, ponieważ:

  • mój kod PHP nie zamyka poprawnie połączenia db (jest to ostrzeżenie, nie błąd) mysql_close()lub równoważny.
  • lub ponieważ serwer pamięci podręcznej / serwera proxy nginx jest skonfigurowany do zamykania połączenia, jeśli klient je zamknął, serwer pamięci podręcznej / serwera proxy nie czeka na serwer źródłowy (gdzie jest również mysql).
adrianTNT
źródło