MySQL error 2006: сервер mysql исчез

Я использую сервер в моем офисе, чтобы обработать некоторые файлы и сообщить результаты на удаленный сервер MySQL.

Обработка файлов занимает некоторое время, и процесс завершается на полпути со следующей ошибкой:

2006, MySQL server has gone away

Я слышал о настройке MySQL, wait_timeout, но мне нужно изменить это на сервере в моем офисе или на удаленном сервере MySQL?

32 ответа

Решение

Может быть легче проверить, если соединение и восстановить его, если это необходимо.

Смотрите PHP:mysqli_ping для информации об этом.

Я сталкивался с этим несколько раз, и я обычно нашел, что ответом является очень низкая настройка по умолчанию max_allowed_packet,

Поднятие в /etc/my.cnf (под [mysqld]) до 8 или 16М это обычно исправляет. (По умолчанию в MySql 5.7 4194304, что составляет 4 МБ.)

[mysqld]
max_allowed_packet=16M

Примечание: это может быть установлено на вашем сервере, когда он работает.

использование set global max_allowed_packet=104857600, Это устанавливает его в 100 МБ.

У меня была такая же проблема, но менялась max_allowed_packet в my.ini/my.cnf файл под [mysqld] сделал трюк.

добавить строку

max_allowed_packet=500M

сейчас restart the MySQL service как только вы закончите.

Я использовал следующую команду в командной строке MySQL, чтобы восстановить базу данных MySQL размером более 7 ГБ, и она работает.

set global max_allowed_packet=268435456;

Есть несколько причин этой ошибки.

MySQL/MariaDB связаны:

  • wait_timeout - Время в секундах, в течение которого сервер ждет, пока соединение не станет активным, прежде чем закрыть его.
  • interactive_timeout - Время в секундах, в течение которого сервер ожидает интерактивного соединения.
  • max_allowed_packet - Максимальный размер в байтах пакета или сгенерированной / промежуточной строки. Набор размером с самый большой BLOB, кратный 1024.

Пример my.cnf:

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

Связанный с сервером:

  • Ваш сервер имеет полную память - проверьте информацию об оперативной памяти с помощью free -h

Рамки, связанные:

  • Проверьте настройки вашего фреймворка. Джанго например использовать CONN_MAX_AGE (см. документы)

Как отладить это:

Ошибка: 2006 ( CR_SERVER_GONE_ERROR)

Сообщение: сервер MySQL ушел

Как правило, вы можете повторить попытку подключения, а затем выполнить запрос еще раз, чтобы решить эту проблему - попробуйте 3-4 раза, прежде чем полностью сдаться.

Я предполагаю, что вы используете PDO. Если это так, то вы перехватите исключение PDO, увеличите счетчик и затем повторите попытку, если счетчик находится ниже порогового значения.

Если у вас есть запрос, который вызывает тайм-аут, вы можете установить эту переменную, выполнив:

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

Где 300 - это количество секунд, которое вы считаете максимальным временем, которое может занять запрос.

Дополнительная информация о том, как бороться с проблемами подключения Mysql.

РЕДАКТИРОВАТЬ: две другие настройки, которые вы также можете использовать, это net_write_timeout а также net_read_timeout,

В MAMP (не про версия) я добавил

--max_allowed_packet=268435456

в ...\MAMP\bin\startMysql.sh

Кредиты и более подробную информацию здесь

Если вы используете сервер xampp:

Перейдите в xampp -> mysql -> bin -> my.ini

Измените параметр ниже:

max_allowed_packet = 500 МБ

innodb_log_file_size = 128 МБ

Это мне очень помогло:)

Я получал эту же ошибку на моем сервере DigitalOcean Ubuntu.

Я попытался изменить настройки max_allowed_packet и wait_timeout, но ни один из них не исправил это.

Оказывается, на моем сервере не было оперативной памяти. Я добавил 1ГБ файл подкачки, и это решило мою проблему.

Проверьте свою память с free -h чтобы увидеть, если это то, что вызывает это.

Эта ошибка возникает из-за истечения срока ожидания wait_timeout.

Просто зайдите на сервер MySQL и проверьте его wait_timeout:

mysql> ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'wait_timeout'

mysql> set global wait_timeout = 600 # 10 минут или максимальное время ожидания, которое вам нужно

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

В Windows те парни, которые используют xampp, должны использовать этот путь xampp/mysql/bin/my.ini и изменить max_allowed_packet(в разделе [mysqld]) по вашему выбору. например

max_allowed_packet=8M

Снова на php.ini(xampp/php/php.ini) измените upload_max_filesize по выбору размера. например

upload_max_filesize=8M

Дали мне головную боль на некоторое время, пока я не обнаружил это. Надеюсь, поможет.

Это была проблема с оперативной памятью для меня.

У меня была такая же проблема даже на сервере с 12 ядрами процессора и 32 ГБ оперативной памяти. Я исследовал больше и попытался освободить оперативную память. Вот команда, которую я использовал в Ubuntu 14.04 для освобождения оперативной памяти:

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

И это все исправило. Я установил его под cron, чтобы запускать каждый час.

crontab -e

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

И вы можете использовать эту команду, чтобы проверить, сколько свободной оперативной памяти доступно:

free -h

И вы получите что-то вроде этого:

             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

В моем случае это было низкое значение open_files_limit переменная, которая блокировала доступ mysqld к файлам данных.

Я проверил это с:

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

После того, как я изменил переменную на большое значение, наш сервер снова ожил:

[mysqld]
open_files_limit = 100000

Обычно это указывает на проблемы с подключением к серверу MySQL или тайм-ауты. Обычно это можно решить, изменив wait_timeout и max_allowed_packet в my.cnf или аналогичном.

Я бы предложил эти значения:

wait_timeout = 28800

max_allowed_packet = 8M

Существует более простой способ, если вы используете XAMPP. Откройте панель управления XAMPP и нажмите кнопку конфигурации в разделе mysql.

Теперь нажмите на my.ini, и он откроется в редакторе. Обновите max_allowed_packet до нужного вам размера.

Затем перезапустите службу MySQL. Нажмите на остановку на сервисе Mysql, нажмите "Пуск" снова. Подождите несколько минут.

Затем попробуйте снова выполнить свой запрос Mysql. Надеюсь, это сработает.

Если вы используете 64-битный WAMPSERVER, пожалуйста, найдите несколько вхождений max_allowed_packet, потому что WAMP использует значение, установленное в [wampmysqld64], а не значение, установленное в [mysqldump], что для меня было проблемой, я обновлял не тот. Установите это как что-то вроде max_allowed_packet = 64M.

Надеюсь, это поможет другим пользователям Wampserver.

Всегда полезно проверять логи сервера Mysql по той причине, по которой он исчез.

Это скажет тебе.

MAMP 5.3, вы не найдете my.cnf, и добавление их не работает, так как max_allowed_packet хранится в переменных.

Одним из решений может быть:

  1. Зайдите на http://localhost/phpmyadmin
  2. Перейти на вкладку SQL
  3. Запустите SHOW VARIABLES и проверьте значения, если оно маленькое, то запустите с большими значениями
  4. Запустите следующий запрос, он установит max_allowed_packet равным 7 ГБ:

    установить глобальный max_allowed_packet=268435456;

Для некоторых вам может потребоваться увеличить также следующие значения:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

Для Vagrant Box убедитесь, что вы выделяете достаточно памяти для коробки

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

Маловероятно, что у вас есть межсетевой экран между клиентом и сервером, который принудительно сбрасывает TCP в соединение.

У меня была такая проблема, и я обнаружил, что наш корпоративный брандмауэр F5 был настроен на прекращение неактивных сеансов, которые простаивают более 5 минут.

Еще раз, это маловероятный сценарий.

Это может быть проблемой вашего размера файла.sql.

Если вы используете xampp. Зайдите в панель управления xampp -> нажмите MySql config -> откройте my.ini.

Увеличьте размер пакета.

max_allowed_packet = 2M -> 10M

Раскомментируйте строку ниже в вашем my.ini/my.cnf, это разделит ваш большой файл на меньшую часть

# binary logging format - mixed recommended
# binlog_format=mixed

К

# binary logging format - mixed recommended
binlog_format=mixed

Я нашел решение этой ошибки: "#2006 - сервер MySQL исчез". Решение просто проверить два файла

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

Путь этих файлов в windows

C:\wamp64\apps\phpmyadmin4.6.4

В этих двух файлах значение этого:

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

В моем случае это было:

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

измените это на:

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

Убедитесь в обоих:

  1. config.inc.php
  2. Файлы config.sample.inc.php должны быть локальными.

И последний набор:

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

Затем перезапустите Wampserver.


Чтобы изменить имя пользователя и пароль phpmyadmin

Вы можете напрямую изменить имя пользователя и пароль phpmyadmin через файл config.inc.php

Эти две линии

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

Здесь вы можете дать новое имя пользователя и пароль. После изменений сохраните файл и перезапустите сервер WAMP.

Я получил сообщение об ошибке 2006 в различных клиентских программах MySQL на своем рабочем столе Ubuntu. Оказалось, что моя версия драйвера JDBC была слишком старой.

У меня была такая же проблема в докере, добавив ниже настройку в docker-compose.yml:

db:
    image: mysql:8.0
    command: --wait_timeout=800 --max_allowed_packet=256M --character-set-server=utf8 --collation-server=utf8_general_ci --default-authentication-plugin=mysql_native_password
    volumes:
      - ./docker/mysql/data:/var/lib/mysql
      - ./docker/mysql/dump:/docker-entrypoint-initdb.d
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

Эта ошибка происходит в основном по двум причинам.

  1. У вас слишком мало оперативной памяти.
  2. Соединение с базой данных закрывается при попытке подключения.

Вы можете попробовать этот код ниже.

# 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()

Это устраняет ошибку независимо от причины, особенно по второй.

Если это вызвано нехваткой ОЗУ, вы должны либо повысить эффективность соединения с базой данных из кода, из конфигурации базы данных, либо просто увеличить ОЗУ.

Я тоже столкнулся с этой ошибкой. Но даже при увеличении или любое увеличение стоимости в , ошибка сохраняется.

Что я сделал, так это я устранил свою базу данных:

  • Я проверил таблицы, где ошибка сохраняется
  • Затем я проверил каждую строку
  • Есть строки, которые можно извлекать, а есть строки, в которых только отображается ошибка.
  • Кажется, что в этих строках есть значение, которое вызывает эту ошибку
  • Но даже при выборе только основного столбца ошибка все равно появляется ( )

Решение, о котором я подумал, - это повторно импортировать базу данных. Хорошо, что у меня есть резервная копия этой базы данных. Но я только отбросил проблемную таблицу, а затем импортировал свою резервную копию этой таблицы. Это решило мою проблему.


Мой вывод об этой проблеме:

  • Всегда имейте резервную копию своей базы данных. Либо вручную, либо через задание CRON
  • Я заметил, что в затронутых строках есть специальные символы. Поэтому, когда я восстановил таблицу, я сразу же изменил параметры сортировки этой таблицы с к utf8_general_ci
  • Моя база данных работала нормально до того, как моя система внезапно столкнулась с этой проблемой. Возможно, это также как-то связано с обновлением базы данных MySQL нашим хостинг-провайдером. Так что частое резервное копирование просто необходимо!

Моя проблема заключалась в том, что я добавил конфигурацию SSL к соединению для производства, что нарушило мою локальную среду. Простой, но может помочь другим осознать свою проблему.

На всякий случай это кому-то поможет:

Я получил эту ошибку, когда открывал и закрывал соединения в функции, которая вызывалась из нескольких частей приложения. У нас слишком много соединений, поэтому мы подумали, что было бы неплохо повторно использовать существующее соединение или выбросить его и создать новое следующим образом:

  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 ($ database, $ host, $ user, $ password); } return self:: $ instance; } Что ж, оказывается, мы слишком тщательно убивали, и поэтому процессы, выполняющие важные дела в старом соединении, никогда не могли завершить свою работу. Итак, мы сбросили эти строки

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

и, поскольку оборудование и настройка машины позволяют это, мы увеличили количество разрешенных подключений на сервере, добавив

max_connections = 500

в наш файл конфигурации. На данный момент это устранило нашу проблему, и мы кое-что узнали об уничтожении соединений mysql.

Для пользователей, использующих XAMPP, в C:\xampp\mysql\bin\my.ini есть 2 параметра max_allowed_packet.

Другие вопросы по тегам