Назад | Перейти на главную страницу

Балансировка нагрузки MySQL с использованием HAProxy: есть ошибка чтения коммуникационных пакетов?

Я настроил балансировка нагрузки ведомых устройств 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.