记录日常工作关于系统运维,虚拟化云计算,数据库,网络安全等各方面问题。

使用 HAProxy 进行 MySQL 负载平衡


应用程序通常通过在其中一个数据库节点上打开连接来连接到数据库集群或复制的设置,以便运行事务。如果数据库节点发生故障,客户端将需要重新连接到另一个数据库节点,然后才能继续为请求提供服务。

有不同的方法可以提供与一个或多个 MySQL 数据库服务器的连接。一种方法是使用支持连接池、负载平衡和故障转移的数据库驱动程序,例如:

上述数据库驱动程序旨在为客户端在连接到独立MySQL服务器,MySQL群集(NDB)MySQL复制设置时提供透明度。但是,在其他集群设置中,如 Galera Cluster for MySQL 或 MariaDB,JDBC 和 PHP 驱动程序不知道内部 Galera 状态信息。例如,Galera 捐赠节点在帮助另一个节点重新同步时可能处于只读状态(如果 SST 方法是 mysqldump 或 rsync),或者如果发生裂脑,它可能处于非主要状态。另一种解决方案是在客户端和数据库集群之间使用负载均衡器。

本教程将引导您了解如何使用 ClusterControl 使用 HAProxy 部署、配置和管理 MySQL 负载平衡。

白皮书的内容

  • 什么是HAProxy?
  • MySQL 的运行状况检查
  • 故障检测和故障转移
  • 使用HAProxy进行读/写分离
  • 与集群控制集成
  • HAProxy 冗余与 Keepalive
  • HAProxy 统计
  • 故障排除和解决方法

什么是HAProxy?

HAProxy代表高可用性代理,是一个伟大的基于软件的TCP / HTTP负载均衡器。它将工作负载分布在一组服务器之间,以最大限度地提高性能并优化资源使用。HAProxy 采用复杂且可定制的运行状况检查方法构建,允许在单个正在运行的实例中对多个服务进行负载均衡。

依赖于数据库后端的前端应用程序很容易使数据库过度饱和,并发运行的连接过多。HAProxy提供与一个或多个MySQL服务器的连接排队和限制,并防止单个服务器因过多的请求而过载。所有客户端都连接到 HAProxy 实例,反向代理根据所使用的负载平衡算法将连接转发到可用的 MySQL 服务器之一。

一种可能的设置是在每个 Web 服务器(或在数据库上发出请求的应用程序服务器)上安装 HAProxy。如果只有几个 Web 服务器,则此方法可以正常工作,因此可以检查运行状况检查引入的负载。Web服务器将连接到本地HAProxy(例如,在127.0.0.1:3306上建立mysql连接),并且可以访问所有数据库服务器。Web 和 HAProxy 共同构成了一个工作单元,因此如果 HAProxy 不可用,Web 服务器将无法工作。

在负载均衡器层中使用 HAProxy,您将具有以下优势:

  • 所有应用程序都通过一个 IP 地址或主机名访问群集。数据库集群的拓扑在 HAProxy 后面屏蔽。
  • MySQL 连接在可用数据库节点之间进行负载均衡。
  • 可以在不对应用程序进行任何更改的情况下添加或删除数据库节点。
  • 一旦达到最大数据库连接数(在MySQL中),HAProxy就会对其他新连接进行排队。这是限制数据库连接请求并实现过载保护的巧妙方法。

ClusterControl 直接从 UI 支持 HAProxy 部署,默认情况下它支持三种负载平衡算法 - 轮询、最小连接或源。我们建议用户在客户端和数据库服务器池之间使用 HAProxy,特别是对于后端被平等对待的 Galera 集群或 MySQL 集群。

MySQL 的运行状况检查

可以通过连接到MySQL端口(通常是3306)来让HAProxy检查服务器是否已启动,但这还不够好。实例可能已启动,但底层存储引擎可能无法正常工作。需要通过特定的检查,具体取决于集群类型是 Galera、MySQL 复制还是 MySQL 集群。

健康检查脚本

执行MySQL运行状况检查的最佳方法是使用自定义shell脚本,该脚本通过仔细检查MySQL服务器的内部状态来确定MySQL服务器是否可用,这取决于所使用的集群解决方案。默认情况下,ClusterControl 提供自己的健康检查脚本版本,称为 mysqlchk,驻留在负载平衡集中的每个 MySQL 服务器上,并能够返回 HTTP 响应状态和/或标准输出 (stdout),这对于 TCP 健康检查很有用。

mysqlchk for Galera Cluster

如果后端 MySQL 服务器运行正常,则脚本将返回退出状态为 0 的简单 HTTP 200 OK 状态代码。否则,脚本将返回 503 服务不可用和退出状态 1。使用 xinetd 是执行运行状况检查脚本的最简单方法,方法是使该脚本守护并侦听自定义端口(默认值为 9200)。然后,HAProxy 将连接到此端口并请求运行状况检查输出。如果运行状况检查方法是 httpchk,HAProxy 将查找 HTTP 响应代码,如果该方法是 tcp-check,它将查找期望字符串(如第 3.2.3 节所示)。

以程图说明了报告多主站设置的 Galera 节点运行状况的过程:

模板文件位于 ClusterControl 服务器上的 /usr/share/cmon/templates/mysqlchk.galera 中。这个 mysqlchk 脚本由 ClusterControl 自动安装在参与负载均衡集的每个 Galera 节点上。

mysqlchk for MySQL Replication

此脚本基于标准 mysqlchk 脚本,但专为正确监控 MySQL 复制后端服务器而量身定制。该模板在此 Github 存储库中可用,您可以通过在 HAProxy 部署开始之前替换位于 /usr/share/cmon/templates/mysqlchk.mysql 的默认模板来使用它。这与 Galera 集群的 mysqlchk 类似,其中需要 xinetd 来守护健康检查脚本。

该脚本根据以程图检测 MySQL 复制角色:

为 MySQL 复制设置 HAProxy 需要两个不同的 HAProxy 侦听器,例如,端口 3307 用于写入主站,端口 3308 用于读取所有可用的从站(包括主站)。我们在这篇博文中对此进行了介绍。

mysqlchk-iptables for Galera Cluster

一个后台脚本,用于检查 Galera 节点的可用性,并在 Galera 节点运行正常时使用 iptables 添加重定向端口(而不是返回 HTTP 响应)。这允许其他运行状况检查功能有限的 TCP 负载均衡器正确监控后端 Galera 节点。

除了 HAProxy 之外,您现在可以使用您最喜欢的反向代理在 Galera 节点之间对请求进行负载均衡,即:

  • nginx 1.9 (–with-stream)
  • 保持活力
  • IPVS
  • 分配器
  • 平衡

此运行状况检查脚本超出了本教程的范围,因为它是为 TCP 负载均衡器(HAProxy 除外)构建的,这些 TCP 负载均衡器具有有限的运行状况检查功能,可以正确监控后端 Galera 节点。您可以在以下截屏视频中观看它的实际效果:

这在这篇博文nginx作为MySQL Galera Cluster的数据库负载均衡器中详细介绍。

健康检查方法

HAProxy 通过执行所谓的运行状况检查来确定服务器是否可用于请求路由。HAProxy通过以下选项支持多种可用于MySQL的后端健康检查方法:

  • Mysql-check
  • TCP 检查
  • 维基奇克

Mysql-check

检查包括发送两个 MySQL 数据包、一个客户端身份验证数据包和一个 QUIT 数据包,以正确关闭 MySQL 会话。然后,HAProxy解析MySQL握手初始化数据包和/或错误数据包。这是一个基本但有用的测试,不会在服务器上产生错误或中止连接。但是,它需要在 MySQL 表中添加授权,如下所示:

USE mysql;
INSERT INTO user (Host,User) values ('<ip_of_haproxy>','<username>');
FLUSH PRIVILEGES;

请注意,这不会检查数据库是否存在或数据库一致性。为此,我们必须使用外部检查(通过 xinetd),这将在下一节中解释。

TCP 检查

默认情况下,如果设置了“check”,则当服务器能够接受定期 TCP 连接时,将被视为可用。这对于数据库后端来说不够可靠,因为数据库服务器可能能够在处于非操作状态时响应连接请求。实例可能已启动,但底层存储引擎可能无法正常工作。此外,还需要执行特定的检查,具体取决于集群类型是Galera还是MySQL集群(NDB)。

ClusterControl 提供的 mysqlchk 脚本支持返回 HTTP 状态码和标准输出(stdout)。通过使用 xinetd 中的 stdout,我们可以扩展 tcp-check 功能,使其在 Galera 或 MySQL 复制节点状态下更加准确。以下示例配置显示了它的可用性:

listen  haproxy_192.168.55.110_3307
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option tcp-check
        tcp-check expect string is\ running.
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check
        server galera3 192.168.55.113:3306 check

上面的配置行告诉 HAProxy 使用 TCP 发送/期望序列执行运行状况检查。它连接到数据库的端口 9200,并期望包含“is\ running”的字符串(反斜杠用于转义空格)。要验证通过 xinetd 端口 9200 的 mysqlchk 输出,请对 HAProxy 节点上的数据库节点执行远程登录:

$ telnet 192.168.55.111 9200
Trying 192.168.55.171...
Connected to 192.168.55.171.
Escape character is '^]'.
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 43
 
<html><body>MySQL is running.</body></html>
 
Connection closed by foreign host.

您可以对 MySQL 复制使用类似的配置,其中 master 的预期字符串是“MySQL Master 正在运行”。有关 HAProxy 作为 MySQL 复制负载均衡器的示例部署的更多详细信息,请阅读此博客

群集控制默认使用 httpchk,如下一节所述。

维基奇克

选项 httpchk 使用 HTTP 协议来检查服务器的运行状况。如果要对 HTTP 服务进行负载平衡,这很常见,其中 HAProxy 确保后端在路由传入连接之前返回特定的 HTTP 响应代码。此选项不一定需要 HTTP 后端,它也适用于普通 TCP 后端。尽可能使用 httpchk 是首选选项,因为它通过无状态 HTTP 连接使用更少的资源。

listen  haproxy_192.168.55.110_3307
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option httpchk
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check
        server galera3 192.168.55.113:3306 check

上面的例子告诉我们,HAProxy 将连接到端口 9200,xinetd 正在那里监听数据库服务器。HAProxy 将查找预期的 HTTP 响应代码。如果服务器运行正常,mysqlchk 脚本将返回“HTTP 200 OK”或“HTTP 503 服务不可用”。

故障检测和故障转移

当数据库节点发生故障时,在该节点上打开的数据库连接也将失败。重要的是,HAProxy 不会将新的连接请求重定向到故障节点。

有几个用户定义的参数决定了 HAProxy 检测服务器不可用的速度。以下是位于 /etc/haproxy/haproxy.cfg 的 ClusterControl 部署的示例 HAProxy 配置:

listen  haproxy_192.168.55.110_3307
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option httpchk
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check
        server galera3 192.168.55.113:3306 check

以上每行的快速说明:

  • 听:侦听部分定义了一个完整的代理,其前端和后端部分组合在一个部分中。它通常对于仅 TCP 流量很有用。在其旁边指定 HA 代理实例名称。描述该节的下一行必须缩进。
  • 捆:绑定到此主机上端口 3307 上的所有 IP 地址。客户端必须连接到此行中定义的端口。
  • 模式:实例的协议。对于 MySQL,实例应在纯 TCP 模式下工作。将在客户端和服务器之间建立全双工连接,并且不会执行第 7 层检查。
  • timeout 客户端:客户端的最大非活动时间。建议与超时服务器保持相同的值以实现可预测性。
  • 超时服务器:服务器端的最大非活动时间。建议与超时客户端保持相同的值以实现可预测性。
  • 平衡:负载平衡算法。ClusterControl 能够部署 minimumconn、roundrobin 和 source,但您可以在稍后阶段自定义配置。首选使用 minimumconn 选项,以便连接数最少的数据库服务器接收连接。如果数据库服务器的连接数相同,则执行轮循机制以确保使用所有服务器。
  • 选项 httpchk:改为执行基于 HTTP 的运行状况检查。群集控制在负载平衡集中的每个后端服务器上配置一个 xinetd 脚本,该脚本返回 HTTP 响应代码。
  • 选项全部备份:当所有正常备份服务器不可用时,将在所有备份服务器之间执行负载平衡。如果将MySQL服务器配置为备份,则此选项适用,如本教程的故障排除和解决方法部分所述。
  • 默认服务器:服务器选项下列出的后端服务器的默认选项。
  • 港口:后端运行状况检查端口。ClusterControl 配置一个 xinetd 进程,侦听运行自定义运行状况检查脚本的每个数据库节点上的端口 9200。
  • 国米:对于处于“启动”状态、过渡性“启动或关闭”或尚未检查的服务器,运行状况检查之间的间隔为 2 秒。
  • 下层:当服务器 100% 关闭或无法访问时,关闭间隔为 5 秒。
  • 上升:连续 3 次成功运行状况检查后,服务器将被视为可用。
  • 秋天:连续 2 次运行状况检查失败后,服务器将被视为关闭/不可用。
  • 慢启动:在 60 秒内,服务器接受的连接数将在重新联机后从通常动态限制的 1% 增长到 100%。
  • 麦克斯康:当连接数为 64 时,HAProxy 将停止接受连接。
  • 最大队列:将在队列中等待此服务器的最大连接数。如果达到此限制,下一个请求将重新调度到其他服务器,而不是无限期地等待服务。
  • 重量:在加莱拉,所有节点通常一视同仁。因此,将其设置为 100 是一个好的开始。
  • 服务器:定义后端服务器名称、IP 地址、端口和服务器选项。我们通过在每个服务器上使用检查选项启用了运行状况检查。其余选项与默认服务器相同。

从上述配置来看,后端 MySQL 服务器在以下情况下运行状况检查失败:

  • HAProxy 无法连接到 MySQL 服务器的端口 9200
  • 如果连接了 9200,MySQL 服务器发送的 HTTP 响应代码返回 HTTP/1.1 200 OK 以外的代码(选项 httpchk)

因此,停机时间和正常运行时间年表为:

  1. HAProxy 每隔 2 秒对后端服务器的 9200 端口(2 间 9200 端口)进行一次健康检查。
  2. 如果运行状况检查失败,则开始下降计数,并将检查下一次失败。5秒后,如果第二次尝试仍然失败,HAProxy会将MySQL服务器标记为关闭(向下5秒下降2)。
  3. MySQL 服务器会自动从可用服务器列表中排除。
  4. MySQL服务器重新联机后,如果运行状况检查成功,则上升计数将开始,它将检查下一次连续尝试是否成功。如果计数达到 3,服务器将被标记为可用(上升 3)。
  5. MySQL服务器会自动包含在可用服务器列表中。
  6. MySQL服务器开始逐渐接受连接60秒(慢启动60秒)。
  7. MySQL服务器已启动并完全运行。

使用HAProxy进行读/写分离

HAProxy作为MySQL负载均衡器的工作方式类似于TCP转发器,后者在TCP / IP模型的传输层中运行。它不理解它分发到后端MySQL服务器的MySQL查询(在较高层运行)。因此,HAProxy在Galera Cluster和MySQL Cluster等多主复制设置中很受欢迎,其中所有后端MySQL服务器都得到平等对待。所有MySQL服务器都能够处理转发的读/写。与数据库感知负载均衡器/反向代理(如 MaxScale 或 ProxySQL)相比,在传输层中操作消耗的开销也更少。

尽管如此,这并不意味着HAProxy不适用于其他非多主设置,尤其是主从复制。在MySQL复制中,事情变得有点复杂。写入必须仅转发给主站,而读操作可以转发给所有从站(或主站),只要从站不落后。在复制设置中更新多个主节点可能会导致数据不一致并导致复制中断

要使 HAProxy 能够分别处理读取和写入,必须:

  • 为 MySQL 复制配置运行状况检查。运行状况检查脚本必须能够:
    • 报告复制角色(主角色、从角色或无复制角色)
    • 报告从站滞后(如果从属)
    • 必须可通过 HAProxy 访问(通过 xinetd 或转发端口配置)
  • 创建两个 HAProxy 侦听器,一个用于读取,一个用于写入:
    • 读取侦听器 – 转发给所有从站(或主站)以处理读取。
    • 写入侦听器 – 将写入转发到单个主服务器。
  • 指示应用程序将读/写发送到相应的侦听器:
    • 构建/修改应用程序,以便能够向相应的侦听器发送读取和写入
    • 使用支持内置读写分离的应用程序连接器。如果你使用的是Java,你可以使用Connecter/J。对于 PHP,您可以使用 php-mysqlnd 作为主从。这将最大限度地减少应用程序端的更改。

我们已经在这篇博文中详细介绍了PHP案例,使用php-mysqlnd,MySQL复制和HAProxy进行高可用性读写分离

与集群控制集成

ClusterControl与HAProxy集成,结合Galera或MySQL NDB Cluster等集群MySQL后端,简化负载均衡器的部署和管理。还可以将现有/已部署的 HAProxy 实例添加到 ClusterControl 中,以便您可以直接从 ClusterControl UI 和数据库节点对其进行监控和管理。

要进行安装,您只需转到“群集控制”>“管理>负载均衡器”>“安装 HAProxy”选项卡,然后输入所需信息:

  • HAProxy 地址:HAProxy 节点的 IP 地址或主机名。群集控制必须能够通过无密码 SSH 进行连接。
  • 侦听端口:HAProxy 实例将侦听的端口。此端口将用于连接到负载平衡的 MySQL 连接。
  • 策略:负载平衡算法。支持的值包括:
    • 最少连接 – 连接数最少的服务器接收连接。
    • 循环 – 每个服务器根据其权重轮流使用。
    • source – 客户端 IP 地址经过哈希处理并除以总权重,因此只要没有服务器关闭或启动,它就会始终到达同一服务器。
  • 从包管理器安装:如果基于 Redhat,请通过 yum 包管理器安装。对于基于 Debian 的,将使用 apt-get 命令。
  • 从源代码构建(将使用最新的可用源代码包:
    • 群集控制将编译从 http://www.haproxy.org/#down 下载的最新可用源包。
    • 仅当您打算使用最新版本的 HAProxy 或操作系统发行版的包管理器出现问题时,才需要此选项。一些较旧的操作系统版本在其软件包存储库中没有 HAProxy。
  • 覆盖目标上现有的 /usr/local/sbin/mysqlchk:如果 mysqlchk 脚本已经存在,请覆盖此部署的脚本。如果您已根据需要调整脚本,则可能需要取消选中此选项。
  • 显示高级设置:
    • 统计套接字:各种统计输出的 UNIX 套接字文件位置。默认值为 /var/run/haproxy.socket,建议不要更改此设置。
    • 管理端口:HAProxy 管理员级别统计信息页面的端口。默认值为 9600。
    • 管理员用户:连接到统计信息页面时的管理员用户。
    • 管理员密码:管理员用户的密码
    • 后端名称:后端的侦听器名称。没有空格。
    • 超时服务器(秒):服务器端的最大非活动时间。
    • 超时客户端(秒):客户端的最大非活动时间。
    • 前端最大连接数:前端每个进程的最大并发连接数。
    • 每个实例的最大连接后端数:限制从HAProxy到每个MySQL服务器可以建立的连接数。超过此值的连接将由 HAProxy 排队。最佳做法是将其设置为小于 MySQL 的max_connections,以防止连接泛洪。
    • xinetd 允许来自:仅允许此网络通过 xinetd 服务连接到 MySQL 服务器上的健康检查脚本。
  • 服务器实例:集群中的 MySQL 服务器列表。
  • 包括:将服务器包含在负载平衡集中。
  • 角色:选择节点是活动节点还是备份节点。在备份模式下,仅当所有其他活动服务器不可用时,服务器才会用于负载平衡。

对话框填满后,单击“安装 HAProxy”按钮以触发部署作业:

触发部署作业时,群集控制将执行以下任务:

  1. 安装帮助程序包
  2. 调整实例的 TCP 堆栈
  3. 在每个 Galera 节点上复制和配置 mysqlchk 脚本(从模板)
  4. 在 /etc/xinetd.d/mysqlchk 安装和配置 xinetd
  5. 将 HAProxy 节点注册到 ClusterControl 中

可以在“群集控制”下监视部署进度 > 日志>作业,类似于以下示例:

默认情况下,HAProxy 服务器将在端口 3307 上侦听连接。在此示例中,HAProxy 主机 IP 地址为 192.168.55.170。您可以将应用程序连接到 192.168.55.170:3307,请求将在后端 MySQL 服务器上进行负载均衡。

不要忘记授予从HAProxy服务器到MySQL服务器的访问权限,因为MySQL服务器将看到HAProxy建立连接,而不是应用程序服务器本身。在上面的示例中,在MySQL服务器上发出您想要的访问权限:

mysql> GRANT ALL PRIVILEGES ON mydb.* TO 'appuser'@'192.168.55.170' IDENTIFIED BY 'password';

HAProxy进程将由ClusterControl管理,如果失败,它会自动重新启动。

HAProxy Redundancy with Keepalive

由于所有应用程序都将依赖于HAProxy连接到可用的数据库节点,因此为了避免HAProxy的单点故障,可以设置两个相同的HAProxy实例(一个活动实例和一个备用实例),并使用Keepalive在它们之间运行VRRP。VRRP 为活动 HAProxy 提供虚拟 IP 地址,并在发生故障时将虚拟 IP 传输到备用 HAProxy。这是无缝的,因为两个 HAProxy 实例不需要共享状态。

通过将 Keepalive 添加到图片中,我们的基础设施现在将如下所示:

在此示例中,我们使用两个节点充当负载均衡器,并在数据库集群前面进行 IP 地址故障转移。虚拟 IP (VIP) 地址将在 HAProxy #1(主)和 HAProxy #2(备份)之间浮动。当 HAProxy #1 关闭时,VIP 将由 HAProxy #2 接管,一旦 HAProxy #1 再次启动,VIP 将故障回复到 HAProxy #1,因为它持有更高的优先级号码。故障转移和故障恢复过程是自动的,由 Keepalived 控制。

您需要至少有两个 HAProxy 实例才能安装 Keepalived。使用“安装 HAProxy”安装另一个 HAProxy 实例,然后转到群集控制>管理>负载均衡器>安装保持生存以安装或添加现有的保持生存实例,如以下屏幕截图所示:

请注意,您的网络环境支持 VRRP(IP 协议 112)用于两个节点之间的运行状况检查通信。还可以通过配置单播让 Keepalive 在非多播环境中运行,如果安装的 Keepalive 是版本 1.2.8 及更高版本,则默认情况下,群集控制将使用单播。

有关 ClusterControl 如何配置 Keepalive 以及故障转移和故障回复预期结果的更多详细信息,请参阅此博客文章

HAProxy Statistics

除了部署和管理之外,ClusterControl 还提供了从 UI 中对 HAProxy 统计信息的洞察。从 ClusterControl 中,您可以访问 ClusterControl > 节点的统计信息页面>选择 HAProxy 节点,类似于下面的屏幕截图:

您可以通过勾选/取消选中“已启用”列下的复选框按钮,从负载平衡中启用/禁用服务器。当您希望应用程序有意跳过连接到服务器时,例如,为了维护或测试和验证新的配置参数或优化的查询,这非常有用。

还可以通过连接到 HAProxy 节点上的端口 9600 来访问默认的 HAProxy 统计信息页面。以下屏幕截图显示了使用默认用户名和密码“admin”连接到 http://[HAProxy_node_IP_address]:9600/时的示例:

根据表图例,绿色行表示服务器可用,而红色行表示向下。当服务器可用时,您应该注意到“slowstart 60s”启动的限制部分(最后一列)。此服务器将接收逐步连接,其中权重在达到预期权重(权重 100)之前动态调整 60 秒:

故障排除和解决方法

本节提供了一些关于使用 HAProxy、Keepalive 和 ClusterControl 配置 MySQL 时常见问题的指导。

Galera 中的 MySQL 死锁

Galera 集群具有已知的局限性,其中之一是它使用集群范围的乐观锁定。这可能会导致某些事务回滚。随着可写主节点数量的增加,事务回滚速率可能会增加,尤其是在同一数据集上存在写入争用时。当然,可以重试事务,也许它会在重试中提交,但这会增加事务延迟。但是,有些设计容易死锁,例如序列表。

解决方案是为单节点读/写创建另一个侦听器,并告知应用程序将有问题的查询发送到相应的侦听器。以下示例显示了端口 3307 上的多节点读取/写入和端口 3308 上的单节点读取/写入的 HAProxy 侦听器片段:

listen  haproxy_192.168.55.110_3307_multi
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option httpchk
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check
        server galera3 192.168.55.113:3306 check
 
listen  haproxy_192.168.55.110_3308_single
        bind *:3308
        mode tcp
        timeout client  10800s
        timeout server  10800s
        balance leastconn
        option httpchk
        option allbackups
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server galera1 192.168.55.111:3306 check
        server galera2 192.168.55.112:3306 check backup
        server galera3 192.168.55.113:3306 check backup

我们已经在这篇博文《避免 Glera 中的死锁》中详细介绍了这一点。

MySQL 服务器已消失

这通常是当 HAProxy 由于超时而关闭连接或在服务器端关闭连接时引起的。有时,当服务器重新启动或连接达到以下超时之一时,您可能会看到这种情况(以下默认值适用于 ClusterControl 部署的 MySQL 变量):

  • connect_timeout – 默认值为 10s
  • deadlock_timeout_long – 默认值为 50000000s
  • deadlock_timeout_short – 默认值为 10000s
  • delayed_insert_timeout – 默认值为 300s
  • innodb_lock_wait_timeout – 默认值为 50s
  • interactive_timeout – 默认值为 28800s
  • lock_wait_timeout – 默认值为 31536000s
  • net_read_timeout – 默认值为 30s
  • net_write_timeout – 默认值为 60s
  • slave_net_timeout – 默认值为 3600s
  • thread_pool_idle_timeout – 默认值为 60s
  • wait_timeout – 28800s

我们建议使用与 HAProxy 配置文件中的超时客户端和超时服务器相同的值配置net_read_timeout和net_write_timeout值。

非统一硬件

如果硬件不统一,则为每个服务器设置权重可能有助于平衡服务器的负载。所有服务器都将收到与其权重相对于所有权重之和成比例的负载,因此权重越高,负载就越高。建议从可以增长和缩小的值开始,例如在 10 到 100 之间,以便在上方和下方留出足够的空间以供以后调整。

Galera 复制性能由群集中最慢的节点决定。假设在三节点群集中,引入第三个节点的容量是其他两个节点的一半。将特定服务器的权重减少一半是一种很好的做法,这样它就可以获得相当数量的连接,并且不会拖累其他成员以满负荷运行:

...
default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
server galera1 192.168.55.111:3306 check
server galera2 192.168.55.112:3306 check
server galera3 192.168.55.113:3306 check weight 50

其他资源

您可能还想查看以下 2 个网络研讨会重播:



转载请标明出处【使用 HAProxy 进行 MySQL 负载平衡】。

《www.micoder.cc》 虚拟化云计算,系统运维,安全技术服务.

网站已经关闭评论