web-dev-qa-db-ja.com

HAProxyを使用したMySQLの負荷分散：通信パケットの読み取り中にエラーが発生しましたか？

xinetdを介してHAProxyを使用してMySQLスレーブの負荷を分散する を設定しました。 2つのロードバランサーがPacemakerによって管理される仮想IPを共有しました：

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はHAProxyのIPアドレスです。

mysql> show global status like 'Aborted%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 53626 |
| Aborted_connects | 400   |
+------------------+-------+

max_allowed_packetには128Mでは不十分だと思います。

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と関係がありますか？

何かご意見は？

mysqlload-balancinghaproxyconnection
7
quanta

これらはMySQLで与えられた理由です docs ：

Max_allowed_pa​​cket変数の値が小さすぎるか、クエリにmysqldに割り当てたよりも多くのメモリが必要です。セクションC.5.2.10「パケットが大きすぎる」を参照してください。

Linuxでのイーサネットプロトコルの使用、半二重と全二重の両方。多くのLinuxイーサネットドライバにこのバグがあります。クライアントマシンとサーバーマシン間でFTPを使用して巨大なファイルを転送することにより、このバグをテストする必要があります。転送がburst-pause-burst-pauseモードになる場合は、Linuxデュプレックスシンドロームが発生しています。ネットワークカードとハブ/スイッチの両方のデュプレックスモードを全二重または半二重に切り替え、結果をテストして最適な設定を決定します。

読み取り時に割り込みが発生するスレッドライブラリの問題。

正しく構成されていないTCP/IP。

障害のあるイーサネット、ハブ、スイッチ、ケーブルなど。これは、ハードウェアを交換することによってのみ適切に診断できます。

そして this はよりよく説明します：

これらはより大きな問題の症状である可能性がありますが、通常の（つまり、回避できない）ネットワークの問題が原因である可能性があります。

同じLAN上にある場合でも、さまざまな理由で、アプリケーションサーバーとデータベース間で通信エラーが発生する可能性があります。通信が破損したりタイムアウトしたりした場合、アプリケーションやMySQLは再試行して機能する可能性が高く、問題が表面化することも、明らかになることもありません。

私の経験では、これらのタイプのメッセージの最も一般的なソースは、アプリケーション（サーバー）のフレーキング、アプリケーションが接続を適切に終了していないこと、またはオフサイトレプリケーションの遅延からです。

MySQLサーバーでエラーロギングを有効にする前に発生していた可能性があります。

2
Jacob

Haproxy.cfgファイルのタイムアウト設定を増やすと、このエラーが解決することがわかりました。 my.cnfのwait_timeoutなどを確認するのに多くの時間を費やし、ボトルネックが実際にはHAProxyであることに気付きました。

0
Jonathan Nathanson

haproxymannulを確認してください

tune.idletimer

空のバッファがおそらくアイドルストリームに関連付けられているとhaproxyが見なすまでの期間を設定します。これは、大小のデータを交互に転送しながら、一部のパケットサイズを最適に調整するために使用されます。 splice（）を使用するか、SSLで大きなバッファーを送信するかの決定は、このパラメーターによって調整されます。値は0〜65535のミリ秒単位です。値がゼロの場合、haproxyはアイドル状態のストリームを検出しようとしません。デフォルトは1000で、エンドユーザーの一時停止を正しく検出するようです（例：クリックする前にページを読む）。この値を変更する理由はないはずです。以下のtune.ssl.maxrecordを確認してください。

tune.idletimer=60000を設定し、haproxyサービスを再起動します。そして問題は再び起こります。 haproxy1.8.14で問題を解決します

古いhaproxy1.5.4は問題ありません。

0
zhouqiang