Błąd 2006 (HY000): serwer MySQL zniknął

Możesz zwiększyć maksymalny dozwolony Pakiet

SET GLOBAL max_allowed_packet=1073741824;

Http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

Global update I my.ustawienia cnf nie działały dla mnie z jakiegoś powodu. Przekazywanie wartości max_allowed_packet bezpośrednio do klienta działało tutaj:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

Ogólnie błąd:

Błąd: 2006 (CR_SERVER_GONE_ERROR) - serwer MySQL zniknął

Oznacza, że klient nie mógł wysłać pytania do serwera.

mysql import

W konkretnym przypadku podczas importowania pliku bazy danych za pomocą mysql, najprawdopodobniej oznacza to, że niektóre zapytania w pliku SQL są zbyt duże, aby je zaimportować i nie można ich było wykonać na serwerze, dlatego klient nie powiedzie się po pierwszym wystąpieniu błąd.

Więc masz następujące możliwości:

• Dodaj opcję force (-f) dla mysql, aby kontynuować i wykonać resztę zapytań.

  Jest to przydatne, jeśli baza danych ma kilka dużych zapytań związanych z pamięcią podręczną, które i tak nie są istotne.

• Zwiększ max_allowed_packet i wait_timeout w konfiguracji serwera (np. ~/.my.cnf).

• Zrzut bazy danych za pomocą opcji --skip-extended-insert, aby rozbić duże zapytania. Następnie zaimportuj go jeszcze raz.

• Spróbuj zastosować opcję --max-allowed-packet dla mysql.

Wspólne powody

Ogólnie ten błąd może oznaczać kilka rzeczy, takich jak:

• Nie jest to jednak żaden problem.]}

  Rozwiązanie: zwiększ max_allowed_packet zmienną.

  • Upewnij się, że zmienna znajduje się w sekcji [mysqld], a nie [mysql].

  • Nie bój się używać dużych liczb do testowania (jak 1G).

  • Nie zapomnij ponownie uruchomić serwera MySQL / MariaDB.

  • Sprawdź dokładnie, czy wartość została ustawiona poprawnie przez:

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"
    

• Masz limit czasu połączenia TCP / IP po stronie klienta.

  Rozwiązanie: zwiększ wait_timeout zmienną .

• Próbowano uruchomić zapytanie po zamknięciu połączenia z serwerem.

  Rozwiązanie: błąd logiczny w aplikacji powinien być poprawione.

• Nie powiodło się wyszukiwanie nazwy hosta (np. problem z serwerem DNS) lub serwer został uruchomiony z opcją --skip-networking.

  Inną możliwością jest to, że firewall blokuje port MySQL (np. 3306 domyślnie).

• Wątek został zabity, więc spróbuj ponownie.

• Napotkałeś błąd, w którym serwer umarł podczas wykonywania zapytania.

• Klient działający na innym hoście nie ma niezbędne uprawnienia do połączenia.

• I wiele innych, więc dowiedz się więcej na: B. 5.2. 9 serwer MySQL zniknął.

Debugowanie

• Sprawdź dzienniki, np.

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")
  

• Przetestuj połączenie poprzez mysql, telnet lub funkcji ping (np. mysql_ping w PHP).

• Użyj tcpdump, aby powąchać komunikację MySQL (nie będzie działać dla socket połączenie), np.:

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings
  

• W Linuksie użyj strace. Na BSD / Mac use dtrace/dtruss, np.

  sudo dtruss -a -fn mysqld 2>&1
  

  Zobacz: pierwsze kroki z Dtracingiem MySQL

Dowiedz się więcej jak debugować serwer lub klienta MySQL pod adresem: 26.5 debugowanie i przenoszenie MySQL.

W celach informacyjnych, sprawdź kod źródłowy w sql-common/client.c plik odpowiedzialny za wywołanie błędu CR_SERVER_GONE_ERROR dla polecenia klienta.

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

Rozwiązałem błąd ERROR 2006 (HY000) at line 97: MySQL server has gone away i pomyślnie przeprowadziłem migrację pliku sql > 5GB, wykonując te dwa kroki w kolejności:

1. Created / etc / my.cnf zgodnie z zaleceniami innych, o następującej treści:

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE
   

2. Dołączanie znaczników --force --wait --reconnect do komendy (tj. mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Ważna uwaga: konieczne było wykonanie obu kroków, ponieważ gdybym nie zawracał sobie głowy wprowadzaniem zmian w /etc / my.pliku cnf, a także dołączanie tych flag, niektóre tabele zaginęły po imporcie.

Używany System: OSX El Capitan 10.11.5; mysql ver 14.14 Distrib 5.5.51 dla osx10. 8 (i386)

Na wszelki wypadek, aby sprawdzić zmienne możesz użyć

$> mysqladmin variables -u user -p 

To wyświetli bieżące zmienne, w tym przypadku max_allowed_packet, i jak ktoś powiedział w innej odpowiedzi, możesz ustawić go tymczasowo za pomocą

mysql> SET GLOBAL max_allowed_packet=1072731894

W moim przypadku plik cnf nie był brany pod uwagę i nie wiem dlaczego, więc zestaw globalnego kodu naprawdę pomógł.

Możesz również zalogować się do bazy danych jako root (lub SUPER privilege) i zrobić

set global max_allowed_packet=64*1024*1024;

Nie wymaga również ponownego uruchamiania MySQL. Zauważ, że powinieneś naprawić swój plik my.cnf, jak opisano w innych rozwiązaniach:

[mysqld]
max_allowed_packet=64M

I Potwierdź zmianę po ponownym uruchomieniu MySQL:

show variables like 'max_allowed_packet';

Możesz również użyć wiersza poleceń, ale może to wymagać aktualizacji skryptów start/stop, które mogą nie przetrwać aktualizacji systemu i łat.

zgodnie z życzeniem, dodaję własną odpowiedź proszę. cieszę się, że to działa!

Rozwiązaniem jest zwiększenie wartości podanych parametrów wait_timeout i connect_timeout w pliku options, pod tagiem [mysqld].

Musiałem odzyskać kopię zapasową mysql 400MB i to działało dla mnie (wartości, których użyłem poniżej są nieco przesadzone, ale rozumiesz o co chodzi):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

Blockquote

Miałem ten sam problem, ale zmieniłem max_allowed_packet w my.ini / my.plik cnf pod [mysqld] zrobił sztuczkę.

Dodaj wiersz

max_allowed_packet=500M

Teraz uruchom ponownie usługę MySQL po zakończeniu.

Kilka rzeczy może się tu dziać;

• Twój INSERT działa długo, a Klient się rozłącza. Po ponownym połączeniu nie wybiera bazy danych, stąd błąd. Jedną z opcji jest uruchomienie pliku wsadowego z wiersza poleceń i wybranie bazy danych w argumentach, w ten sposób;

$ mysql db_name

• innym jest uruchomienie komendy za pomocą php lub innego języka. Po każdym długotrwałym wyciągu można zamknąć i ponownie otwórz połączenie, upewniając się, że jesteś połączony na początku każdego zapytania.

Jeśli jesteś na Macu i zainstalowałeś mysql przez brew jak ja, poniższe działanie.

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

Source: for homebrew mysql installs, where ' s my.cnf?

1. Dodaj max_allowed_packet=1073741824 do /usr/local/etc/my.cnf

2. mysql.server restart

Napotkałem ten błąd, gdy używam klastra Mysql, Nie wiem, czy to pytanie pochodzi z użycia klastra, czy nie. Ponieważ błąd jest dokładnie taki sam, więc podaj moje rozwiązanie tutaj. Uzyskanie tego błędu, ponieważ węzły danych nagle ulegają awarii. Ale gdy węzły ulegną awarii, nadal możesz uzyskać poprawny wynik za pomocą cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

I mysqld również działa correctly.So na początku nie mogę zrozumieć, co jest nie tak. I około 5 minut później, wynik ndb_mgm nie pokazuje żadnego węzła danych działającego. Wtedy zdaję sobie sprawę, że problem. Spróbuj ponownie uruchomić wszystkie węzły danych, a następnie serwer mysql wróci i wszystko jest w porządku.

Ale jedno jest dla mnie dziwne, po utracie serwera mysql dla niektórych zapytań, gdy używam cmd jak show tables, nadal mogę uzyskać informacje zwrotne jak 33 rows in set (5.57 sec), ale nie wyświetla się żadna informacja tabeli.

Ten Komunikat o błędzie pojawia się również, gdy tworzysz schemat z innym zestawieniem niż ten, który jest używany w zrzucie. Tak więc, jeśli zrzut zawiera

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Należy to również odzwierciedlić w zestawieniu schematu:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Używałem utf8mb4_general_ci w schemacie, ponieważ mój skrypt pochodził ze świeżej instalacji V8, teraz Ładowanie DB na Starym 5.7 rozbił się i doprowadzał mnie prawie do szaleństwa.

(MacOS 10.3, mysql 5.7)

Jeśli jest ponowne podłączenie i uzyskanie connection ID 2, Serwer prawie na pewno się rozbił.

Skontaktuj się z administratorem serwera i poproś go o zdiagnozowanie problemu. Żaden nie złośliwy SQL nie powinien zawieszać serwera, a wyjście mysqldump z pewnością nie powinno.

Jest to prawdopodobnie przypadek, że administrator serwera popełnił jakiś duży błąd operacyjny, taki jak przypisanie wielkości buforów większych niż ograniczenia przestrzeni adresowej architektury lub więcej niż pojemność pamięci wirtualnej. Na MySQL error-log prawdopodobnie będzie zawierał pewne istotne informacje; będą to monitorować, jeśli i tak będą kompetentni.

Jest to raczej rzadki problem, ale widziałem to, jeśli ktoś skopiował cały katalog/var/lib / mysql jako sposób na migrację ich DB na inny serwer. Powodem, dla którego nie działa, jest to, że baza danych była uruchomiona i używała plików dziennika. Czasami nie działa, jeśli są logi w /var/log / mysql. Rozwiązaniem jest również skopiowanie plików/var/log / mysql.

Dla amazon RDS (to mój przypadek), możesz zmienić wartość parametru max_allowed_packet Na dowolną wartość liczbową w bajtach, która ma sens dla największych danych w dowolnym insercie, który możesz mieć (np.: jeśli masz jakieś 50MB wartości blob w swojej insercie, Ustaw max_allowed_packet Na 64M = 67108864), w Nowym lub istniejącym parameter-group. Następnie zastosuj ten parametr-group do instancji MySQL(może wymagać ponownego uruchomienia instancji).

Dla użytkowników Drupal 8 szukających rozwiązania dla błędu importu DB:

Na końcu pliku zrzutu sql mogą być polecenia wstawiające dane do tabeli "webprofiler". To chyba jakiś plik dziennika debugowania i nie jest naprawdę ważne, aby strona działała, więc wszystko to można usunąć. Usunąłem wszystkie te wstawki, w tym blokady tabel i odblokować tabele (i wszystko między). Jest na samym dole pliku sql. Problem jest opisany tutaj:

Https://www.drupal.org/project/devel/issues/2723437

Ale nie ma na to rozwiązania poza obcinaniem tej tabeli.

BTW próbowałem wszystkich rozwiązań z powyższych odpowiedzi i nic więcej nie pomogło.

Próbowałem wszystkich powyższych rozwiązań, wszystkie zawiodły.

Skończyło się na użyciu -h 127.0.0.1 zamiast domyślnego var/run/mysqld/mysqld.sock.

Jeśli wypróbowałeś wszystkie te rozwiązania, esp. zwiększenie max_allowed_packet do maksymalnej obsługiwanej ilości 1GB i nadal widzisz te błędy, może się zdarzyć, że twój serwer dosłownie nie ma wystarczającej ilości wolnej pamięci RAM...

Rozwiązanie = Uaktualnij serwer do większej ilości pamięci RAM i spróbuj ponownie.

Uwaga: dziwię się, że to proste rozwiązanie nie zostało wspomniane po ponad 8 latach dyskusji w tym wątku... czasami deweloperzy mają tendencję do nadmiernego myślenia.

Jeśli żadna z tych odpowiedzi nie rozwiąże problemu, rozwiązałem go usuwając tabele i tworząc je ponownie automatycznie w ten sposób:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

Następnie po prostu użyj tej kopii zapasowej z db i usunie i odtworzy tabele, których potrzebujesz.

Następnie wykonujesz kopię zapasową tylko danych i robisz to samo, a to zadziała.

Jak o użyciu klienta mysql w ten sposób:

mysql -h <hostname> -u username -p <databasename> < file.sql