BŁĄD 2006 (HY000): Serwer MySQL zniknął

Ten błąd pojawia się, gdy próbuję pobrać duży plik SQL (duże INSERTzapytanie).

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

Nic w tabeli nie jest aktualizowane. Próbowałem usunąć i usunąć tabelę / bazę danych, a także ponownie uruchomić MySQL. Żadna z tych rzeczy nie rozwiązuje problemu.

Oto mój maksymalny rozmiar pakietu:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

Oto rozmiar pliku:

$ ls -s file.sql 
79512 file.sql

Kiedy próbuję innej metody ...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

Dodanie tej linii do my.cnfpliku rozwiązuje mój problem.

Jest to przydatne, gdy kolumny mają duże wartości, które powodują problemy, wyjaśnienie znajdziesz tutaj .

W systemie Windows ten plik znajduje się w: „C: \ ProgramData \ MySQL \ MySQL Server 5.6”

W systemie Linux (Ubuntu): / etc / mysql

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

Globalna aktualizacja i ustawienia my.cnf z jakiegoś powodu nie działały dla mnie. Przekazywanie max_allowed_packetwartości 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 może wysłać pytania do serwera .

mysql import

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

Masz więc następujące możliwości:

• Dodaj opcję siły ( -f) dlamysql aby kontynuować i wykonać pozostałe zapytania.

  Jest to przydatne, jeśli baza danych zawiera duże zapytania związane z pamięcią podręczną, które i tak nie są istotne.

• Zwiększ max_allowed_packetiwait_timeout w konfiguracji serwera (np ~/.my.cnf.).

• Zrzuć bazę danych, używając --skip-extended-insertopcji, aby rozbić duże zapytania. Następnie zaimportuj go ponownie.

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

Najczęstsze powody

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

• zapytanie do serwera jest nieprawidłowe lub zbyt duże,

  Rozwiązanie: Zwiększ max_allowed_packetzmienną .

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

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

  • Nie zapomnij zrestartować serwera MySQL / MariaDB.

  • Dokładnie sprawdź, czy wartość została ustawiona poprawnie przez:

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

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

  Rozwiązanie: Zwiększ wait_timeoutzmienną .

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

  Rozwiązanie: Błąd logiczny w aplikacji powinien zostać poprawiony.

• Wyszukiwanie nazw hosta nie powiodło się (np. Problem z serwerem DNS) lub serwer został uruchomiony z --skip-networkingopcją.

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

• Bieżący wątek został zabity, więc spróbuj ponownie.

• Wystąpił błąd, w wyniku którego serwer zmarł podczas wykonywania zapytania.

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

• I wiele innych, więc dowiedz się więcej na: B.5.2.9 Serwer MySQL odszedł .

Debugowanie

Oto kilka pomysłów debugowania na poziomie eksperckim:

• Sprawdź dzienniki, np

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

• Sprawdzić swoje połączenie przez mysql, telnetlub funkcji ping (np mysql_pingw PHP).

• Służy tcpdumpdo wąchania komunikacji MySQL (nie działa w przypadku połączenia przez gniazdo), np .:

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

• W systemie Linux użyj strace. Na BSD / Mac użyj dtrace/ dtruss, np

  sudo dtruss -a -fn mysqld 2>&1

  Zobacz: Rozpoczęcie pracy z DTracing MySQL

Dowiedz się więcej o debugowaniu serwera lub klienta MySQL pod adresem: 26.5 Debugowanie i przenoszenie MySQL .

W sql-common/client.ccelach informacyjnych sprawdź kod źródłowy w pliku odpowiedzialnym za zgłoszenie CR_SERVER_GONE_ERRORbłędu 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;
}

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

$> mysqladmin variables -u user -p 

Spowoduje to wyświetlenie bieżących zmiennych, w tym przypadku max_allowed_packet, i jak ktoś powiedział w innej odpowiedzi, możesz ustawić je tymczasowo za pomocą

mysql> SET GLOBAL max_allowed_packet=1072731894

W moim przypadku plik cnf nie został uwzględniony i nie wiem dlaczego, więc kod SET GLOBAL naprawdę pomógł.

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

1. Utworzono /etc/my.cnf, jak zalecili inni, z następującą zawartością:

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

2. Dołączanie flag --force --wait --reconnectdo polecenia (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ż jeśli nie zawracałem sobie głowy wprowadzaniem zmian do pliku /etc/my.cnf, a także dodawaniem tych flag, niektórych tabel brakowało po imporcie.

Zastosowany system: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 dla osx10.8 (i386)

Miałem ten sam problem, ale zmiana max_allowed_packet w pliku my.ini / my.cnf w [mysqld] załatwiła sprawę.

dodaj linię

max_allowed_packet=500M

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

Możesz także zalogować się do bazy danych jako root (lub uprawnienia SUPER) i zrobić

set global max_allowed_packet=64*1024*1024;

nie wymaga również ponownego uruchomienia MySQL. Pamiętaj, że powinieneś naprawić my.cnfplik zgodnie z opisem w innych rozwiązaniach:

[mysqld]
max_allowed_packet=64M

I potwierdź zmianę po ponownym uruchomieniu MySQL:

show variables like 'max_allowed_packet';

Możesz także użyć wiersza polecenia, ale może to wymagać aktualizacji skryptów start / stop, które mogą nie przetrwać aktualizacji systemu i poprawek.

Zgodnie z życzeniem dodaję tutaj własną odpowiedź. Cieszę się, że to działa!

Rozwiązaniem jest zwiększenie wartości podanych wait_timeouti connect_timeoutparametrów w pliku opcji w obszarze[mysqld] znacznikiem.

Musiałem odzyskać 400 MB kopii zapasowej mysql i to zadziałało dla mnie (wartości, których użyłem poniżej, są nieco przesadzone, ale masz rację):

[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

Zablokować cytat

Może się tu zdarzyć kilka rzeczy;

• Twój INSERTdziała długo, a klient się rozłącza. Po ponownym połączeniu nie wybiera bazy danych, stąd błąd. Jedną z opcji jest tutaj uruchomienie pliku wsadowego z wiersza poleceń i wybranie bazy danych w argumentach, tak jak to;

$ mysql nazwa_db <source.sql

• Innym jest uruchomienie polecenia za pośrednictwem phplub innego języka. Po każdej długo działającej instrukcji możesz zamknąć i ponownie otworzyć połączenie, upewniając się, że jesteś podłączony na początku każdego zapytania.

Jeśli korzystasz z komputera Mac i zainstalowałeś mysql przez brew tak jak ja, działało to.

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

Źródło: W przypadku instalacji homebrew mysql, gdzie jest my.cnf?

2. dodaj max_allowed_packet=1073741824do/usr/local/etc/my.cnf

3. mysql.server restart

Wystąpił ten błąd podczas korzystania z klastra Mysql, nie wiem, czy to pytanie dotyczy użycia klastra, czy nie. Ponieważ błąd jest dokładnie taki sam, więc podaj moje rozwiązanie tutaj. Występuje ten błąd, ponieważ nagle węzły danych ulegają awarii. Ale gdy awarie węzłów nadal można uzyskać poprawny wynik za pomocą cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Mysqld również działa poprawnie, więc na początku nie rozumiem, co jest nie tak. A około 5 minut później wynik ndb_mgm pokazuje, że węzeł danych nie działa. Wtedy zdaję sobie sprawę z problemu. Spróbuj ponownie uruchomić wszystkie węzły danych, a następnie serwer mysql powróci i wszystko będzie w porządku.

Ale jedna rzecz jest dla mnie dziwna, po tym, jak straciłem serwer mysql dla niektórych zapytań, kiedy używam cmd jak show tables, wciąż mogę uzyskać informacje o zwróceniu 33 rows in set (5.57 sec), ale nie wyświetla się żadna informacja o tabeli.

W przypadku amazon RDS (to mój przypadek) możesz zmienić max_allowed_packetwartość parametru na dowolną wartość liczbową w bajtach, która ma sens dla największych danych w dowolnej wstawce, jaką możesz mieć (np .: jeśli masz jakieś 50mb wartości blob we wstawce, ustaw max_allowed_packetdo 64 M = 67108864), w nowym lub istniejącym parameter-group. Następnie zastosuj tę grupę parametrów do instancji MySQL (może wymagać ponownego uruchomienia instancji).

Jeśli łączy się ponownie i uzyskuje identyfikator połączenia 2, serwer prawie na pewno się zawiesił.

Skontaktuj się z administratorem serwera i poproś go o zdiagnozowanie problemu. Żaden nie złośliwy SQL nie powinien powodować awarii serwera, a wynik działania mysqldump z pewnością nie powinien.

Prawdopodobnie jest tak, że administrator serwera popełnił duży błąd operacyjny, na przykład przypisując rozmiary buforów większe niż ograniczenia przestrzeni adresowej architektury lub więcej niż pojemność pamięci wirtualnej. Dziennik błędów MySQL prawdopodobnie zawiera pewne istotne informacje; będą monitorować to, jeśli i tak będą kompetentni.

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

Dla użytkowników Drupal 8 szukających rozwiązania problemu z niepowodzeniem importu bazy danych:

Na końcu pliku zrzutu sql mogą znajdować się polecenia wstawiające dane do tabeli „webprofiler”. To chyba plik dziennika debugowania i nie jest tak naprawdę ważny, aby witryna działała, więc wszystko to można usunąć. Usunąłem wszystkie te wstawki, w tym LOCK TABLES i UNLOCK TABLES (i wszystko pomiędzy). Jest na samym dole pliku sql. Problem opisano tutaj:

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

Ale nie ma na to rozwiązania oprócz obcinania tego stołu.

BTW Wypróbowałem wszystkie rozwiązania z powyższych odpowiedzi i nic więcej nie pomogło.

Wypróbowałem wszystkie powyższe rozwiązania, wszystkie zawiodły.

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

Ten komunikat o błędzie pojawia się również, gdy utworzono SCHEMAT z inną KOLACJĄ niż ta, która jest używana w zrzutu. 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 SCHEMA:

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 uległo awarii i doprowadziło mnie do szaleństwa.

Może to pomoże ci zaoszczędzić trochę frustrujących godzin ... :-)

(MacOS 10.3, mysql 5.7)

jeśli żadna z tych odpowiedzi nie rozwiązuje 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, a usunie i ponownie utworzy potrzebne tabele.

Następnie wykonaj kopię zapasową samych danych i zrób to samo, a to zadziała.

Co powiesz na użycie klienta mysql w ten sposób:

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