Serwer MySQL zniknął podczas importowania dużego pliku SQL

Próbowałem zaimportować duży plik sql przez phpMyAdmin ... Ale nadal wyświetlał błąd

„Serwer MySql zniknął”

Co robić?

Jak stwierdzono tutaj :

Dwa najczęstsze powody (i poprawki) dla serwera MySQL zniknęły (błąd 2006):

Serwer przekroczył limit czasu i zamknął połączenie. Jak naprawić:

1. sprawdź, czy zmienna wait_timeout w pliku konfiguracyjnym my.cnf twojego mysqld jest wystarczająco duża. W systemie Debian: sudo nano /etc/mysql/my.cnfustaw wait_timeout = 600sekundy (możesz dostosować / zmniejszyć tę wartość, gdy zniknie błąd 2006) sudo /etc/init.d/mysql restart. Nie sprawdziłem, ale domyślna wartość wait_timeout może wynosić około 28800 sekund (8 godzin).

2. Serwer upuścił niepoprawny lub zbyt duży pakiet. Jeśli mysqld otrzyma pakiet, który jest zbyt duży lub niepoprawny, zakłada, że ​​coś poszło nie tak z klientem i zamyka połączenie. Możesz zwiększyć maksymalny limit rozmiaru pakietu, zwiększając wartość parametru max_allowed_packet w pliku my.cnf. W systemie Debian: sudo nano /etc/mysql/my.cnfustaw max_allowed_packet = 64M(możesz dostosować / zmniejszyć tę wartość, gdy zniknie błąd 2006) sudo /etc/init.d/mysql restart.

Edytować:

Zauważ, że pliki opcji MySQL nie mają już swoich poleceń jako komentarzy (na przykład w php.ini). Więc należy wpisać dowolną zmianę / dostrojenia w my.cnflub my.inii umieścić je w mysql/datakatalogu lub na którykolwiek z pozostałych ścieżek pod właściwą grupę opcji, takich jak [client], [myslqd]itd Na przykład:

[mysqld]
wait_timeout = 600
max_allowed_packet = 64M

Następnie uruchom ponownie serwer. Aby uzyskać ich wartości, wpisz klienta mysql:

> select @@wait_timeout;
> select @@max_allowed_packet;

Dla mnie to rozwiązanie nie zadziałało, więc wykonałem

SET GLOBAL max_allowed_packet=1073741824;

w moim kliencie SQL.

Jeśli nie można tego zmienić przy działającej usłudze MYSql, należy zatrzymać usługę i zmienić zmienną w pliku „my.ini”.

Na przykład:

max_allowed_packet=20M

Jeśli pracujesz na XAMPP, możesz naprawić problem MySQL Server zniknął problem z następującymi zmianami.

otwórz plik my.ini Lokalizacja my.ini to (D: \ xampp \ mysql \ bin \ my.ini)

zmień następujące wartości zmiennych

max_allowed_packet = 64M
innodb_lock_wait_timeout = 500

Jeśli korzystasz z wartości domyślnych, masz dużo miejsca na zoptymalizowanie konfiguracji mysql.

Pierwszym krokiem, który zalecam, jest zwiększenie pakietu max_allowed_packet do 128M.

Następnie pobierz skrypt MySQL Tuning Primer i uruchom go. Zapewni rekomendacje dla kilku aspektów twojej konfiguracji dla lepszej wydajności.

Zobacz także, jak dostosować wartości limitu czasu zarówno w MySQL, jak i PHP.

Jak duży (rozmiar pliku) jest importowany plik i czy możesz go zaimportować przy użyciu klienta wiersza polecenia mysql zamiast PHPMyAdmin?

Jeśli używasz MAMPa w OS X, musisz zmienić max_allowed_packetwartość w szablonie MySQL.

1. Można go znaleźć na: Plik> Edytuj szablon> MySQL my.cnf

2. Następnie wyszukaj max_allowed_packet, zmień wartość i zapisz.

Rozwiązałem problem z tym krótkim plikiem /etc/mysql/my.cnf:

[mysqld]
wait_timeout = 600
max_allowed_packet = 100M

Innym powodem może być brak pamięci. Sprawdź / var / log / messages i upewnij się, że plik my.cnf nie jest skonfigurowany tak, aby mysqld przydzielił więcej pamięci niż ma to urządzenie.

Twój proces mysqld może zostać zabity przez jądro, a następnie ponownie uruchomiony przez proces „safe_mysqld”, nawet nie zdając sobie z tego sprawy.

Skorzystaj z góry i obserwuj przydzielanie pamięci podczas pracy, aby zobaczyć, jaki jest twój zapas.

wykonaj kopię zapasową pliku my.cnf przed jego zmianą.

Miałem ten błąd i inne powiązane, gdy importowałem przy 16 GB pliku SQL. Dla mnie, edytuj plik my.ini i ustaw następujące (w oparciu o kilka różnych postów) w sekcji [mysqld]:

max_allowed_packet      = 110M
innodb_buffer_pool_size=511M
innodb_log_file_size=500M
innodb_log_buffer_size = 800M
net_read_timeout        = 600
net_write_timeout       = 600

Jeśli korzystasz z systemu Windows, przejdź do panelu sterowania, usług i spójrz na szczegóły MySQL, a zobaczysz, gdzie znajduje się my.ini. Następnie po edycji i zapisaniu pliku my.ini uruchom ponownie usługę mysql (lub uruchom ponownie komputer).

Jeśli używasz HeidiSQL, możesz również ustawić niektóre lub wszystkie z nich za pomocą tego.

Zaktualizowałem „max_allowed_packet” do 1024M, ale nadal nie działało. Okazuje się, że mój skrypt wdrażania działał:

mysql --max_allowed_packet=512M --database=mydb -u root < .\db\db.sql

Pamiętaj, aby wyraźnie podać większą liczbę z wiersza poleceń, jeśli przekazujesz ją w ten sposób.

Jeśli Twoje dane obejmują BLOBdane:

Zauważ, że import danych z wiersza poleceń wydaje się dławić danymi BLOB, co powoduje błąd „serwer MySQL zniknął”.

Aby tego uniknąć, utwórz ponownie mysqldump, ale z --hex-blobflagą:

http://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_hex-blob

który zapisuje plik danych z wartościami szesnastkowymi zamiast binarnymi wśród innych tekstów.

PhpMyAdmin ma również opcję „Zrzuć kolumny binarne w notacji szesnastkowej (na przykład„ abc ”staje się 0x616263)”, co działa dobrze.

Zauważ, że istnieje od dawna błąd (od grudnia 2015 r.), Co oznacza, że GEOMkolumny nie są konwertowane: wykonać kopię zapasową tabeli za pomocą kolumny GEOMETRY za pomocą mysqldump? więc użycie programu takiego jak PhpMyAdmin wydaje się być jedynym obejściem (wspomniana powyżej opcja poprawnie konwertuje kolumny GEOM).

Jeśli awaria zajmuje dużo czasu, powiększ wait_timeoutzmienną.

Jeśli zawiedzie od razu, powiększ max_allowed_packetzmienną; nadal nie działa, upewnij się, że polecenie jest poprawnym SQL. Mój miał niezauważalne cytaty, które wszystko popsuły.

Ponadto, jeśli jest to wykonalne, rozważ ograniczenie liczby wstawień pojedynczego polecenia SQL do, powiedzmy, 1000. Możesz utworzyć skrypt, który tworzy wiele instrukcji z jednego polecenia, poprzez ponowne wprowadzenie INSERT ... części co n wstawień.

dostałem podobny błąd .. aby rozwiązać ten problem, wystarczy otworzyć plik my.ini .. w linii nr 36 zmień wartość maksymalnego dozwolonego rozmiaru pakietu, tj. max_allowed_packet = 20 mln

Upewnij się, że proces mysqld nie uruchamia się ponownie z powodu menedżerów usług, takich jak systemd.

Miałem ten problem z włóczęgami z centos 7. Poprawki konfiguracji nie pomogły. Okazało się, że to systemd, który zabijał usługę mysqld za każdym razem, gdy zabierał za dużo pamięci.

Miałem podobny błąd dzisiaj, gdy duplikowanie bazy danych (serwer MySQL zniknął ...), ale kiedy próbowałem zrestartować mysql.server restart, dostałem błąd

ERROR! The server quit without updating PID ...

Tak to rozwiązałem: otworzyłem Aplikacje / Narzędzia / i uruchomiłem Monitor aktywności

 quit mysqld

wtedy był w stanie rozwiązać problem z błędem

mysql.server restart

Robię kilka dużych obliczeń, które wymagają połączenia mysql, aby pozostać długo i z dużymi danymi. Miałem do czynienia z tym problemem „odejdź MySQL”. Próbowałem więc zoptymalizować zapytania, ale to mi nie pomogło, a następnie zwiększyłem limit zmiennych mysql, który jest domyślnie ustawiony na niższą wartość.

wait_timeout max_allowed_packet

Do granic tego, co kiedykolwiek Ci odpowiada, powinna być Dowolna liczba * 1024 (bajty). możesz zalogować się do terminala za pomocą polecenia „ mysql -u nazwa użytkownika - p ” i możesz sprawdzić i zmienić te limity zmiennych.

Dla wspólnego hostingu GoDaddy

Na współdzielonych kontach hostingowych GoDaddy trudno jest ulepszyć pliki PHP.ini itp. Jest jednak inny sposób i dla mnie to zadziałało idealnie. (Właśnie pomyślnie przesłałem plik tekstowy .sql o wielkości 3,8 MB, zawierający 3100 wierszy i 145 kol.. Korzystając z polecenia IMPORT w phpMyAdmin, otrzymywałem przerażający serwer MySQL, który zniknął , i nie ma żadnych dalszych informacji.)

Odkryłem, że Matt Butcher miał właściwą odpowiedź. Podobnie jak Matt, próbowałem wszelkiego rodzaju sztuczek, od eksportowania baz danych MySQL w kawałkach wielkości kęsa, po pisanie skryptów, które dzielą duży import na mniejsze. Ale oto, co zadziałało:

(1) CPANEL ---> PLIKI (grupa) ---> KOPIA ZAPASOWA

(2a) W sekcji „Częściowe kopie zapasowe” ...
(2b) W sekcji „Pobierz
kopię zapasową bazy danych MySQL” (2c) Wybierz bazę danych i pobierz kopię zapasową (ten krok jest opcjonalny, ale mądry)

(3a) Bezpośrednio po prawej stronie 2b, pod nagłówkiem „Przywróć kopię zapasową bazy danych MySQL”
(3b) Wybierz plik importu .SQL z dysku lokalnego
(3c) Prawdziwe szczęście będzie twoje (wkrótce ....) Moje zajęło 5 sekund

Mogłem użyć tej metody do zaimportowania pojedynczej tabeli. Nic innego nie wpłynęło na moją bazę danych - ale właśnie przed tym krok (2) ma chronić.

Uwagi:
a. Jeśli nie masz pewności, jak utworzyć plik importu .SQL, użyj phpMyAdmin, aby wyeksportować tabelę i zmodyfikować tę strukturę pliku.

ŹRÓDŁO: Matt Butcher 2010 Artykuł

Jeśli zwiększenie max_allowed_packetnie pomaga.

Podczas importowania .sqlpliku do mojej bazy danych przez Sequel Pro otrzymywałem ten sam błąd co Ty .

Błąd nadal występował po podniesieniu max_allowed_packetdo, 512Mwięc zamiast tego uruchomiłem import w wierszu poleceń za pomocą:

mysql --verbose -u root -p DatabaseName < MySQL.sql

Dał następujący błąd:

ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled

Znalazłem kilka pomocnych pytań StackOverflow:

• Włącz tryb binarny podczas przywracania bazy danych ze zrzutu SQL
• Mysql ERROR: ASCII '\ 0' podczas importowania pliku sql na serwerze Linux

W moim przypadku mój .sqlplik był trochę uszkodzony lub coś takiego. Zrzut MySQL, który otrzymujemy, jest dostarczany w dwóch plikach zip, które muszą zostać połączone razem, a następnie rozpakowane. Myślę, że rozpakowywanie zostało początkowo przerwane, pozostawiając plik z dziwnymi znakami i kodowaniem. Pobranie nowego zrzutu MySQL i rozpakowanie go poprawnie działało dla mnie.

Chciałem tylko dodać to tutaj, na wypadek gdyby inni stwierdzili, że zwiększenie max_allowed_packetzmiennej nie pomogło.

Żadne z rozwiązań dotyczących rozmiaru pakietu lub przekroczenia limitu czasu nie miało dla mnie znaczenia. Musiałem wyłączyć ssl

mysql -u -p -hmyhost.com --disable-ssl db < file.sql

https://dev.mysql.com/doc/refman/5.7/en/encrypted-connections.html

Mam ten sam problem z

$image_base64 = base64_encode(file_get_contents($_FILES['file']['tmp_name']) );
$image = 'data:image/jpeg;base64,'.$image_base64;
$query = "insert into images(image) values('".$image."')";
mysqli_query($con,$query);

W pliku \ xampp \ mysql \ bin \ my.ini programu phpmyadmin otrzymujemy tylko

[mysqldump]
max_allowed_packet=110M

który jest tylko dla mysqldump -u root -p nazwa_db. Rozwiązałem problem, zastępując powyższy kod na

max_allowed_packet=110M
[mysqldump]
max_allowed_packet=110M