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

Я настроил балансировку нагрузки MySQL-ведомых, используя HAProxy через xinetd. 2 балансировщика нагрузки совместно используют виртуальный 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?

Какие-нибудь мысли?

Источник

3 ответа

Вот причины, приведенные в документации по MySQL:

Значение переменной 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.

Источник

Для меня основной настройкой, которую мне пришлось использовать / изменить, было:

timeout connect 6s
timeout client  600s
timeout server  600s

Я подозреваю, что некоторые клиенты в целях повышения производительности поддерживают соединения сокетов с mysql - в частности, PHP, поэтому единственный обходной путь - позволить им поддерживать такие соединения дольше. Я обнаружил, что 600-е исчезли ошибки и остановились на этом значении.

Источник

Проверьте 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 в порядке.

Источник
Другие вопросы по тегам