Mysql connect error localhost 2006 mysql server has gone away 400 - Исправление ошибок и поиск оптимальных решений проблем

Содержание

Ошибка 2006: MySQL server has gone away
Как исправить MySQL server has gone away
1. Истекло время ожидания
2. Слишком большой пакет
3. Сервер неверно проинициализирован
Выводы
Частые вопросы
Ошибки базы данных
MySQL Server Has Gone Away — как пофиксить
Таймаут соединения
Большой или некорректный пакет
Самое главное

Ошибка 2006: MySQL server has gone away

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

В этой небольшой статье мы рассмотрим более подробно, почему возникает ошибка 2006: MySQL server has gone away, а также — как её исправить.

Как исправить MySQL server has gone away

Такую ошибку вы можете увидеть во время подключения к базе данных с помощью PHP, консольного клиента или, например, в PhpMyAdmin:

1. Истекло время ожидания

Как я уже писал выше, одной из причин может быть таймаут ожидания соединения. Возможно, сервер баз данных перегружен и не успевает обрабатывать все соединения. Вы можете подключиться к серверу с помощью консольного клиента, если вам это удастся, и попытаться выполнить какой-либо запрос, чтобы понять, действительно ли запросы выполняются слишком долго. Если это так, можно оптимизировать производительность MySQL с помощью скрипта MySQLTuner.

В большинстве случаев надо увеличить размер пула движка InnoDB с помощью параметра innodb_buffer_pool_size. Какое значение лучше поставить, можно узнать с помощью указанного выше скрипта. Например, 800 мегабайт:

sudo vi /etc/mysql/my.cnf

Есть и другой путь решения этой проблемы. Если такая скорость обработки запросов считается нормальной, можно увеличить время ожидания ответа от сервера. Для этого измените значение параметра wait_timeout. Это время в секундах, на протяжении которого надо ждать ответа от сервера. Например:

После любых изменений не забудьте перезапустить MySQL сервер:

sudo systemctl restart mysql

sudo systemctl restart mariadb

2. Слишком большой пакет

Если ваш клиент MySQL создаёт слишком большие пакеты с запросами к серверу, это тоже может стать причиной такой ошибки. Максимально доступный размер пакета можно увеличить с помощью параметра max_allowed_packet. Например:

sudo vi /etc/mysql/my.cnf

Обратите внимание, что если вы из своей программы отправляете большие пакеты, то, скорее всего, вы делаете что-то не так. Не надо генерировать запросы к MySQL с помощью циклов for. SQL — это отдельный язык программирования, который многое может сделать сам, без необходимости писать очень длинные запросы.

3. Сервер неверно проинициализирован

Такая проблема может возникать при разворачивании контейнера MySQL или MariaDB в Docker. Дело в том, что на первоначальную инициализацию контейнера нужно много времени: около нескольких минут. Если вы не дадите контейнеру завершить инициализацию, а остановите его и потом снова запустите, то база данных будет всегда возвращать такую ошибку.

Вам нужно полностью удалить данные контейнера с базой данных. Например, с помощью docker-compose:

docker rm mysql-container

Здесь mysql-container — это имя контейнера с базой данных. А затем надо удалить хранилище (volume) с некорректно проинициализированной базой. Сначала посмотрите список всех хранилищ:

docker volume ls

Затем удалите нужное:

docker volume rm имя_хранилища

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

Выводы

В этой небольшой статье мы рассмотрели, что значит ошибка MySQL Server has gone away, а также как её исправить на сервере или в контейнере Docker. Вы знаете ещё другие причины и решения этой проблемы? Пишите в комментариях!

Источник

Частые вопросы

Ошибки базы данных

MySQL server has gone away или Lost connection to server during query

Не отвечает сервер при сохранении данных формы под MSSQL

При переносе на другой хостинг: «#1064 — You have an error in your SQL syntax. ‘DEFAULT CHARSET=. «

При установке на Oracle выдает следующую ошибку: ORA-01704: string literal too long

Неправильно сортируются элементы в списках

Server shutdown in progress

Out of range value adjusted for column ‘USER_ID’ или Incorrect integer value: » for column ‘SESS_SESSION_ID’

Access denied for user: ‘ user @%’ to database ‘dab_test’

DB query error. Please try later

Out of memory; restart server and try again (needed XXXXX bytes)

Got error 28 from table handler

Ошибки БД: «Incorrect key file», «Can’t open file», «Incorrect information in file» и др.

MySQL server has gone away или Lost connection to server during query

В процессе выполнения запроса сервер оборвал соединение. Проблема связана с настройкой MySQL и часто возникает когда на сервере установлен небольшой лимит времени на соединение.

Установите в bitrix/php_interface/after_connect.php:

$DB->Query(«SET wait_timeout=28800»);

Если проблема останется — обратитесь к администратору хостинга.

Наверх

Не отвечает сервер при сохранении данных формы под MSSQL

Проблема часто возникает из за низкого значения параметра PHP odbc.defaultlrl, по умолчанию равного 4096.

Вам необходимо существенно увеличить его, например, до 64000.

Наверх

При переносе на другой хостинг: «#1064 — You have an error in your SQL syntax. ‘DEFAULT CHARSET=. «

Проблема возникает в связи с тем, что дамп БД создается в MySQL версии 4.1 или выше, а устанавливается на более ранней версии MySQL, которая не поддерживает объявление кодировки для таблицы.

Для решения проблемы воспользуйтесь опцией mysqldump: —compatible=mysql40

Наверх

При установке на Oracle выдает следующую ошибку: ORA-01704: string literal too long

Скорее всего, Вы устанавливаете систему при установленной кодировке UTF8 в Oracle.

Установите значение параметра NLS_LANG, например, в AMERICAN_AMERICA.CL8MSWIN1251

Значение параметра Вы можете прописать в реесте Windows, в ветке HLM/SOFTWARE/ORACLE

Наверх

Неправильно сортируются элементы в списках

Возможны разные варианта проблемы:

Обратитесь за решением данной проблемы к администратору хостинга.

2. Проверьте значения, отвечающие за кодировку БД: character_set, или, для версий MySQL 4.1 и выше, character_set_server и character_set_database. При использовании кодировки, отличной от cp1251 (кириллица), например, latin1, сортировка по строкам, содержащим символы кириллицы, будет производиться некорректно. Проверить это можно выполнив запрос к БД

show variables like ‘char%’;

Для решения проблемы установить в файле /bitrix/php_interface/after_connect следующие строки

$DB->Query(«SET NAMES cp1251»);

Если указанные действия не помогают, то выполните перенос системы (установку) еще раз, создавая дамп БД в кодировке cp1251 и создав новую БД тоже в кодировке cp1251.

Наверх

Server shutdown in progress

Часто такая ошибка возникает, когда на сервере установлено ограничение на ресурсы, отводимое операционной системой на тот или иной процесс. Вам нужно обратиться к системному администратору хостинга с тем, чтобы он дал ответ — по какой причине процесс mysql-сервера перезапускается.

Наверх

Out of range value adjusted for column ‘USER_ID’ или Incorrect integer value: » for column ‘SESS_SESSION_ID’

Скорее всего, у вас установлен MySQL версии 5.x

Вам необходимо из значения для переменной sql-mode убрать STRICT_TRANS_TABLES.

1 вариант: изменение конфигурации сервера через my.cnf. Например,

sql-mode=»NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION»

sql-mode=»STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION»

2 вариант: если у Вас нет доступа к конфигурационным файлам MySQL-сервера, попробуйте в /bitrix/php_interface/after_connect.php добавить строку:

$DB->Query(«set sql_mode=»»)

Подробнее на официальном сайте:

Наверх

Access denied for user: ‘ user @%’ to database ‘dab_test’

Начиная с 4-ой версии MySQL права на LOCK назначаются отдельно.

Необходимо дополнительно назначить права на LOCK TABLES для данного пользователя базы данных.

Наверх

DB query error. Please try later

Для решения проблемы в файле /bitrix/php_interface/dbconn.php установите значение переменной $DBDebug в значение true.

После этого обновите страницу: на экране появится текст ошибки. Передайте его в службу нашу поддержки.

Наверх

Out of memory; restart server and try again (needed XXXXX bytes)

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

Также рекомендуем вам установить следующие значения для MySQL в файле my.cnf:

key_buffer = 64M
max_allowed_packet = 8M
table_cache = 256
sort_buffer_size = 8M
read_buffer_size = 1M

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

Наверх

Got error 28 from table handler

Это сообщение об ошибке означает, что не осталось свободного дискового пространства для работы MySQL.

Обратитесь к системному администратору Вашего сервера для решения проблемы.

Наверх

Ошибки БД: «Incorrect key file», «Can’t open file», «Incorrect information in file» и др.

Эта проблема характерна для базы данных MySQL, таблиц в формате MyISAM.

Для решения проблемы в окне SQL-запроса выполните

repair table b_search_content_stem

b_search_content_stem — имя неработающей таблицы.

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

Источник

MySQL Server Has Gone Away — как пофиксить

Технический редактор Highload

Ошибка MySQL Server Has Gone Away (error 2006) может возникнуть в двух случаях.

Собираем на дрон для штурмовиков Николаевской области. Он поможет найти и уничтожить врага

Таймаут соединения

Наиболее распространенная проблема: таймаут соединения, в результате чего сервер его закрывает. Решение весьма тривиальное — увеличение лимита времени wait_timeout в файле конфигурации my.cnf . Для этого в Debian нужно выполнить:

Открытие файла настроек MySQL

Затем установить тайм-аут ожидания:
wait_timeout = 600

Время ожидания в секундах, можно установить вплоть до 28800 с (8 часов)

Не забудьте перезагрузить базу:
sudo /etc/init.d/mysql restart

Перезагрузка базы данных MySQL

Иногда, при выполнении длительных запланированных задач, также может появиться ошибка MySQL Server Has Gone Away все из-за того же таймаута соединения. При этом лимит времени не получится существенно увеличить (максимум до нескольких часов), так как это может привести к заполнению буфера ожидающими соединениями.

Поэтому лучше проверить соединение и, при необходимости, переподключиться.

Подключение БД и переподключение при необходимости

Большой или некорректный пакет

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

Увеличение лимита размера входящего пакета, в МБ

Также не забудьте перезагрузить базу данных.

Самое главное

После того, как устраните ошибку MySQL Server Has Gone Away, поиграйтесь с параметрами wait_timeout и max_allowed_packet для получения оптимальных лимитов.

Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность.

Источник

Adblock
detector

Источник

1. Истекло время ожидания

sudo vi /etc/mysql/my.cnf

innodb_buffer_pool_size=800M

wait_timeout=600

После любых изменений не забудьте перезапустить MySQL сервер:

sudo systemctl restart mysql

или:

sudo systemctl restart mariadb

2. Слишком большой пакет

sudo vi /etc/mysql/my.cnf

max_allowed_packet=128M

3. Сервер неверно проинициализирован

Вам нужно полностью удалить данные контейнера с базой данных. Например, с помощью docker-compose:

docker-compose down

или вручную:

docker rm mysql-container

docker volume ls

Затем удалите нужное:

docker volume rm имя_хранилища

Выводы

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

Источник

The MySQL server has gone away error, which means that the MySQL server (mysqld) timed out and closed the connection. By default, MySQL will close connections after eight hours (28800 seconds) if nothing happens. However, in some cases, your web host, DBA, or app developer may have decreased this timeout setting, as discussed below.

MySQL server has gone away, can be a frustrating error to solve. This is partly because, to solve this error, sometimes the solution involves multiple layers, application, or service config changes. This article includes solutions I’ve seen for this MySQL server general error. If you’ve found a solution not listed or linked to on this page, please send me a note or leave a comment.

MySQL server has gone away error log examples.

Keep in mind that this error can be logged in a few ways, as listed below. In addition, at times, the error is only an indication of a deeper underlying issue. Meaning the error could be due to a problem or bug in your connecting application or remote service. In this case, you need to check ALL related error logs with the same timestamp to determine whether another issue may be to blame. Application Performance Monitoring solutions and PHP Stack trace tools can be of help. With this in mind, here are error log examples of the MySQL server has gone away error:

General error: 2006 MySQL server has gone away

Error Code: 2013. Lost connection to MySQL server during query

Warning: Error while sending QUERY packet

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

Sponsored: Datadog – View query metrics and explain plans from all of your databases in a single place.

Datadog is a unified monitoring, analytics, and security platform that offers end-to-end monitoring for all of your databases, including MySQL, PostgreSQL, and more! Quickly pinpoint costly, slow queries and troubleshoot performance issues faster with key database metrics and patterns in one place. Easily search, compare, and filter your queries on execution plans to quickly identify areas for performance and cost improvements. Utilize our integrations for MySQL, PostgreSQL, SQL Server, and more to visualize key system performance metrics on an out-of-the-box dashboard alongside query and host-level metrics. Datadog Database Monitoring is closely integrated with the rest of the Datadog platform; further improve your Database performance with other key features such as SLO tracking, monitors & alerts, Security Monitoring, and more!

Cost: Free plan, or starting at $70.

MySQL wait_timeout

The reason for MySQL server has gone away error is often because MySQL’s wait_timeout was exceeded. MySQL wait_timeout is the number of seconds the server waits for activity on a non-interactive connection before closing it. You should make sure the wait_timeout is not set too low. The default for MySQL wait_timeout is 28800 seconds. Often, it gets lowered arbitrarily. That said, the lower you can set wait_timeout without affecting database connections, can be a good sign of MySQL database efficiency. Also, check the variables: net_read_timeout, net_write_timeout and interactive_timeout. Adjust or add the following lines in my.cnf to meet your requirements:

wait_timeout=90
net_read_timeout=90
net_write_timeout=90
interactive_timeout=300
connect_timeout=90

MySQL connect timeout in PHP config.

Have a look at your php.ini config file. You’ll find MySQL configuration options. Make sure the mysql.connect_timeout setting isn’t set lower than MySQL wait_timeout, discussed above. The PHP option mysql.connect_timeout is not only used for connect timeout. It’s also when waiting for the first response from the MySQL server. Try increasing mysql.connect_timeout to match or exceed your MySQL wait_timeout and make sure that mysql.allow_persistent is on (default = enabled).

mysql.connect_timeout=90
mysql.allow_persistent=1

IMPORTANT: Read first about PHP Persistent Database Connections to understand the benefits and caveats.

Also, adjust PHP’s default_socket_timeout. For example, a PHP script could be running a slow query. Creating a wait that utilizes the default_socket_timeout. Eventually, it quits with the “MySQL server has gone away” error. Before you send hate mail, please read here first. Here’s an excerpt:

“PHP, by default, sets a read timeout of 60s for streams. This is set via php.ini, default_socket_timeout. This default applies to all streams that set no other timeout value. mysqlnd does not set any other value and therefore connections of long running queries can be disconnected after default_socket_timeout seconds resulting in an error message 2006 – MySQL Server has gone away.”

default_socket_timeout=90

To be throughout, also adjust max_execution_time and max_input_time still in php.ini, if necessary. If PHP’s execution time is longer than max_execution_time, then MySQL server might disconnect.

max_execution_time = 90
max_input_time = 90

MySQL max_allowed_packet

max_allowed_packet is the maximum size of one packet. The default size of 4MB helps the MySQL server catch large (possibly incorrect) packets. As of MySQL 8, the default has been increased to 16MB. If mysqld receives a packet that is too large, it assumes that something is wrong and closes the connection. To fix this, you should increase the max_allowed_packet in my.cnf, then restart MySQL. The max for this setting is 1GB. For example:

max_allowed_packet = 512M

MySQL innodb_log_file_size

You may need to increase the innodb_log_file_size MySQL variable in your my.cnf configuration. MySQL’s innodb_log_file_size should be 25% of innodb_buffer_pool_size (if possible, no less than 20%). Remember that the larger this value, the longer it will take to recover from a database crash. (Source: Phpmyadmin Advisor)

This means for example: if your buffer pool size is set to innodb_buffer_pool_size=16G and your innodb_log_files_in_group setting is still set to the recommended default of 2 files (innodb_log_files_in_group=2), then your innodb_log_file_size should be set to 2G. This will create two (2) log files at 2GB each, which equals 25% of innodb_buffer_pool_size=16G.

WARNING: You must stop MySQL server in order to change innodb_log_file_size or innodb_log_files_in_group. If you don’t, you risk catastrophe! (Read: MySQL Log Redo instructions.)

Other causes of MySQL server has gone away

Remote MySQL connections

Remember earlier I mentioned that the error, at times, is only an indication of a deeper underlying issue. For example, remote MySQL connections to 3rd party services. Using a 3rd party payment processing plugin for osCommerce, Magento, etc.

MySQL database charset and collation

Changing default database charset to latin1 and default collation to latin1_general_ci seemed to have solved MySQL server has gone away for some.

Exceeding MySQL max_connections setting

Max_connections set the maximum permitted number of simultaneous client connections. Be careful with this setting!! Exhaustion of memory and other resources can occur when set too large and scheduling overhead also increases. As a guide, set max_connections to approximately double the previous number of maximum simultaneous client connections. E.g., if after a month of uptime, the maximum simultaneous client connections were 114, then set to max_connections=250. Before you go crazy with this setting, please read: How MySQL Handles Client Connections.

Still unresolved? See MySQL’s help page.

Oracle has put together a nice self-help page for MySQL server has gone away errors. On that page, they also suggest that you make sure MySQL didn’t stop/restart during the query. Excerpt:

“You can check whether the MySQL server died and restarted by executing mysqladmin version and examining the server’s uptime. If the client connection was broken because mysqld crashed and restarted, you should concentrate on finding the reason for the crash.”

# mysqladmin version
mysqladmin Ver 9.1 Distrib 10.1.40-MariaDB, for Linux on x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Server version 10.1.40-MariaDB
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/lib/mysql/mysql.sock
Uptime: 20 days 11 hours 49 min 40 sec

Threads: 5 Questions: 1030744326 Slow queries: 3343 Opens: 3585 Flush tables: 1 Open tables: 2564 Queries per second avg: 582.150

# mysqladmin status
Uptime: 1770590 Threads: 4 Questions: 1030752268 Slow queries: 3343 Opens: 3585 Flush tables: 1 Open tables: 2564 Queries per second avg: 582.151

I hope this helps!

Related articles:

MySQL Performance Tuning: Tips, Scripts and Tools
Tuning MySQL: my.cnf, avoid this common pitfall!
MySQL Performance: Stop hoarding. Drop unused MySQL databases

Published: June 7th, 2019 | Last updated: Nov 10th, 2022

Tags: apm, linux, mariadb, mysql, performance, server, sysadmins

Источник

We all like when error messages are descriptive and give a clear idea about what is happening; however, there are some cases when a few possible reasons lay behind one error message. “MySQL server has gone away” is one of them. Most of the cases when the error occurs are described in MySQL documentation, but it can get tricky. And here, I’d like to talk about “tricky”.

There are only a few major cases when this happens:

1. MySQL Thread Was Killed by an Administrator or a Utility Such as pt-kill

The manual intervention is likely to be intermittent and, as it is a one-time thing in certain situations (e.g., a bad long-running query), probably would be known to a DBA. Pt-kill might be less noticeable, as it is often left running as a workaround to prevent those bad long queries from taxing system resources. Checking the system processlist should bring the commands to the surface:

$ ps xauf | grep pt—kill

taras 6069 0.1 0.1 111416 29452 pts/29 S+ 10:57 0:00 | | _ perl /usr/bin/pt—kill —interval 1s —busy—time 5s —match—info (SELECT) h=127.0.0.1 —print —kill

taras 6913 0.0 0.0 21532 1112 pts/30 S+ 11:00 0:00 | _ grep —color=auto pt—kill

A very convenient way is to use the audit plugin available for Percona Server for MySQL to determine where the kill command came from:

<AUDIT_RECORD>

<NAME>Query</NAME>

<COMMAND_CLASS>kill</COMMAND_CLASS>

<CONNECTION_ID>17</CONNECTION_ID>

<SQLTEXT>KILL QUERY 16</SQLTEXT>

<USER>taras[taras] @ localhost []</USER>

<HOST>localhost</HOST>

<OS_USER></OS_USER>

</AUDIT_RECORD>

It shows the hostname, user, and time when the connection got killed.

2. Big Data Chunk Transfer

For example, when using BLOB fields to store binary data in a table or there is an INSERT statement containing a lot of rows. It may happen when using the MySQL CLI client (one of the cases being loading an SQL dump), or it can happen within an application when it tries to store the BLOB data (for example, from a file upload).

There is a limit MySQL imposes on the amount of data that can be transmitted per query, and the max_allowed_packet variable defines it.

So, in both cases, we need to determine which table the data is being written to, for instance, grepping the SQL file for INSERT INTO statements and implementing logging on the application end. This way, the statement will be stored along with the error that prevented it from completing. A partial statement can be captured (as BLOBs could be a burden to log), but as long as there is a table name, it is possible to check the table structure and see if it does contain binary data.

Example of an INSERT statement with binary data (truncated):

INSERT INTO t1 VALUES (1, x‘89504….82’)

To allow for a larger query execution, the variable needs to be adjusted:

SET GLOBAL max_allowed_packet = 128M ;

The variable can be set per session or globally, depending on the use case.

3. The Connection Was Closed by Timeout

It is trivial, but applications can be reusing already-established connections. During the time of inactivity or lower traffic, it is possible some connections will not be used for a while and closed on the MySQL end. It is traced best with the application logging; if there is an event that happened in the evening followed by a period of inactivity and then the error in the morning, it is very likely that MySQL closed the connection.

mysql> SET SESSION wait_timeout = 5 ;

Query OK, 0 rows affected (0.00 sec)

Wait for 5 seconds:

mysql> select 1 ;

ERROR 2006 (HY000): MySQL server has gone away

No connection. Trying to reconnect...

Connection id: 16

Current database: *** NONE ***

+—+

| 1 |

+—+

| 1 |

+—+

1 row in set (0.01 sec)

Usually, the connection is re-established, and the application continues normal operations; yet it is always possible to extend the timeout in MySQL configuration:

SET GLOBAL wait_timeout = 57600 ;

The default value for the variable is 28800 seconds (8 hours), which is enough in most cases.

Also, closing connections cleanly from an application end, after a period of inactivity, eliminates this problem.

4. MySQL Server Has Actually Gone Away

This one is probably the worst possible scenario when MySQL crashes on a query or due to some other reason, e.g., the OOM killer killed the process. However, it can be caused by a clean restart, too.

In this case, one should check MySQL uptime and the logs, MySQL error log, and syslog. Those should indicate whether the server restart occurred and if there was an error leading to the restart.

In case the server did crash, it is time to find the actual cause. Check the bug tracker, as the issue might have been reported and possibly fixed already; upgrade MySQL if needed. In case it was a clean restart, check if auto-updates are enabled or if someone else restarted the service interactively (yes, lack of communication is a thing too).

Источник

mysql

Две наиболее распространенные причины получения ошибки MySQL server has gone away (error 2006) это..

Сервер закрыл соединение по таймауту.

Исправить можно так: проверить чтобы значение переменной wait_timeout в конфиг файле MySql — my.cnf было достаточным для выполнения скрипта.

На Debian: нужно выполнить

sudo nano /etc/mysql/my.cnf

и установить wait_timeout = 600 ( значение задается в секундах, если ошибка не пропадет поиграйтесь с этим значением, чтобы найти оптимальное), после этого нужно рестартануть MySQL:

sudo /etc/init.d/mysql restart

Я не проверял, но значение по-умолчанию для wait_timeout можно установить вплоть до 28800 секунд (8 часов).

Сервер сбрасывает (отклоняет) неправильные или слишком большие пакеты. Если mysqld получает пакет данных, который слишком большой или не корректный, он думает что что-то пошло не так или с клиентом случилась какая-то беда и закрывает соединение. Часто такая ошибка возникает при импорте дампов содержащих большие тексты.

Так же такое происходит, когда у Вас слишком большой запрос. Например, вы хотите в поле типа longtext записать какую-нибудь книгу, в которой текста на 20 мб. Либо хотите сохранить большой файл (например картинку) в поле с типом blob. В итоге у вас получается запрос по типу

UPDATE books SET text=«сууупер..длинный..текст» WHERE id=1

Если это Ваш случай, то подумайте действительно ли Вам нужно сохранять такой текст/файл в базу, обычная практика в таких случаях, сохранить его в файл на диск, а в базу сохранить имя этого файла. Типа того

file_put_content(‘book.txt’, ‘сууупер..длинный..текст’);

...

UPDATE books SET filename=«book.txt» WHERE id=1

Исправить можно так: вы можете увеличить максимальный размер пакета увеличив значение max_allowed_packet в файле my.cnf.

На Debian нужно выполнить:

sudo nano /etc/mysql/my.cnf

и установить max_allowed_packet = 64M (если ошибка не пропадет поиграйтесь с этим значением, чтобы найти оптимальное), после этого нужно рестартануть MySQL

sudo /etc/init.d/mysql restart

Про max_allowed_packet я так же писал здесь: ERROR 2006 (HY000) — MySQL server has gone away

Если Вы получаете ошибку MySQL server has gone away (error 2006) при использовании драйвера MySQL ODBC – можете попробовать это решение.

Оригинал исходной статьи (на англ): How to fix “MySQL server has gone away” (error 2006)

Ошибка 2006: MySQL server has gone away

Как исправить MySQL server has gone away

1. Истекло время ожидания

2. Слишком большой пакет

3. Сервер неверно проинициализирован

Выводы

Частые вопросы

Ошибки базы данных

MySQL Server Has Gone Away — как пофиксить

Таймаут соединения

Большой или некорректный пакет

Самое главное

1. Истекло время ожидания

2. Слишком большой пакет

3. Сервер неверно проинициализирован

Выводы

Об авторе

MySQL server has gone away error log examples.

MySQL wait_timeout

MySQL connect timeout in PHP config.

MySQL max_allowed_packet

MySQL innodb_log_file_size

Other causes of MySQL server has gone away

Remote MySQL connections

MySQL database charset and collation

Exceeding MySQL max_connections setting

Still unresolved? See MySQL’s help page.

Tags: apm, linux, mariadb, mysql, performance, server, sysadmins

1. MySQL Thread Was Killed by an Administrator or a Utility Such as pt-kill

2. Big Data Chunk Transfer

3. The Connection Was Closed by Timeout

4. MySQL Server Has Actually Gone Away

Похожие статьи