Błąd MySQL 2006: serwer mysql zniknął

Korzystam z serwera w moim biurze, aby przetwarzać niektóre pliki i raportować wyniki na zdalnym serwerze MySQL.

Przetwarzanie plików zajmuje trochę czasu, a proces umiera w połowie z powodu następującego błędu:

2006, MySQL server has gone away

Słyszałem o ustawieniach MySQL, wait_timeout , ale czy muszę to zmienić na serwerze w moim biurze lub na zdalnym serwerze MySQL?

Może być łatwiej sprawdzić, czy połączenie i nawiązać je w razie potrzeby.

Zobacz PHP: mysqli_ping, aby uzyskać informacje na ten temat.

Zetknąłem się z tym wiele razy i zwykle znalazłem odpowiedź na bardzo niskie ustawienie domyślne max_allowed_packet.

Podniesienie go w /etc/my.cnf(poniżej [mysqld]) do 8 lub 16M zwykle to naprawia. (Wartość domyślna w MySql 5.7 4194304to 4 MB.)

[mysqld]
max_allowed_packet=16M

Uwaga: Wystarczy utworzyć linię, jeśli nie istnieje

Uwaga: Można to ustawić na działającym serwerze.

Zastosowanie set global max_allowed_packet=104857600. Ustawia to na 100 MB.

Miałem ten sam problem, ale zmiana max_allowed_packetw my.ini/my.cnfpliku [mysqld]podstępem załatwiła sprawę .

dodaj linię

max_allowed_packet = 500 mln

teraz, restart the MySQL servicekiedy skończysz.

Użyłem następującego polecenia w wierszu polecenia MySQL, aby przywrócić bazę danych MySQL, która ma rozmiar ponad 7 GB i działa.

set global max_allowed_packet=268435456;

Błąd: 2006 ( CR_SERVER_GONE_ERROR )

Wiadomość: serwer MySQL zniknął

Zasadniczo możesz spróbować połączyć się, a następnie ponownie wykonać zapytanie, aby rozwiązać ten problem - spróbuj 3-4 razy, zanim całkowicie się poddasz.

Zakładam, że używasz PDO. Jeśli tak, to złap wyjątek PDO, zwiększ licznik, a następnie spróbuj ponownie, jeśli licznik jest poniżej progu.

Jeśli masz zapytanie powodujące przekroczenie limitu czasu, możesz ustawić tę zmienną, wykonując:

SET @@GLOBAL.wait_timeout=300;
SET @@LOCAL.wait_timeout=300;  -- OR current session only

Gdzie 300 to liczba sekund, według których maksymalny czas może zająć zapytanie.

Więcej informacji na temat rozwiązywania problemów z połączeniem Mysql.

EDYCJA: Dwa inne ustawienia, których możesz także chcieć użyć to net_write_timeouti net_read_timeout.

W MAMP (wersja non-pro) dodałem

--max_allowed_packet=268435456

do ...\MAMP\bin\startMysql.sh

Kredyty i więcej szczegółów tutaj

Ten błąd występuje z powodu upływu czasu oczekiwania.

Po prostu przejdź do serwera mysql i sprawdź jego czas oczekiwania:

mysql> POKAŻ ZMIENNE JAK „wait_timeout”

mysql> ustaw globalny czas oczekiwania = 600 # 10 minut lub maksymalny czas oczekiwania, którego potrzebujesz

http://sggoyal.blogspot.in/2015/01/2006-mysql-server-has-gone-away.html

Istnieje kilka przyczyn tego błędu.

Związane z MySQL / MariaDB:

• wait_timeout - Czas w sekundach, przez który serwer czeka na połączenie do uaktywnienia się przed jego zamknięciem.
• interactive_timeout - Czas w sekundach, przez który serwer czeka na połączenie interaktywne.
• max_allowed_packet- Maksymalny rozmiar w bajtach pakietu lub ciągu generowanego / pośredniego. Ustaw tak duży jak największy BLOB, w wielokrotnościach 1024.

Przykład my.cnf :

[mysqld]
# 8 hours
wait_timeout = 28800
# 8 hours
interactive_timeout = 28800
max_allowed_packet = 256M

Związane z serwerem:

• Twój serwer ma pełną pamięć - sprawdź informacje o pamięci RAM za pomocą free -h

Związane z ramami:

• Sprawdź ustawienia swojego frameworka. Django na przykład użyj CONN_MAX_AGE(patrz dokumenty )

Jak to debugować:

• Sprawdź wartości zmiennych MySQL / MariaDB.
  • z sql: SHOW VARIABLES LIKE '%time%';
  • wiersz poleceń: mysqladmin variables
• Włącz gadatliwość w przypadku błędów:
  • MariaDB: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Sprawdź dokumenty, aby uzyskać więcej informacji o błędzie

W systemie Windows ci ludzie używający xampp powinni użyć tej ścieżki xampp / mysql / bin / my.ini i zmienić max_allowed_packet (w sekcji [mysqld]) na wybrany rozmiar. na przykład

max_allowed_packet=8M

Ponownie na php.ini (xampp / php / php.ini) zmień upload_max_files rozmiar rozmiaru wyboru. na przykład

upload_max_filesize=8M

Sprawiał mi ból głowy, dopóki tego nie odkryłem. Mam nadzieję, że to pomoże.

Otrzymałem ten sam błąd na moim serwerze DigitalOcean Ubuntu.

Próbowałem zmienić ustawienia pakietu max_allowed_packet i wait_timeout, ale żadne z nich tego nie naprawiło.

Okazuje się, że mój serwer nie ma pamięci RAM. Dodałem plik wymiany 1 GB i to rozwiązało mój problem.

Sprawdź swoją pamięć, free -haby zobaczyć, czy to właśnie to powoduje.

To był dla mnie problem z pamięcią RAM.

Miałem ten sam problem nawet na serwerze z 12 rdzeniami procesora i 32 GB pamięci RAM. Badałem więcej i próbowałem zwolnić pamięć RAM. Oto polecenie, którego użyłem w Ubuntu 14.04, aby zwolnić pamięć RAM:

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

I naprawił wszystko. Ustawiłem pod cronem, aby uruchamiał się co godzinę.

crontab -e

0 * * * * bash /root/ram.sh;

I możesz użyć tego polecenia, aby sprawdzić, ile wolnej pamięci RAM jest dostępne:

free -h

I otrzymasz coś takiego:

             total       used       free     shared    buffers     cached
Mem:           31G        12G        18G        59M       1.9G       973M
-/+ buffers/cache:       9.9G        21G
Swap:         8.0G       368M       7.6G

W moim przypadku była to niska wartość open_files_limitzmiennej, która blokowała dostęp mysqld do plików danych.

Sprawdziłem to za pomocą:

mysql> SHOW VARIABLES LIKE 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 1185  |
+------------------+-------+
1 row in set (0.00 sec)

Po zmianie wartości zmiennej na dużą wartość nasz serwer znów żył:

[mysqld]
open_files_limit = 100000

Jeśli używasz 64-bitowego WAMPSERVER, poszukaj wielu wystąpień pakietu max_allowed_packet, ponieważ WAMP używa wartości ustawionej w [wampmysqld64], a nie wartości ustawionej w [mysqldump], co dla mnie było problemem, aktualizowałem niewłaściwy. Ustaw na coś takiego jak max_allowed_packet = 64M.

Mam nadzieję, że pomoże to innym użytkownikom Wampserver.

Zazwyczaj oznacza to problemy z łącznością z serwerem MySQL lub przekroczenia limitu czasu. Ogólnie można go rozwiązać, zmieniając pakiet wait_timeout i max_allowed_packet w pliku my.cnf lub podobnym.

Sugerowałbym te wartości:

wait_timeout = 28800

max_allowed_packet = 8 mln

W przypadku Vagrant Box upewnij się, że przydzielisz wystarczającą ilość pamięci do skrzynki

config.vm.provider "virtualbox" do |vb|
  vb.memory = "4096"
end

Mało prawdopodobnym scenariuszem jest zapora ogniowa między klientem a serwerem, która wymusza reset TCP w połączeniu.

Miałem ten problem i stwierdziłem, że nasza korporacyjna zapora sieciowa F5 została skonfigurowana do kończenia nieaktywnych sesji, które są bezczynne przez ponad 5 minut.

Po raz kolejny jest to mało prawdopodobny scenariusz.

Zawsze dobrze jest sprawdzić dzienniki serwera Mysql, z tego powodu, że zniknął.

To ci powie.

Jeśli używasz serwera xampp:

Idź do xampp -> mysql -> bin -> my.ini

Zmień poniższy parametr:

max_allowed_packet = 500 mln

innodb_log_file_size = 128M

To bardzo mi pomogło :)

odkomentuj ligne poniżej my.ini/my.cnf, spowoduje to podzielenie dużego pliku na mniejszą część

# binary logging format - mixed recommended
# binlog_format=mixed

DO

# binary logging format - mixed recommended
binlog_format=mixed

Znalazłem rozwiązanie tego błędu „# 2006 - serwer MySQL zniknął”. Rozwiązaniem jest tylko sprawdzenie dwóch plików

1. config.inc.php
2. config.sample.inc.php

Ścieżka do tych plików w systemie Windows to

C:\wamp64\apps\phpmyadmin4.6.4

W tych dwóch plikach wartość tego:

$cfg['Servers'][$i]['host']must be 'localhost' .

W moim przypadku było to:

$cfg['Servers'][$i]['host'] = '127.0.0.1';

zmień na:

"$cfg['Servers'][$i]['host']" = 'localhost';

Upewnij się w obu przypadkach:

1. config.inc.php
2. Pliki config.sample.inc.php musi to być „localhost”.

I ostatni zestaw:

$cfg['Servers'][$i]['AllowNoPassword'] = true;

Następnie uruchom ponownie Wampserver.

Aby zmienić nazwę użytkownika i hasło phpmyadmin

Możesz bezpośrednio zmienić nazwę użytkownika i hasło phpmyadmin poprzez plik config.inc.php

Te dwie linie

$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';

Tutaj możesz podać nową nazwę użytkownika i hasło. Po zmianach zapisz plik i zrestartuj serwer WAMP.

Mam komunikat o błędzie 2006 w innym oprogramowaniu klienta MySQL na moim pulpicie Ubuntu. Okazało się, że moja wersja sterownika JDBC była za stara.

Może to być problem z rozmiarem pliku .sql.

Jeśli używasz xampp. Przejdź do panelu sterowania xampp -> Kliknij konfigurację MySql -> Otwórz my.ini.

Zwiększ rozmiar pakietu.

max_allowed_packet = 2M -> 10M

Jest łatwiejszy sposób, jeśli używasz XAMPP. Otwórz panel sterowania XAMPP i kliknij przycisk konfiguracji w sekcji mysql.

Teraz kliknij my.ini, a otworzy się w edytorze. Zaktualizuj pakiet max_allowed_packet do wymaganego rozmiaru.

Następnie uruchom ponownie usługę mysql. Kliknij przycisk Zatrzymaj w usłudze Mysql, kliknij przycisk Rozpocznij ponownie. Poczekaj kilka minut.

Następnie spróbuj ponownie uruchomić zapytanie MySQL. Mam nadzieję, że to zadziała.

MAMP 5.3, nie znajdziesz my.cnf i dodanie ich nie działa, ponieważ ten max_allowed_packet jest przechowywany w zmiennych.

Jednym z rozwiązań może być:

1. Idź do http: // localhost / phpmyadmin
2. Przejdź do zakładki SQL
3. Uruchom POKAŻ ZMIENNE i sprawdź wartości, jeśli są małe, uruchom z dużymi wartościami

4. Uruchom następujące zapytanie, ustawia max_allowed_packet na 7 gb:

   ustaw globalny max_allowed_packet = 268435456;

W przypadku niektórych może być konieczne zwiększenie również następujących wartości:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

Użytkownicy korzystający z XAMPP mają 2 parametry pakietu max_allowed_packet w C: \ xampp \ mysql \ bin \ my.ini.

Ten błąd występuje zasadniczo z dwóch powodów.

1. Masz za mało pamięci RAM.
2. Połączenie z bazą danych jest zamykane podczas próby połączenia.

Możesz wypróbować ten kod poniżej.

# Simplification to execute an SQL string of getting a data from the database
def get(self, sql_string, sql_vars=(), debug_sql=0):
    try:            
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()
    except (AttributeError, MySQLdb.OperationalError):
        self.__init__()
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()

Łagodzi błąd bez względu na przyczynę, szczególnie z drugiego powodu.

Jeśli jest to spowodowane niską pamięcią RAM, musisz zwiększyć wydajność połączenia z bazą danych z kodu, z konfiguracji bazy danych lub po prostu zwiększyć pamięć RAM.

Na wszelki wypadek pomaga to każdemu:

Wystąpił ten błąd, gdy otwierałem i zamykałem połączenia w funkcji, która byłaby wywoływana z kilku części aplikacji. Otrzymaliśmy zbyt wiele połączeń, więc pomyśleliśmy, że dobrym pomysłem może być ponowne użycie istniejącego połączenia lub wyrzucenie go i utworzenie nowego takiego:

  public static function getConnection($database, $host, $user, $password)
 {
 if (!self::$instance) {
  return self::newConnection($database, $host, $user, $password);
 } elseif ($database . $host . $user != self::$connectionDetails) {

self :: $ instance-> query ('KILL CONNECTION_ID ()'); self :: $ instance = null; return self :: newConnection ($ baza danych, $ host, $ użytkownik, $ hasło); } zwróć self :: $ instance; } Cóż, okazuje się, że byliśmy zbyt dokładni w zabijaniu, więc procesy, które robią ważne rzeczy na starym połączeniu, nigdy nie zakończą swojej działalności. Więc porzuciliśmy te linie

  self::$instance->query('KILL CONNECTION_ID()');
  self::$instance = null;

a ponieważ pozwala na to sprzęt i konfiguracja urządzenia, zwiększyliśmy liczbę dozwolonych połączeń na serwerze poprzez dodanie

max_connections = 500

do naszego pliku konfiguracyjnego. To na razie naprawiło nasz problem i nauczyliśmy się czegoś o zabijaniu połączeń mysql.

Jeśli wiesz, że przez jakiś czas jesteś offline, możesz zamknąć połączenie, wykonać przetwarzanie, połączyć się ponownie i napisać raporty.