MySQL выравнивания нагрузки с помощью HAProxy: Получил ошибку при чтении коммуникационных пакетов?
Причины, указанные в MySQL docs :
Значение переменной max_allowed_packet слишком мало или запросы требуют больше памяти, чем вы выделили для mysqld. См. Раздел C.5.2.10, «Пакет слишком велик».
Использование протокола Ethernet в Linux, как полудуплексный, так и полнодуплексный. Много В драйверах Ethernet для Linux есть эта ошибка. Вы должны проверить эту ошибку передача огромного файла по FTP между клиентом и сервером машины. Если передача идет в режиме пакетной паузы-пакетной паузы, вы испытываете синдром дуплекса Linux. Переключите дуплексный режим для обоих ваша сетевая карта и концентратор / коммутатор в полный дуплекс или полудуплекс дуплексный режим и проверьте результаты, чтобы определить наилучшие настройки.
Проблема с библиотекой потоков, которая вызывает прерывания при чтении.
Плохо настроенный TCP / IP.
Неисправные Ethernet-сети, концентраторы, коммутаторы, кабели и т. д. . Это может быть правильно диагностируются только путем замены оборудования.
И это объясняет лучше:
Хотя они могут быть симптомом более серьезной проблемы, они могут быть вызвано обычными (то есть неразрешимыми) проблемами сети.
Даже если они находятся в одной локальной сети, по разным причинам, могут возникнуть ошибки связи между вашим сервером приложений и база данных. В случае коррупции или тайм-аутов приложений и / или MySQL, скорее всего, повторяет и работает, а проблема никогда не возникает и не проявляется.
По моему опыту, наиболее распространенные источники сообщений такого типа выпадают из приложения (сервера), приложение не завершение соединений должным образом или из-за задержек за пределами площадки репликация.
Вполне вероятно, что они происходили до того, как вы включили ошибку входа в систему. сервер MySQL.
Я обнаружил, что увеличение времени ожидания в файле haproxy.cfg решило эту ошибку. Я потратил много времени на проверку my.cnf wait_timeout и т. Д. И понял, что узким местом на самом деле является HAProxy.
check haproxy mannul
tune.idletimer
Устанавливает время, по истечении которого haproxy будет считать, что буфер пустой. вероятно связано с незанятым потоком. Это используется для оптимальной настройки некоторые размеры пакетов при альтернативной пересылке больших и малых данных. В решение использовать splice () или отправлять большие буферы в SSL модулируется этим параметр. Значение в миллисекундах от 0 до 65 535. Нулевое значение. означает, что haproxy не будет пытаться обнаружить незанятые потоки. По умолчанию 1000, который, кажется, правильно обнаруживает паузы конечного пользователя (например: прочитайте страницу перед щелкнув). Причин для изменения этого значения быть не должно. пожалуйста, проверьте tune.ssl.maxrecord ниже.
Я установил tune.idletimer = 60000 и перезапустил службу haproxy. и проблема снова возникает. Я столкнулся с проблемой в haproxy 1.8.14
старый haproxy 1.5.4 в порядке.
Для меня основная настройка, которую я должен был использовать/ изменения заключались в следующем:
timeout connect 6s
timeout client 600s
timeout server 600s
Я подозреваю, что некоторые клиенты в целях повышения производительности поддерживают соединения через сокеты с mysql -- в частности, с PHP, поэтому единственным обходным путем является позволить им поддерживать такие соединения дольше. Я обнаружил, что 600-е исчезли с ошибками и остановились на этом значении.