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

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?

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.

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 .

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.

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

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;

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;

Dzięki! Udało się. Ale wraz z aktualizacjami mysqldb konfiguracja stała się:

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

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

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

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.

Zmień czas „limit czasu odczytu” w menu Edycja-> Preferencje-> Edytor SQL-> sesja MySQL

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.

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

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.

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.

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 😄

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.

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.

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

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).

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.

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ń

Sprawdź, czy indeksy są na pierwszym miejscu.

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

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?

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.

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!

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

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

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”.