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

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

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

2006, MySQL server has gone away

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

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

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

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

Увеличение его в /etc/my.cnf(под [mysqld]) до 8 или 16M обычно исправляет это. (Значение по умолчанию в 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;

Ошибка: 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

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

Эта ошибка возникает из-за истечения срока ожидания 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

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

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

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

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

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

• Проверьте значения переменных MySQL / MariaDB.
  • с sql: SHOW VARIABLES LIKE '%time%';
  • командная строка: mysqladmin variables
• Включите многословие для ошибок:
  • MariaDB: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Проверьте документы для получения дополнительной информации об ошибке

В 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

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

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

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

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

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

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

У меня была такая же проблема даже на сервере с 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

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

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

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

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

wait_timeout = 28800

max_allowed_packet = 8M

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

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

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

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

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

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

Это скажет вам.

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

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

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

max_allowed_packet = 500M

innodb_log_file_size = 128M

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

раскомментируйте строку ниже в вашем 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 была слишком старой.

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

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

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

max_allowed_packet = 2M -> 10M

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

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

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

Затем попробуйте снова выполнить запрос 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;

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

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

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

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

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

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

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

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

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

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

max_connections = 500

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

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