Я настроил балансировка нагрузки ведомых устройств MySQL с использованием HAProxy через xinetd. Два балансировщика нагрузки совместно используют виртуальный IP-адрес, которым управляет Pacemaker:
crm configure show
:
node SVR120-27148.localdomain
node SVR255-53192.localdomain
primitive failover-ip ocf:heartbeat:IPaddr2 \
params ip="192.168.5.9" cidr_netmask="32" \
op monitor interval="5s" \
meta is-managed="true"
primitive haproxy ocf:heartbeat:haproxy \
params conffile="/etc/haproxy/haproxy.cfg" \
op monitor interval="30s" \
meta is-managed="true"
colocation haproxy-with-failover-ip inf: haproxy failover-ip
order haproxy-after-failover-ip inf: failover-ip haproxy
property $id="cib-bootstrap-options" \
dc-version="1.0.12-unknown" \
cluster-infrastructure="openais" \
no-quorum-policy="ignore" \
expected-quorum-votes="2" \
stonith-enabled="false" \
last-lrm-refresh="1342783084"
/etc/haproxy/haproxy.cfg
:
global
log 127.0.0.1 local1 debug
maxconn 4096
pidfile /var/run/haproxy.pid
daemon
defaults
log global
mode tcp
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
frontend FE_mysql
bind 192.168.5.9:3307
default_backend BE_mysql
backend BE_mysql
mode tcp
balance roundrobin
option tcpka
option httpchk
#server mysql1 192.168.6.47:3306 weight 1 check port 9199 inter 12000 rise 3 fall 3
server mysql2 192.168.6.248:3306 weight 1 check port 9199 inter 12000 rise 3 fall 3
server mysql3 192.168.6.129:3306 weight 1 check port 9199 inter 12000 rise 3 fall 3
Моя проблема в том, что большую часть времени я подключаюсь через виртуальный IP, /var/log/mysqld.log
продолжает наводнять:
120719 12:59:46 [Warning] Aborted connection 17237 to db: 'db' user: 'user' host: '192.168.5.192' (Got an error
reading communication packets)
120719 12:59:49 [Warning] Aborted connection 17242 to db: 'db' user: 'user' host: '192.168.5.192' (Got an error
reading communication packets)
120719 12:59:52 [Warning] Aborted connection 17248 to db: 'db' user: 'user' host: '192.168.5.192' (Got an error
reading communication packets)
(соединение все еще установлено)
192.168.5.192
- это IP-адрес HAProxy.
mysql> show global status like 'Aborted%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Aborted_clients | 53626 |
| Aborted_connects | 400 |
+------------------+-------+
Я не думаю, что 128M недостаточно для max_allowed_packet
:
max_connections = 300
max_allowed_packet = 128M
_timeout
переменные:
mysql> show global variables like '%timeout';
+----------------------------+----------+
| Variable_name | Value |
+----------------------------+----------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_lock_wait_timeout | 60 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 3600 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| wait_timeout | 600 |
+----------------------------+----------+
Есть ли что-нибудь, что может вызвать это? Относится ли это к HAProxy?
Есть предположения?
Это причины, указанные в MySQL документы:
Значение переменной max_allowed_packet слишком мало или для запросов требуется больше памяти, чем вы выделили для mysqld. См. Раздел C.5.2.10, «Слишком большой пакет».
Использование протокола Ethernet с Linux, как полудуплексного, так и полнодуплексного. Эта ошибка есть во многих драйверах Ethernet для Linux. Вы должны проверить наличие этой ошибки, передав огромный файл по FTP между клиентской и серверной машинами. Если передача идет в режиме пакетной паузы-пакетной паузы, вы испытываете синдром дуплексного режима Linux. Переключите дуплексный режим для сетевой карты и концентратора / коммутатора на полнодуплексный или полудуплексный и проверьте результаты, чтобы определить наилучшую настройку.
Проблема с библиотекой потоков, вызывающая прерывания при чтении.
Плохо настроен TCP / IP.
Неисправные сети Ethernet, концентраторы, коммутаторы, кабели и т. Д. Правильно это можно диагностировать, только заменив оборудование.
И, этот объясняет лучше:
Хотя они могут быть симптомом более серьезной проблемы, они могут быть вызваны обычными (то есть непредотвратимыми) проблемами сети.
Даже если они находятся в одной локальной сети, по разным причинам могут возникнуть ошибки связи между вашим сервером приложений и базой данных. В случаях нарушения связи или тайм-аутов приложения и / или MySQL, скорее всего, будут повторять попытки и работают, и проблема никогда не проявляется и не проявляется.
По моему опыту, наиболее распространенными источниками этих типов сообщений являются сбой приложения (сервера), неправильное завершение соединения приложением или задержки при репликации за пределами площадки.
Вполне вероятно, что они происходили до того, как вы включили регистрацию ошибок на сервере MySQL.
проверить haproxy mannul
tune.idletimer
Устанавливает продолжительность, по истечении которой haproxy будет считать, что пустой буфер, вероятно, связан с незанятым потоком. Это используется для оптимальной настройки некоторых размеров пакетов при альтернативной пересылке больших и малых данных. Этот параметр модулирует решение использовать splice () или отправлять большие буферы в SSL. Значение находится в миллисекундах от 0 до 65535. Нулевое значение означает, что haproxy не будет пытаться обнаруживать незанятые потоки. Значение по умолчанию - 1000, что, кажется, правильно определяет паузы конечного пользователя (например: прочтите страницу перед щелчком). Причин для изменения этого значения быть не должно. Пожалуйста, проверьте tune.ssl.maxrecord ниже.
Я установил tune.idletimer=60000
и перезапустите службу haproxy. и проблема снова возникает. Встречаю проблему в haproxy 1.8.14
старый haproxy 1.5.4 в порядке.
Я обнаружил, что увеличение настроек тайм-аута в файле haproxy.cfg решило эту ошибку для меня. Я потратил много времени на проверку my.cnf wait_timeout и т. Д. И понял, что узким местом на самом деле является HAProxy.