HAproxy状态显示为DOWN

Question

我已经建立了MariaDB Galera集群，测试后发现在以下服务器上都可以正常工作：

• db1 192.169.0.1
• db2 192.169.0.2
• db3 192.169.0.3

它们全部运行在CentOS-6.5系统上，使用的MariaDB版本是10.0。

我的目标是使用HAproxy进行负载均衡。我已经在一个单独的服务器上安装并配置了HAproxy。

db4 192.168.0.4 

在没有集群设置或安装MariaDB的情况下，只有HAproxy。问题是，HAproxy似乎不起作用，即不能进行负载均衡。它可以正常启动，我可以通过Web界面访问：

http://192.168.0.4:9000/haproxy

但是服务器的状态显示它们已经宕机，即使它们实际上正在各自的机器上运行。HAproxy配置如下：

global
log 127.0.0.1 local0 notice
user haproxy
group haproxy

defaults
log global
retries 2
timeout connect 1000
timeout server 5000
timeout client 5000

listen mariadb-cluster
bind 0.0.0.0:3306
mode tcp
option mysql-check user haproxy
balance roundrobin
server db1 192.168.0.1:3306 check
server db2 192.168.0.2:3306 check
server db4 192.168.0.3:3306 check

listen webinterface
bind 0.0.0.0:9000
mode http
stats enable
stats uri /haproxy
stats realm Strictly\ Private
stats auth admin:password

db1、db2、db3和db4只是每个服务器的主机名。当我在第一个服务器上运行命令#hostname时，它会显示db1。

- The Georgia

---

你在haproxy服务器上打开了3306端口吗？ - zypro

Answer 1

我相信你已经查看了日志，可以看到连接进入并且被重定向到节点/服务器，或者没有被正确地重定向。

我不知道这是否是打字错误，但我认为您已将db4（haproxy机器）作为一个节点包含在内，对吧？它应该是db3）

还要检查您是否可以从HAproxy机器访问每个数据库节点的3306端口。

如果不能，请检查您为检查过程定义的haproxy用户是否具有mysql权限。如果没有，请登录到其中一个节点服务器，并执行以下操作：

mysql> GRANT USAGE ON *.* TO 'haproxy'@'%'; 

(出于安全考虑，应将“%”限制在HAproxy运行的IP地址范围内)

我有一个与您类似的配置，但添加了节点权重和每个节点的最大连接数选项。我还更喜欢使用“leastcon”而不是“round robin”，因此请评估它是否适合您的目的。

haproxy.cfg

global
    log         127.0.0.1 local0
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     512
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats mode 666

defaults
        log     global
        mode    http
        option  tcplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 1024
        timeout connect     3s
        timeout client      50s
        timeout server      50s
        timeout check       10s

listen website_cluster 0.0.0.0:3306
        mode tcp
        balance leastconn
        option tcpka
        option httpchk
        option mysql-check user haproxy
        stick store-request src
        stick-table type ip size 200k expire 30m
        server db1 192.168.0.1:3306 weight 40 check port 3306 inter 5000 rise 1 fall 3 maxconn 120
        server db2 192.168.0.2:3306 weight 30 check port 3306 inter 5000 rise 1 fall 3 maxconn 75
        server db3 192.168.0.3:3306 weight 30 check port 3306 inter 5000 rise 1 fall 3 maxconn 75

在MariaDB的网站上还有一个教程，可能也会帮助你: 这里。

- bigux

Answer 2

我也遇到了这个问题，花了将近一天的时间才发现HAPROXY有两种后端负载均衡/健康检查模式。第四层检查在OSI第四层运行，而第七层在应用程序级别上运行。我当时使用的是option mysql-check，它在第七层进行检查，并需要在HAPROXY服务器/节点上安装mysql-client。但是我在HAPROXY机器/容器（docker）上没有安装任何Mysql-client软件包。然后我将选项检查转换为option tcp-check，就可以正常工作了。下面是我完整的haproxy.cfg代码。

global
    log haproxy-logger local0 notice
    fuser haproxy
    group haproxy
    defaults
log global
    retries 2
    timeout connect 3000
    timeout server 5000
    timeout client 5000
listen mysql-cluster
    bind 0.0.0.0:3306
    mode tcp
    #option mysql-check user haproxy_check
    option tcp-check
    balance roundrobin
    server mysql1 mysql1:3306 check
    server mysql2 mysql2:3306 check weight 2
listen mysql-clusterstats
    bind 0.0.0.0:8080
    mode http
    stats enable
    stats uri /
    stats realm Strictly\ Private
    stats auth status:mypass

最终通过将其转换为第四层负载平衡来修复

更多详细信息请参见我的博客 - Docker上的HAProxy - Mysql集群

- Avinash Barnwal

---

我也遇到了完全相同的问题，将mysql-check更改为tcp-check确实解决了问题。但是我的配置与你的有些不同，我的haproxy运行在与mariadb服务器相同的节点上，其中还安装了mysql客户端......所以对我来说原因仍然不清楚。顺便说一下，经过测试，如果我根本不启用检查，问题也会消失（尽管在生产中禁用健康检查并不是一个好主意）。 - bruin

进行了更多的测试。对于使用mysql-check，我的问题是我没有为haproxy_check帐户设置空密码。设置密码后，mysql-check也可以正常工作。值得注意的是，我还遇到了另一个关于mysql.user表复制的问题，即当我从一个节点创建haproxy_check帐户时，它不会自动复制到其他节点。结果证明，我需要使用不同的SQL语句来完成这个操作，或者至少验证所有节点上的帐户信息是否相同。经过测试，以下两个命令是“可复制的”： - bruin

1. 创建用户：CREATE USER haproxy_check@'10.0.0.%';
2. 授予权限：GRANT USAGE ON . TO 'haproxy_check'@'10.0.0.%' IDENTIFIED BY '' WITH GRANT OPTION; FLUSH PRIVILEGES; 顺便提一下，我正在使用CentOS 7.2上的MariaDB v10.1.19和HAProxy v1.5.14。

- bruin

Answer 3

在我的情况下，是SELinux阻止了连接。

- Mawardy