Ошибка MySQL 2006: сервер mysql ушел

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

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

2006, MySQL server has gone away

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

23 ответов


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

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


я сталкивался с этим несколько раз, и я обычно находил ответ очень низким значением по умолчанию max_allowed_packet. Поднимая его в /etc/my.cnf (при [mysqld]) до 8 или 16M обычно исправляет его.

[mysqld]
max_allowed_packet=16M

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

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


у меня была та же проблема, но изменение max_allowed_packet на под [mysqld] сделал трюк.

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

max_allowed_packet=500M

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


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

set global max_allowed_packet=268435456;

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

--max_allowed_packet=268435456

to ...\MAMP\bin\startMysql.sh

кредитов и более подробная информация здесь


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

EDIT: две другие настройки, которые вы также можете использовать, это net_write_timeout и net_read_timeout.


эта ошибка возникает из-за истечения wait_timeout .

просто перейдите на сервер mysql, проверьте его wait_timeout:

mysql> показать переменные, такие как'wait_timeout'

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

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


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

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

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

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


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

max_allowed_packet=8M

снова на php.Ини(программе XAMPP/PHP в/РНР.ini) измените размер выбора upload_max_filesize. е.г

upload_max_filesize=8M

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


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

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

В моем случае это было низкое значение 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

это была проблема с ОЗУ для меня.

у меня была такая же проблема даже на сервере с 12 ядрами процессора и 32 ГБ оперативной памяти. Я исследовал больше и попытался освободить RAM. Вот команда, которую я использовал на 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

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

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

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


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

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


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

# binary logging format - mixed recommended
# binlog_format=mixed

до

# binary logging format - mixed recommended
binlog_format=mixed

Я нашел решение для "#2006 - mysql server ушел " эта ошибка. Решение заключается в том, что вам нужно проверить два файла

  1. конфигурации.Инк.в PHP
  2. конфигурации.образец.Инк.в 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. конфигурации.Инк.в PHP
  2. конфигурации.образец.Инк.php-файлы должны быть "localhost".

и последний сет:

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

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


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

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

эти две строки

$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';
вы можете дать новое имя пользователя и пароль:. После изменений сохраните файл и перезапустите WAMP server.

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

Я бы предложил следующие значения:

wait_timeout = 28800

max_allowed_packet = 8М


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


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

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

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

max_allowed_packet = 2M -> 10M

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


это всегда хорошая идея, чтобы проверить журналы сервера Mysql, по той причине, почему он ушел.

Он скажет вам.


эта ошибка возникает в основном по двум причинам.

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

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

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


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