Kod błędu: 2013. Utracono połączenie z serwerem MySQL podczas zapytania


252

Otrzymałem kod błędu: 2013. Utracono połączenie z serwerem MySQL podczas błędu zapytania, gdy próbowałem dodać indeks do tabeli za pomocą MySQL Workbench. Zauważyłem również, że pojawia się za każdym razem, gdy uruchamiam długie zapytanie.

Czy istnieje możliwość zwiększenia wartości limitu czasu?

Odpowiedzi:


473

Nowe wersje MySQL WorkBench mają opcję zmiany określonych limitów czasu.

Dla mnie było to w Edycja → Preferencje → Edytor SQL → Limit czasu odczytu połączenia DBMS (w sekundach): 600

Zmieniono wartość na 6000.

Również niezaznaczone wiersze limitów, ponieważ nakładanie limitu za każdym razem, gdy chcę przeszukać cały zestaw danych, staje się męczące.


2
Czy można zwiększyć ten limit w ciągu 99 999 sekund? DBMS connection read time outPole przyjąć tylko do figur 5 i ustawiania pola 0 odpowiada domyślnej parametrów (600 sekund). (Windows 7 64-bit Ultimate, MySQL Workbench 5.2.47 CE)
Franck Dernoncourt


4
odznacz limit wierszy w Edycja → Preferencje → Zapytania SQL
Jon

7
Po ponownym uruchomieniu ponownie wyświetla błąd 2013, nawet jeśli czas odczytu ustawiony jest na 6000, więc nie wydaje się to rozwiązaniem.
Davicus

4
Pamiętaj, aby zrestartować Workbench ORAZ, aby najpierw zamknąć wszystkie otwarte okna zapytań!
pimbrouwers

32

Rozpocząć serwera bazy danych z możliwością comandline net_read_timeout/ wait_timeouti odpowiednią wartość (w sekundach) - na przykład: --net_read_timeout=100.

W celach informacyjnych patrz tutaj i tutaj .



6
Jak podać ten parametr w wierszu polecenia? Kiedy próbuję połączyć się z bazą danych: mysql -u root -p --net_read_timeout = 60 lub kiedy próbuję uruchomić usługę? usługa sudo mysql start? W obu miejscach podaje błąd: nieznana zmienna „net_read_timeout”
Vikas Goel

@VikasGoel Jest to parametr po stronie serwera. Tj mysqld.
Chloe,

29

Jeśli zapytanie zawiera dane obiektów blob, ten problem można rozwiązać, wprowadzając my.inizmianę zaproponowaną w tej odpowiedzi :

[mysqld]
max_allowed_packet=16M

Domyślnie będzie to 1 mln (dozwolona maksymalna wartość to 1024 mln). Jeśli podana wartość nie jest wielokrotnością 1024 KB, zostanie automatycznie zaokrąglona do najbliższej wielokrotności 1024 KB.

Natomiast odwoływać wątek jest o błędzie MySQL 2006 , ustawienie max_allowed_packetod 1M do 16M zrobił naprawić błąd 2013, który pojawił się na mnie, kiedy uruchomiony długą zapytania.

Dla użytkowników WAMP: flaga znajduje się w [wampmysqld]sekcji.


To był dokładnie mój problem. Importowałem kopię zapasową bazy danych z pliku, a MySQL Workbench zgłaszał ten błąd 2013, a następnie „Operacja nie powiodła się z kodem wyjścia 1”. Okazuje się, że kopia zapasowa miała duże kolumny obiektów blob przekraczające domyślny maksymalny rozmiar pakietu 4S MySQL. Zwiększenie to naprawiło. (MySQL 5.6 i Workbench 6.2.3). Dzięki!
zAlbee

To była też poprawka dla mnie. Chociaż ustawiłem go na 256M dla komputera z systemem Windows.
smoore4

Miałem 16M, wielokrotnie otrzymałem ten błąd przy importowaniu pliku, zmieniłem na 32M, a potem zadziałało.
hakre

15

Dodaj następujące pliki do pliku / etc / mysql / cnf:

innodb_buffer_pool_size = 64M

przykład:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

6
Czy na pewno nazwa pliku /etc/mysql/cnfjest poprawna? Nie powinno tak być /etc/my.cnf?
Peter VARGA,

12
SET @@local.net_read_timeout=360;

Ostrzeżenie: następujące elementy nie będą działać, gdy zastosujesz je w połączeniu zdalnym:

SET @@global.net_read_timeout=360;

Co to jest 360? Milisek, sekundy, minuty?
MasterJoe2

10

Istnieją trzy prawdopodobne przyczyny tego komunikatu o błędzie

  1. Zwykle oznacza to problemy z połączeniem sieciowym i powinieneś sprawdzić stan sieci, jeśli ten błąd występuje często
  2. Czasami formularz „podczas zapytania” ma miejsce, gdy miliony wierszy są wysyłane w ramach jednego lub więcej zapytań.
  3. Rzadziej może się to zdarzyć, gdy klient próbuje nawiązać pierwsze połączenie z serwerem

Aby uzyskać więcej informacji przeczytaj >>

Przyczyna 2:

SET GLOBAL interactive_timeout=60;

od domyślnego 30 sekund do 60 sekund lub dłużej

Przyczyna 3:

SET GLOBAL connect_timeout=60;

2 daje mi ten błąd - kod: 1227. Odmowa dostępu; potrzebujesz (co najmniej jednego) uprawnienia SUPER do tej operacji
MasterJoe2


8

Powinieneś ustawić właściwości „Interactive_timeout” i „wait_timeout” w pliku konfiguracyjnym mysql na potrzebne wartości.


To mi pomaga. „Interactive_timeout” w my.cnf ustawiono na 100, co jest za krótkie. po zmianie na 3600 s (lub dowolnej wartości wystarczająco dużej dla Ciebie) problem został rozwiązany.
Thx

7

Wystarczy wykonać aktualizację MySQL że będzie odbudować silnik InnoDB wraz z przebudowa wielu tabel potrzebnych do prawidłowego funkcjonowania, takich jak MySQL performance_schema, information_schemaitp

Wydaj następujące polecenie ze swojej powłoki:

sudo mysql_upgrade -u root -p

Błąd pojawił się dopiero w MySQL Workbench 6.1.4 (i dopiero po pewnym czasie) i zdarza się również w 6.1.6 (choć tylko po kilku zastosowaniach), więc nie jestem pewien, jak odbudowa wielu serwerów jest poprawką dla problem, który niedawno pojawił się na jednym GUI.
Davicus

To naprawiło mój problem. Właśnie użyłem Ansible do skonfigurowania bazy danych na istniejącej i wszystko poszło nie tak. Uruchomienie tego polecenia przywróciło wszystko do porządku.
Jubz

4

Wiem, że jest stary, ale na Macu

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.


3

Spróbuj odznaczyć limit wierszy w Edycja → Preferencje → Zapytania SQL

ponieważ powinieneś ustawić właściwości „Interactive_timeout” i „wait_timeout” w pliku konfiguracyjnym mysql na potrzebne wartości.


3

Jeśli napotkasz ten problem podczas przywracania dużego pliku zrzutu i możesz wykluczyć problem, że ma on coś wspólnego z siecią (np. Wykonanie na localhost), wówczas moje rozwiązanie może być pomocne.

Mój mysqldump zawierał przynajmniej jeden WSTAW, który był zbyt duży, aby mysql mógł go obliczyć. Możesz wyświetlić tę zmienną, wpisując show variables like "net_buffer_length";wewnątrz swojego mysql-cli. Masz trzy możliwości:

  • zwiększyć net_buffer_length wewnątrz mysql -> to wymagałoby ponownego uruchomienia serwera
  • utwórz zrzut za pomocą --skip-extended-insert, dla każdej wstawki używana jest jedna linia -> chociaż te zrzuty są o wiele ładniejsze do czytania, nie jest to odpowiednie dla dużych zrzutów> 1 GB, ponieważ zwykle jest bardzo wolne
  • utwórz zrzut z rozszerzonymi wstawkami (co jest ustawieniem domyślnym), ale ogranicz długość bufora netto, np. --net-buffer_length NR_OF_BYTESgdzie NR_OF_BYTES jest mniejszy niż długość_ bufora serwera -> Myślę, że to najlepsze rozwiązanie, chociaż wolniej nie jest wymagane ponowne uruchomienie serwera.

Użyłem następującego polecenia mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile


2

Mam ten sam problem podczas ładowania pliku .csv. Konwertuje plik na .sql.

Za pomocą poniższego polecenia udało mi się obejść ten problem.

mysql -u <user> -p -D <DB name> < file.sql

Mam nadzieję, że to pomoże.


2

Jeśli wszystkie inne rozwiązania tutaj zawiodą - sprawdź swój syslog (/ var / log / syslog lub podobny), aby sprawdzić, czy na serwerze brakuje pamięci podczas zapytania.

Wystąpił ten problem, gdy parametr innodb_buffer_pool_size był ustawiony zbyt blisko pamięci fizycznej bez skonfigurowanego pliku wymiany. MySQL zaleca ustawienie serwera innodb_buffer_pool_size dla bazy danych na maks. Około 80% pamięci fizycznej , ustawiłem na około 90%, jądro zabijało proces mysql. Przeniesiono innodb_buffer_pool_size z powrotem do około 80% i to rozwiązało problem.


2

W moim przypadku ustawienie limitu czasu połączenia na 6000 lub coś wyższego nie działało.

Właśnie zrobiłem to, co mówi stół warsztatowy, że mogę zrobić.

Maksymalny czas, przez który zapytanie może zwrócić dane z DBMS.Set 0, aby pominąć limit czasu odczytu.

W systemie Mac Preferencje -> Edytor SQL -> Przejdź do sesji MySQL -> ustaw limit czasu odczytu połączenia na 0.

I to działa 😄


1

Napotkałem ten sam problem. Wydaje mi się, że dzieje się tak, gdy masz klucze obce do większych tabel (co wymaga czasu).

Próbowałem ponownie uruchomić instrukcję tworzenia tabeli bez deklaracji klucza obcego i okazało się, że zadziałała.

Następnie po utworzeniu tabeli dodałem ograniczenia klucza obcego za pomocą zapytania ALTER TABLE.

Mam nadzieję, że to komuś pomoże.


1

Stało się tak, ponieważ mój rozmiar innodb_buffer_pool_size był ustawiony na większy niż rozmiar pamięci RAM dostępny na serwerze. Z tego powodu sprawy ulegały zakłóceniu i pojawia się ten błąd. Rozwiązaniem jest aktualizacja my.cnf z poprawnym ustawieniem dla innodb_buffer_pool_size.


1

Przejdź do Edycja środowiska roboczego → Preferencje → Edytor SQL → Limit czasu odczytu połączeń DBMS: do 3000. Błąd już nie występuje.


0

Iść do:

Edycja -> Preferencje -> Edytor SQL

Tam możesz zobaczyć trzy pola w grupie „MySQL Session”, w których możesz teraz ustawić nowe interwały połączeń (w sekundach).


0

Okazuje się, że nasza reguła zapory blokowała moje połączenie z MYSQL. Po zniesieniu zasady zapory sieciowej, aby umożliwić połączenie, udało mi się pomyślnie zaimportować schemat.


0

Miałem ten sam problem - ale dla mnie rozwiązaniem był użytkownik bazy danych ze zbyt surowymi uprawnieniami. Musiałem pozwolić tej Executeumiejętności na mysqlstole. Po zezwoleniu na to nie miałem już zrywanych połączeń


0

Sprawdź, czy indeksy są na pierwszym miejscu.

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

0

Natknąłem się na to podczas uruchamiania zapisanego procesu, który tworzył wiele wierszy w tabeli w bazie danych. Widziałem błąd pojawiający się tuż po przekroczeniu granicy 30 sekund.

Wypróbowałem wszystkie sugestie z pozostałych odpowiedzi. Jestem pewien, że część z nich pomogła jednak - naprawdę sprawiło, że działało dla mnie przejście na SequelPro z Workbench.

Zgaduję, że było to połączenie po stronie klienta, którego nie mogłem wykryć w Workbench. Może to pomoże komuś innemu?


0

Jeśli używasz SQL Work Bench, możesz spróbować użyć Indeksowania, dodając indeks do swoich tabel, aby dodać indeks, kliknij symbol klucza (klucza) na stole, powinien otworzyć konfigurację tabeli poniżej , kliknij widok indeksu, wpisz nazwę indeksu i ustaw typ na indeks, W kolumnach indeksu wybierz kolumnę podstawową w tabeli.

Wykonaj ten sam krok dla innych kluczy podstawowych w innych tabelach.


0

Wydaje się, że brakuje tutaj odpowiedzi dla tych, którzy używają SSH do łączenia się z bazą danych MySQL. Musisz sprawdzić dwa miejsca, a nie 1, jak sugerują inne odpowiedzi:

Edycja środowiska roboczego → Preferencje → Edytor SQL → DBMS

Edycja stołu roboczego → Preferencje → SSH → Limity czasu

Moje domyślne limity czasu SSH były bardzo niskie i powodowały niektóre (ale najwyraźniej nie wszystkie) moje problemy z limitem czasu. Po nie zapomnij zrestartować MySQL Workbench!

Na koniec warto skontaktować się z administratorem DB i poprosić go o zwiększenie właściwości wait_timeout i Interactive_timeout w samym mysql poprzez my.conf + mysql restart lub wykonanie zestawu globalnego, jeśli ponowne uruchomienie mysql nie jest możliwe.

Mam nadzieję że to pomoże!


0

Trzy rzeczy do naśladowania i upewnij się:

  1. Czy wiele zapytań pokazuje utratę połączenia?
  2. jak używasz zestawu zapytań w MySQL?
  3. jak jednocześnie usunąć + zaktualizować zapytanie?

Odpowiedzi:

  1. Zawsze staraj się usunąć program definiujący, ponieważ MySQL tworzy swój własny program definiujący, a jeśli wiele tabel jest zaangażowanych w aktualizację, spróbuj wykonać jedno zapytanie, ponieważ czasami wiele zapytań pokazuje utratę połączenia
  2. Zawsze ustaw wartość na górze, ale po USUŃ, jeśli jej warunek nie obejmuje wartości ustawienia.
  3. Użyj USUŃ PIERWSZĄ, A NASTĘPNIE AKTUALIZACJĘ, JEŚLI OBECNE OPERACJE SĄ WYKONYWANE NA RÓŻNYCH TABELACH

-1

sprawdź o

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

Mam nadzieję że to pomoże


-1

Zazwyczaj oznacza to, że masz „niezgodność z bieżącą wersją serwera MySQL”, patrz mysql_upgrade. Natrafiłem na ten sam problem i po prostu musiałem uruchomić:

mysql_upgrade --password Dokumentacja stwierdza, że ​​„mysql_upgrade powinien być wykonywany przy każdej aktualizacji MySQL”.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.