作者： hey-hoho 原文来源：https://tidb.net/blog/586ae0e8
【是否原创】是
【首发渠道】TiDB 社区
前言
分布式关系型数据库 TiDB 是一种计算和存储分离的架构，每一层都可以独立地进行水平扩展，这样就可以做到有的放矢，对症下药。
从 TiDB 整体架构图可以看到，计算层（图中的 TiDB Cluster）负责与外部应用使用 MySQL 协议通信，每一个 TiDB Server 是一个无状态节点彼此独立，应用端连接任何一个 TiDB 节点都可以正常访问数据库。这样做的好处有以下两点：
但这样带来的一个问题是，如果集群有多个 TiDB 节点，应用端应该访问哪一个呢？我们不可能在应用端写多个数据库连接，A 业务访问 TiDB-1，B 业务访问访问 TiDB-2。又或者是习惯了分库分表读写分离的同学会考虑用 MyCat 这类的数据库中间件来实现请求转发。
TiDB 的诞生初衷就是彻底告别各种复杂的数据库拆分模式，做到不和数据库中间件强耦合，我们需要的是一个单纯的代理来自动实现 TiDB 节点路由。
这时候，运行在 TCP 层的负载均衡组件显然更适合。
TiDB 可以用哪些负载均衡组件
经过多方调研和使用，这里推荐以下三种 TiDB 负载均衡方案。
首先是 HAProxy，它作为一款工作在 TCP（四层）和 HTTP（七层）的开源代理组件，支持丰富的负载均衡策略以及出色的性能从而使用非常广泛，它是 TiDB 官方推荐的负载均衡方式。
其次是 LVS，这也是一款鼎鼎大名的负载均衡开源软件，它工作在网络第四层，流量直接通过 Linux 内核来处理性能非常高，同时也支持多种负载均衡算法，但是配置和使用相对比较复杂。
最后要介绍一下 TiDB 孵化器下的 Weir，这个项目最初由伴鱼发起并开源，而后 PingCAP 也加入其中，也是官方推荐的负载均衡之一。除此之外，它还支持 SQL 审计、监控、多租户、自适应熔断限流等高级特性，对这方面有需求的可以优先考虑。和前面两种不一样的是，它是工作在第七层应用层的。
另外，像 DNS 解析或 F5 这类非软件层面的负载均衡也可以用在 TiDB 上，但不在本文的讨论范围。
HAProxy
HAProxy 在 TiDB 中的最佳实践官网有一篇文章详细介绍过，手把手教你如何安装和配置，地址是https://docs.pingcap.com/zh/tidb/dev/haproxy-best-practices
这里借用里面的一张图：
从这张图里面可以发现，引入 HAProxy 后它自身成为了一个单点，一旦出现故障那整个数据库都无法访问，那么搭建高可用负载均衡是不可避免的，这里我推荐的方式是使用 Keepalived+VIP 的方式，架构如下图所示：
Keepalived 的工作原理是基于虚拟路由冗余协议（VRRP）让两台主机绑定同一个虚拟 IP，当其中的 master 节点故障时自动路由到 backup 节点，无需人工介入。
值得一提的是，bakcup 节点在成为 master 前都是闲置状态，有一定的资源浪费。
接下来看一下如何操作。
直接通过 yum 就可以安装 keepalived：
[root@localhost ~]# yum install -y keepalived
[root@localhost ~]# which keepalived/usr/sbin/keepalived
复制代码
它的配置文件在/etc/keepalived/keepalived.conf。
分别在两台负载均衡节点上安装 keepalived。
在第一台节点 (设置为 master) 上修改 keepalived 的配置如下：
! Configuration File for keepalived
global_defs { router_id kad_01 #节点标识，要全局唯一}
vrrp_instance tidb_ha { state MASTER #节点角色 interface ens192 #这里设置成自己的网卡名字，标识绑定到哪个网卡 virtual_router_id 51 #虚拟路由id，同一组主备节点要相同 priority 100 #优先级，要确保master的优先级比backup的高 advert_int 1 #主备之间检查频率为1秒 authentication { auth_type PASS auth_pass tidb666 #主备之间的认证密码 }
virtual_ipaddress { 10.3.65.200 #设置绑定的虚拟IP }}
复制代码
这里只演示了最基础的几个配置，它还可以用更多的配置实现复杂功能，可以参考其他资料实现。
然后启动服务：
[root@localhost haproxy]# systemctl start keepalived[root@localhost haproxy]# systemctl status keepalived
复制代码
可以看到当前 keepalived 已经是active (running)状态，虚拟 IP 已经绑定到了网卡上：
我们用虚拟 IP 为入口验证一下是否能够登录到 TiDB 中：
发现登录成功。
用相同的方式，用如下配置文件在第二个节点启动 keepalived 服务：
! Configuration File for keepalived
global_defs { router_id kad_02 #节点标识，要全局唯一}
vrrp_instance tidb_ha { state BACKUP #节点角色 interface eth0 #这里设置成自己的网卡名字，标识绑定到哪个网卡 virtual_router_id 51 #虚拟路由id，同一组主备节点要相同 priority 50 #优先级，要确保master的优先级比backup的高 advert_int 1 #主备之间检查频率为1秒 authentication { auth_type PASS auth_pass tidb666 #主备之间的认证密码 }
virtual_ipaddress { 10.3.65.200 #设置绑定的虚拟IP }}
复制代码
这里要注意 router_id、state、priority 要与第一个节点不同。
接着我模拟 master 节点故障，直接把它关机：
[root@localhost haproxy]# poweroffConnection closing...Socket close.
Connection closed by foreign host.
Disconnected from remote host(centos-9) at 20:38:16.
Type `help' to learn how to use Xshell prompt.[C:\"~]$
复制代码
退出连接后再次登录，发现依然正常：
另外一点使用 HAProxy 的彩蛋是，Prometheus 官方已经出了 HAProxy 的 exporter，而且从 HAProxy 2.0 开始已经自己提供了 prometheus-exporter，这意味着我们可以很方便的把对 HAProxy 的监控集成到 TiDB 的监控体系中。
限于篇幅，以后再介绍详细。
LVS
LVS 支持三种工作模式，每种模式的工作原理这里不做介绍，大家去参考其他资料，每一种模式的配置方式都不同，我只列出它们之间的对比结果：
我以使用最广泛的 DR 模式来介绍配置过程，相比 HAProxy 它在网络上的配置要复杂一些。
从 DR 的工作原理可以得知，LVS 所在的主机和它后面的真实服务主机都需要绑定同一个虚拟 IP。
先配置 LVS 的主机，复制一份默认网卡的配置进行修改：
[root@localhost ~]# cd /etc/sysconfig/network-scripts[root@localhost network-scripts]# cp ifcfg-eth0 ifcfg-eth0:1[root@localhost network-scripts]# vi ifcfg-eth0:1
TYPE="Ethernet"PROXY_METHOD="none"BROWSER_ONLY="no"BOOTPROTO="static"DEFROUTE="yes"IPV4_FAILURE_FATAL="no"IPV6INIT="yes"IPV6_AUTOCONF="yes"IPV6_DEFROUTE="yes"IPV6_FAILURE_FATAL="no"IPV6_ADDR_GEN_MODE="stable-privacy"IPADDR=10.3.65.201 # 这里配置虚拟IPNETMASK=255.255.255.0NAME="eth0:1"DEVICE="eth0:1"ONBOOT="yes"~ [root@localhost network-scripts]# systemctl restart network
复制代码
接着对 TiDB 节点进行网卡配置：
[root@localhost ~]# cd /etc/sysconfig/network-scripts[root@localhost network-scripts]# cp ifcfg-lo ifcfg-lo:1[root@localhost network-scripts]# vi ifcfg-lo:1
DEVICE=lo:1IPADDR=10.3.65.201NETMASK=255.255.255.255NETWORK=127.0.0.0# If you're having problems with gated making 127.0.0.0/8 a martian,# you can change this to something else (255.255.255.255, for example)BROADCAST=127.255.255.255ONBOOT=yesNAME=loopback~ [root@localhost network-scripts]# systemctl restart network[root@localhost network-scripts]# vi /etc/sysctl.conf # 这里新增下面显示的几条配置[root@localhost network-scripts]# sysctl -pnet.ipv4.conf.all.arp_ignore = 1net.ipv4.conf.default.arp_ignore = 1net.ipv4.conf.lo.arp_ignore = 1net.ipv4.conf.all.arp_announce = 2net.ipv4.conf.default.arp_announce = 2net.ipv4.conf.lo.arp_announce = 2[root@localhost network-scripts]# route add -host 10.3.65.201 dev lo:1
复制代码
Linux 内核从 2.4 版本开始就已经集成了 LVS，所以我们不用单独安装了，这里只需要安装它的管理工 ipvsadmin。
[root@localhost ~]# yum install ipvsadm[root@localhost ~]# ipvsadm -LnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn
复制代码
通过 ipvsadm 添加 LVS 节点信息：
[root@localhost ~]# ipvsadm -A -t 10.3.65.201:4000 -s wrr -p 5 #这里添加虚拟IP，使用加权轮询策略
复制代码
然后把 TiDB 节点也添加进去：
[root@localhost network-scripts]# ipvsadm -a -t 10.3.65.201:4000 -r 10.3.65.126:4000 -g
复制代码
这里的 -t 参数指定 LVS 节点虚拟 IP，-r 参数指定后面的真实服务节点也就是 TiDB 的访问端口，如果有多个 TiDB 节点就每个都加入。
准备就绪以后，我们把当前的信息保存到 LVS 配置文件中，然后启动服务即可：
[root@localhost network-scripts]# ipvsadm --save > /etc/sysconfig/ipvsadm[root@localhost network-scripts]# cat /etc/sysconfig/ipvsadm-A -t 10.3.65.201:4000 -s wrr-a -t 10.3.65.201:4000 -r 10.3.65.126:4000 -g -w 1[root@localhost network-scripts]# systemctl start ipvsadm
复制代码
启动以后通过虚拟 IP 来登录到 TiDB 中，发现登录成功：
LVS 的高可用方案与前面提到的 HAProxy 类似，都是使用 keepalived 来实现，为了避免大量重复内容，这里只给出 Master 的关键配置：
! Configuration File for keepalived
global_defs { router_id kad_01 #节点标识，要全局唯一}
vrrp_instance tidb_ha { state MASTER #节点角色 interface eth0 #这里设置成自己的网卡名字，标识绑定到哪个网卡 virtual_router_id 51 #虚拟路由id，同一组主备节点要相同 priority 100 #优先级，要确保master的优先级比backup的高 advert_int 1 #主备之间检查频率为1秒 authentication { auth_type PASS auth_pass tidb666 #主备之间的认证密码 }
virtual_ipaddress { 10.3.65.201 #设置绑定的虚拟IP }
virtual_server 10.3.65.201 4000 { delay_loop 6 #服务轮询的时间间隔 lb_algo wrr #加权轮询调度，调度算法有 rr|wrr|lc|wlc|lblc|sh|sh lb_kind DR #LVS工作模式 NAT|DR|TUN persistence_timeout 50 #会话保持时间 protocol TCP #健康检查协议
# 真实的后台服务，这里配TiDB访问信息，每个TiDB节点配置一个real_server real_server 10.3.65.126 4000 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 4000 } } }}
复制代码
Backup 节点配置参考前面的修改即可，更多详细配置可以去网上搜索。
Weir
网上关于 Weir 的信息并不多，有用的资料都来自Github 主页的文档，Weir 的架构和原理可以参考这篇文章：https://asktug.com/t/topic/93717，这里只总结一下如何去快速使用。
首先从 Github 拉取源码编译安装：
[root@localhost ~]# git clone https://github.com/tidb-incubator/weir[root@localhost ~]# cd weir[root@localhost ~]# make weirproxy
复制代码
它涉及到两个配置文件，一个和 proxy 相关（weir 默认端口是 6000），一个和 namespace 相关，都在 conf 目录下。简单起见，proxy 的配置我不做任何修改都用默认值，只改一下 namespace 配置里和 TiDB 有关的参数：
[root@localhost weir]# vi conf/namespace/test_namespace.yaml
version: "v1"namespace: "test_namespace"frontend: allowed_dbs: - "test" slow_sql_time: 50 sql_blacklist: denied_ips: idle_timeout: 3600 users: - username: "weir" password: "111111"
backend: instances: - "10.3.65.126:4000" username: "root" password: "" selector_type: "random" pool_size: 10 idle_timeout: 60~
复制代码
详细的配置参数可以参考官方文档。
修改好配置后运行启动文件：
[root@localhost weir]# ./bin/weirproxy &
复制代码
通过 Weir 暴露的入口登录到 TiDB，发现登录成功：
这里要注意的是，MySQL 客户端登录时使用的账号密码是 namespace 中设置的信息，不再是 TiDB 原本的账号密码。
Weir 的高可用方案官方介绍的不多，没有提供原生的高可用支持。从某个角度来看，Weir 更像是 TiDB SQL 层的一个 HTTP 扩展，所以也是无状态服务，如果部署多个 Weir 来做集群的话，那么它的上层就需要引入像 Nginx 或 HAProxy 这样的负载均衡组件，问题好像一下子回到最开始了。
与前面两种方案相比，Weir 实施起来稍微有点重，不过它胜在支持前面两种没有的功能，这就需要大家根据实际情况取舍，还是希望 Weir 会越做越好。
总结
总体来说，本文介绍的内容都偏 TiDB 外侧的东西，看似关系不大但是又很重要，一旦用了 TiDB 就不得不考虑负载均衡的问题，希望本文能给大家带来一些帮助。
评论