У журналах помилок MySQL я бачу ці досить мало попереджень:
120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets)Я не помічав жодної втрати даних сам по собі, тому мені цікаво, що означає це попередження або що викликає його, і як можна вирішити проблему, яка їх викликає. Це на RHEL 6.1 та MySQL Enterprise 5.5.
Відповіді:
Одним із безшумних вбивць MySQL Connections є пакет MySQL.
Спочатку давайте розберемося, що таке пакет MySQL.
Відповідно до сторінки 99 "Розуміння внутрішніх даних MySQL" (ISBN 0-596-00957-7) , ось пункти 1-3, що пояснюють пакети MySQL:
Код зв'язку в мережі MySQL був написаний з припущенням, що запити завжди досить короткі, а тому можуть бути відправлені та оброблені сервером за один фрагмент, який в термінології MySQL називається пакетом . Сервер виділяє пам'ять на тимчасовий буфер для зберігання пакету, і він вимагає достатньо, щоб повністю вмістити його. Ця архітектура вимагає запобіжних заходів, щоб уникнути втрати пам’яті сервера --- обмеження розміру пакету, яке виконується цим параметром.
Код, що цікавить цей параметр, можна знайти в sql / net_serv.cc . Погляньте на my_net_read () , потім слідкуйте за викликом до my_real_read () і зверніть особливу увагу на net_realloc () .
Ця змінна також обмежує довжину результату багатьох функцій струн. Докладніше див. Sql / field.cc та sql / intem_strfunc.cc .
Знаючи це про MySQL Packets, дозволяє розробнику / DBA розміру їх розміру для розміщення декількох BLOB в одному пакеті, навіть якщо вони неприємно великі. Однозначно, занадто малий пакет може спричинити проблеми з відкритими з'єднаннями в цьому відношенні.
Відповідно до документації MySQL
Ви також можете отримати ці помилки, якщо надішлете запит на сервер, який є неправильним або занадто великим. Якщо mysqld отримує занадто великий пакет або вийшов із ладу, він припускає, що з клієнтом щось пішло не так і закриває з'єднання. Якщо вам потрібні великі запити (наприклад, якщо ви працюєте з великими стовпцями BLOB), ви можете збільшити ліміт запитів, встановивши змінну max_allowed_packet на сервері, яка має значення за замовчуванням 1MB. Можливо, вам також знадобиться збільшити максимальний розмір пакета на клієнтському кінці. Більш детальна інформація про встановлення розміру пакета наведена у Розділі C.5.2.10, "Пакет занадто великий".
Оператор INSERT або REPLACE, який вставляє велику кількість рядків, також може викликати подібні помилки. Будь-яка з цих операторів надсилає сервер один запит незалежно від кількості рядків, які потрібно вставити; таким чином, ви часто можете уникнути помилки, зменшивши кількість рядків, надісланих за INSERT або ЗАМІНЮ.
РЕКОМЕНДАЦІЯ
Спробуйте підняти max_allowed_packet на значно більшу кількість, оскільки за замовчуванням дорівнює 1М. Я б запропонував приблизно в 10 разів найбільше поле TEXT або BLOB у вашому поточному наборі даних.
Щоб встановити max_allowed_packet на 256M, ви можете додати його в /etc/my.cnf або my.ini
[mysqld]
max_allowed_packet=256Mдля покриття майбутніх перезавантажень mysqld. Щоб встановити значення зараз на сервері, будь ласка, запустіть це:
SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;Спробувати !!!
Переважно за замовчуванням max_connections буде 100. Спробуйте збільшити параметр config
max_connections = 400, після установки в my.cnf перезавантажте сервер або встановіть його динамічно:
set @@global.max_connections = 400;Просто спробуйте наведену вище рекомендацію, щоб уникнути цих попереджувальних повідомлень, а також переконайтесь, що у вашій мережі немає крапель пакетів.
Нещодавно я зіткнувся з цією проблемою після переходу з MySQL Enterprise 5.1.x до 5.7.x , без значних змін коду додатку почала з’являтися « примітка ».
У моєму випадку першопричиною появи « примітки » була програма, яка виходила з відкритими з’єднаннями. Обставина того, що з'єднання не були закриті, було трохи більше пов'язане і не пов'язане з MySQL, але ACE, потоками та TSS.