Помилка MySQL 2006: сервер mysql пішов

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

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

2006, MySQL server has gone away

Я чув про налаштування MySQL, wait_timeout , але чи потрібно це змінити на сервері в моєму офісі або на віддаленому сервері MySQL?

Можливо, буде простіше перевірити, чи є з'єднання, і заново встановити його, якщо потрібно.

Інформацію про це див. У PHP: mysqli_ping .

Я неодноразово стикався з цим, і зазвичай я вважав, що відповідь є дуже низькою max_allowed_packet.

Підвищення його в /etc/my.cnf(під [mysqld]) до 8 або 16М зазвичай виправляє. (Типовим параметром у MySql 5.7 4194304є 4MB.)

[mysqld]
max_allowed_packet=16M

Примітка. Просто створіть рядок, якщо він не існує

Примітка. Це можна встановити на вашому сервері під час роботи.

Використовуйте set global max_allowed_packet=104857600. Це встановлює його в 100 Мб.

У мене була та ж проблема , але changeing max_allowed_packetв my.ini/my.cnfфайлі під [mysqld]зробив трюк.

додати рядок

max_allowed_packet = 500М

тепер, 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

Кредити та детальніше тут

Ця помилка виникає через закінчення терміну дії_чака.

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

mysql> ПОКАЗУЙТЕ ВАРІАБЛІСЬКІ ПОДІБНІ "wait_timeout"

mysql> встановити глобальний 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

Рамки, пов'язані:

• Перевірте налаштування своєї рамки. Наприклад, використання Джанго 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

І, це все виправляло. Я поставив його під кроном, щоб працювати щогодини.

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

Якщо ви використовуєте 64Bit WAMPSERVER, будь ласка, шукайте кілька випадків max_allowed_packet, тому що WAMP використовує значення, встановлене під [wampmysqld64], а не значення, встановлене в розділі [mysqldump], яке для мене було проблемою, я оновив неправильний. Встановіть це на зразок max_allowed_packet = 64М.

Сподіваємось, це допомагає іншим користувачам Wampserver там.

Це, як правило, вказує на проблеми з підключенням сервера MySQL або тайм-аути. Як правило, можна вирішити, змінивши wait_timeout та max_allowed_packet в my.cnf або подібному.

Я б запропонував ці значення:

wait_timeout = 28800

max_allowed_packet = 8М

Для 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 = 500М

innodb_log_file_size = 128М

Це мені дуже допомогло :)

коментуйте ligne нижче у вашому 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 він повинен бути "localhost".

І останній набір:

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

Потім перезапустіть Wampserver.

Щоб змінити ім'я користувача та пароль phpmyadmin

Ви можете безпосередньо змінити ім'я користувача та пароль phpmyadmin через файл config.inc.php

Ці два рядки

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

Тут ви можете ввести нове ім’я користувача та пароль. Після змін збережіть файл та перезапустіть сервер WAMP.

На робочому столі Ubuntu я отримав повідомлення про помилку 2006 року в різних клієнтських програмах MySQL. Виявилося, що моя версія драйвера JDBC була занадто стара.

Це може бути проблемою розміру вашого файлу .sql.

Якщо ви використовуєте xampp. Перейдіть на панель керування xampp -> Клацніть MySql config -> Open 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 7gb:

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

Для деяких може знадобитися також збільшити такі значення:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

Для користувачів, які використовують XAMPP, є два параметри 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; повернути себе :: newConnection ($ база даних, $ хост, $ користувач, $ пароль); } return self :: $ instance; } Добре виявляється, ми були занадто ретельними з убивством, і тому процеси, які робили важливі речі на старій зв'язку, ніколи не могли закінчити свою справу. Тому ми відкинули ці рядки

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

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

max_connections = 500

до нашого конфігураційного файла. Наразі це вирішило нашу проблему, і ми дізналися щось про вбивство mysql-зв’язків.

Якщо ви знаєте, що ви перебуваєте в режимі офлайн на деякий час, ви можете перервати з'єднання, обробити, підключитися та написати свої звіти.