Код помилки: 2013. Втрачений зв’язок із сервером MySQL під час запиту

Я отримав код помилки: 2013. Втрачений зв’язок із сервером MySQL під час помилки запиту, коли я намагався додати індекс до таблиці за допомогою MySQL Workbench. Я також помітив, що вона з’являється щоразу, коли я запускаю довгі запити.

Чи є можливість збільшити значення тайм-ауту?

У нових версіях MySQL WorkBench є можливість змінити певні тайм-аути.

Для мене це було в розділі Правка → Налаштування → Редактор SQL → Час очікування з'єднання СУБД (у секундах): 600

Змінено значення на 6000.

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

Запуск сервера БД з опцією comandline net_read_timeout/ wait_timeoutі відповідного значення (в секундах) - наприклад: --net_read_timeout=100.

Для ознайомлення дивіться тут і тут .

Якщо у вашому запиті є дані про краплі, цю проблему можна усунути, застосувавши my.iniзміну , запропоновану в цій відповіді :

[mysqld]
max_allowed_packet=16M

За замовчуванням це буде 1М (допустиме максимальне значення - 1024М). Якщо подане значення не кратне 1024K, воно автоматично округляється до найближчого кратного 1024K.

У той час як посилання нитка про помилку MySQL 2006 , встановлюючи max_allowed_packetвід 1М до 16М зробив виправлення помилки 2013 , який показав на мене , коли працює довгий запит.

Для користувачів WAMP: прапор ви знайдете в [wampmysqld]розділі.

Додайте у файл / etc / mysql / cnf:

innodb_buffer_pool_size = 64M

приклад:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

SET @@local.net_read_timeout=360;

Попередження: Якщо ви застосовуєте його у віддаленому з'єднанні, наступні дії не працюватимуть:

SET @@global.net_read_timeout=360;

Існує три ймовірні причини цього повідомлення про помилку

1. Зазвичай це вказує на проблеми з підключенням до мережі, і вам слід перевірити стан вашої мережі, якщо ця помилка трапляється часто
2. Іноді форма "під час запиту" трапляється, коли мільйони рядків надсилаються як частина одного або декількох запитів.
3. Рідше це може статися, коли клієнт намагається здійснити початкове підключення до сервера

Детальніше читайте >>

Причина 2:

SET GLOBAL interactive_timeout=60;

від замовчування від 30 секунд до 60 секунд або довше

Причина 3:

SET GLOBAL connect_timeout=60;

Дякую! Це спрацювало. Але з оновленнями mysqldb конфігурація стала:

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

Ви повинні встановити властивості 'interactive_timeout' та 'wait_timeout' у файлі конфігурації mysql на потрібні вам значення.

Просто виконати MySQL оновлення , що буде заново будувати InnoDB двигун поряд з відновленням багатьох таблиць , необхідних для правильного функціонування MySQL , таких як performance_schema, information_schemaі т.д.

Випустіть нижче команду зі своєї оболонки:

sudo mysql_upgrade -u root -p

Я знаю його старе, але на Mac

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.

Змініть час "час очікування читання" в меню Правка-> Налаштування-> Редактор SQL-> сеанс MySQL

Спробуйте зняти прапорці в рядках у меню Правка → Налаштування → SQL-запити

тому що ви повинні встановити властивості 'interactive_timeout' та 'wait_timeout' у файлі конфігурації mysql на потрібні вам значення.

Якщо ви зіткнулися з цією проблемою під час відновлення великого дамп-файлу і виключаєте проблему, пов'язану з мережею (наприклад, виконанням на localhost), ніж моє рішення може бути корисним.

Мій mysqldump мав принаймні одну ВСТУП, яка була занадто великою для обчислення mysql. Ви можете переглянути цю змінну, ввівши show variables like "net_buffer_length";всередині свого mysql-cli. У вас є три можливості:

• збільшити net_buffer_length всередині mysql -> для цього знадобиться перезапуск сервера
• створити дамп із --skip-extended-insert, на кожну вставку використовується один рядок -> хоча ці звалища набагато приємніше читати, це не підходить для великих дампів> 1 Гб, оскільки це, як правило, дуже повільно
• створити дамп із розширеними вставками (що за замовчуванням), але обмежте чисту довжину-buffer_length, наприклад, --net-buffer_length NR_OF_BYTESде NR_OF_BYTES менше, ніж net_buffer_length сервера -> Я думаю, що це найкраще рішення, хоча повільніше перезапуск сервера не потрібен.

Я використовував таку команду mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile

У мене виникла та сама проблема під час завантаження .csv-файлу. Перетворено файл у .sql.

Використовуючи команду нижче, мені вдається обійти цю проблему.

mysql -u <user> -p -D <DB name> < file.sql

Сподіваюся, це допоможе.

Якщо всі інші рішення тут не вдається - перевірте свій syslog (/ var / log / syslog або подібне), щоб побачити, чи не вистачає пам’яті у вашого сервера під час запиту.

Була ця проблема, коли innodb_buffer_pool_size був встановлений занадто близько до фізичної пам'яті без налаштування swapfile. MySQL рекомендує встановити для сервера бази даних налаштування innodb_buffer_pool_size максимум біля 80% фізичної пам'яті , у мене встановлено приблизно 90%, ядро ​​вбивало процес mysql. Переміщений innodb_buffer_pool_size повернувся до рівня приблизно 80%, що вирішило проблему.

У моєму випадку встановлення інтервалу очікування підключення до 6000 або щось вище не спрацювало.

Я просто зробив те, що говорить верстат, що я можу зробити.

Максимальний час, який запит може зайняти для повернення даних із СУБД. Установіть 0, щоб пропустити час очікування читання.

У Mac Preferences -> SQL Editor -> Перейдіть до MySQL Session -> встановіть інтервал очікування зчитування підключення до 0.

І це працює 😄

Я зіткнувся з цим самим питанням. Я вважаю, що це трапляється, коли у вас є зовнішні ключі до більших таблиць (що вимагає часу).

Я спробував знову запустити оператор створення таблиці без зовнішніх ключових декларацій і виявив, що це працює.

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

Сподіваюся, що це комусь допоможе.

Це сталося зі мною, оскільки мій innodb_buffer_pool_size був встановлений на більший розмір оперативної пам’яті, доступний на сервері. Речі перервалися через це, і це видає цю помилку. Виправлення полягає в тому, щоб оновити my.cnf правильним налаштуванням для innodb_buffer_pool_size.

Перейдіть до редагування робочого столу → Налаштування → Редактор SQL → Час очікування з’єднань СУБД: До 3000. Помилка більше не сталася.

Йти до:

Правка -> Налаштування -> Редактор SQL

Там ви можете побачити три поля в групі "MySQL Session", де тепер можна встановити нові інтервали з'єднання (у секундах).

Виявляється, наше правило брандмауера блокувало моє з'єднання з MYSQL. Після того, як політика брандмауера буде знята, щоб дозволити з'єднання, я зміг успішно імпортувати схему.

У мене була така ж проблема - але для мене рішення було користувачем БД із занадто суворими дозволами. Я повинен був дозволити Executeвміння на mysqlстолі. Після дозволу у мене більше не було падіння з'єднань

Перевірте, чи немає індексів спочатку.

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

Я зіткнувся з цим під час запуску збереженої програми, яка створювала багато рядків у таблиці в базі даних. Я помітив, що помилка прийшла відразу після того, як час перейшов межу 30 секунд.

Я спробував усі пропозиції в інших відповідях. Я впевнений, що деякі з них допомогли, однак - те, що насправді змусило мене працювати, - це перейти на SequelPro з Workbench.

Я здогадуюсь, що я не міг помітити в Workbench зв’язок на стороні клієнта. Може, це допоможе і комусь іншому?

Якщо ви використовуєте SQL Work Bench, ви можете спробувати скористатись індексуванням, додавши індекс до своїх таблиць, додати індекс, натисніть на значок гайкового ключа (гайкового ключа) на столі, він повинен відкрити налаштування для таблиці, нижче , натисніть на перегляд індексу, введіть ім'я індексу та встановіть тип індексу, у стовпцях індексів виберіть основний стовпчик таблиці.

Зробіть той же крок для інших первинних ключів в інших таблицях.

Здається, тут відсутня відповідь для тих, хто використовує SSH для підключення до своєї бази даних MySQL. Потрібно перевірити два місця не 1, як пропонують інші відповіді:

Правка робочого столу → Налаштування → Редактор SQL → СУБД

Правка верстака → Налаштування → SSH → Часи очікування

Мої тайм-аути SSH за замовчуванням були встановлені дуже низько і спричиняли деякі (але, мабуть, не всі) проблеми з моїм тайм-аутом. Після цього не забудьте перезапустити MySQL Workbench!

Нарешті, можливо, варто звернутися до вашого адміністратора БД та попросити його збільшити властивості wait_timeout & interactive_timeout в самому mysql через перезапуск my.conf + mysql або зробити глобальний набір, якщо перезапуск mysql не є варіантом.

Сподіваюсь, це допомагає!

Три речі, які слід дотримуватися та переконайтесь у цьому:

1. Чи кілька запитів показують втрачене з'єднання?
2. як ви використовуєте встановлений запит у MySQL?
3. як видалити + оновити запит одночасно?

Відповіді:

1. Завжди намагайтеся видалити дефінір, оскільки MySQL створює власний дефінітор, і якщо кілька оновлених таблиць для оновлення намагаються зробити один запит, оскільки іноді кілька запитів показує втрачене з'єднання
2. Завжди SET значення вгорі, але після DELETE, якщо його стан не включає значення SET.
3. Використовуйте ВИДАЛЕННЯ ПЕРШОГО ОНОВЛЕННЯ, ЯКЩО БУДЬ ТОМИ ОПЕРАЦІЙ ВИКОНАННЯ НА РІЗНИХ ТАБЛИЦЯ

перевірити о

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

Сподіваюсь, це допомагає

Зазвичай це означає, що у вас "несумісність з поточною версією MySQL Server", див. Mysql_upgrade. Я зіткнувся з цим самим питанням і просто довелося бігти:

mysql_upgrade --password У документації зазначено, що "mysql_upgrade має виконуватися кожного разу при оновленні MySQL".