В журналах ошибок 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 позволяет разработчику / администратору базы данных изменять их размер, чтобы вместить несколько BLOB-объектов в одном пакете, даже если они слишком большие. Определенно, слишком маленький пакет вызовет проблемы для открытых соединений в этом отношении.
Согласно документации MySQL
Вы также можете получить эти ошибки, если отправите запрос на сервер, который является неправильным или слишком большим. Если mysqld получает пакет, который слишком велик или не в порядке, он предполагает, что с клиентом что-то не так, и закрывает соединение. Если вам нужны большие запросы (например, если вы работаете с большими BLOB-столбцами), вы можете увеличить лимит запросов, установив переменную max_allowed_packet сервера, значение которой по умолчанию составляет 1 МБ. Вам также может понадобиться увеличить максимальный размер пакета на стороне клиента. Более подробная информация о настройке размера пакета приведена в разделе C.5.2.10, «Слишком большой пакет».
Операторы INSERT или REPLACE, которые вставляют большое количество строк, также могут вызывать подобные ошибки. Любой из этих операторов отправляет серверу один запрос независимо от количества вставляемых строк; таким образом, вы часто можете избежать ошибки, уменьшив количество строк, отправляемых за INSERT или REPLACE.
РЕКОМЕНДАЦИЯ
Попробуйте поднять max_allowed_packet до гораздо большего числа, поскольку по умолчанию установлено значение 1M. Я бы посоветовал примерно в 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.