Tidb分布式数据库使用HAproxy实现负载均衡

TiDB 简介

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

五大核心特性

1. 一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

1. 金融级高可用

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

1. 实时 HTAP

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

1. 云原生的分布式数据库

专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

1. 兼容 MySQL 5.7 协议和 MySQL 生态

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

四大核心应用场景

1. 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。

1. 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

1. Real-time HTAP 场景

随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

1. 数据汇聚、二次加工处理的场景

当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

TiDB 软件和硬件环境建议配置

TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境、ARM 架构的服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络。作为一款高性能数据库系统，TiDB 支持主流的 Linux 操作系统环境。

Linux 操作系统版本要求

Linux 操作系统平台	版本
Red Hat Enterprise Linux	7.3 及以上
CentOS	7.3 及以上
Oracle Enterprise Linux	7.3 及以上
Ubuntu LTS	16.04 及以上

开发及测试环境

组件	CPU	内存	本地存储	网络	实例数量(最低要求)
TiDB	8 核+	16 GB+	无特殊要求	千兆网卡	1（可与 PD 同机器）
PD	4 核+	8 GB+	SAS, 200 GB+	千兆网卡	1（可与 TiDB 同机器）
TiKV	8 核+	32 GB+	SSD, 200 GB+	千兆网卡	3
TiFlash	32 核+	64 GB+	SSD, 200 GB+	千兆网卡	1
TiCDC	8 核+	16 GB+	SAS, 200 GB+	千兆网卡	1

生产环境

组件	CPU	内存	硬盘类型	网络	实例数量(最低要求)
TiDB	16 核+	32 GB+	SAS	万兆网卡（2 块最佳）	2
PD	4核+	8 GB+	SSD	万兆网卡（2 块最佳）	3
TiKV	16 核+	32 GB+	SSD	万兆网卡（2 块最佳）	3
TiFlash	48 核+	128 GB+	1 or more SSDs	万兆网卡（2 块最佳）	2
TiCDC	16 核+	64 GB+	SSD	万兆网卡（2 块最佳）	2
监控	8 核+	16 GB+	SAS	千兆网卡	1

网络要求

TiDB 作为开源分布式 NewSQL 数据库，其正常运行需要网络环境提供如下的网络端口配置要求，管理员可根据实际环境中 TiDB 组件部署的方案，在网络侧和主机侧开放相关端口：

组件	默认端口	说明
TiDB	4000	应用及 DBA 工具访问通信端口
TiDB	10080	TiDB 状态信息上报通信端口
TiKV	20160	TiKV 通信端口
TiKV	20180	TiKV 状态信息上报通信端口
PD	2379	提供 TiDB 和 PD 通信端口
PD	2380	PD 集群节点间通信端口
TiFlash	9000	TiFlash TCP 服务端口
TiFlash	8123	TiFlash HTTP 服务端口
TiFlash	3930	TiFlash RAFT 服务和 Coprocessor 服务端口
TiFlash	20170	TiFlash Proxy 服务端口
TiFlash	20292	Prometheus 拉取 TiFlash Proxy metrics 端口
TiFlash	8234	Prometheus 拉取 TiFlash metrics 端口
Pump	8250	Pump 通信端口
Drainer	8249	Drainer 通信端口
CDC	8300	CDC 通信接口
Prometheus	9090	Prometheus 服务通信端口
Node_exporter	9100	TiDB 集群每个节点的系统信息上报通信端口
Blackbox_exporter	9115	Blackbox_exporter 通信端口，用于 TiDB 集群端口监控
Grafana	3000	Web 监控服务对外服务和客户端(浏览器)访问端口
Alertmanager	9093	告警 web 服务端口
Alertmanager	9094	告警通信端口

基础配置：

1、基础环境

umount /home

mkfs.ext4 /dev/mapper/centos-home

mount /dev/mapper/centos-home /home -o nodelalloc,noatime

lsblk -f

vi /etc/fstab

mount -t ext4

echo "vm.swappiness = 0" >> /etc/sysctl.conf

sysctl -p

swapoff -a

TiDB 安装（由于资源有限我按最小拓扑架构）

拓扑信息

实例	个数	物理机配置	IP	配置
TiDB	3	4 VCore 8GB * 1	192.168.1.11 192.168.1.12 192.168.1.13	默认端口 全局目录配置
PD	1	2 VCore 4GB * 1	192.168.1.10	默认端口 全局目录配置
TiKV	3	4 VCore 8GB 500G	192.168.1.11 192.168.1.12 192.168.1.13	默认端口 全局目录配置
Monitoring & Grafana	1	2 VCore 4GB	192.168.1.10	默认端口 全局目录配置

简单最小配置模板

cat  mini.yaml

# # Global variables are applied to all deployments and used as the default value of

# # # the deployments if a specific deployment value is missing.

global:

  user: "tidb"

  ssh_port: 22

  deploy_dir: "/home/tidb-deploy"

  data_dir: "/home/tidb-data"

pd_servers:

  - host: 192.168.1.10

tidb_servers:

  - host: 192.168.1.11

  - host: 192.168.1.12

  - host: 192.168.1.13

tikv_servers:

  - host: 192.168.1.11

  - host: 192.168.1.12

  - host: 192.168.1.13

monitoring_servers:

  - host: 192.168.1.10

启动：

tiup cluster deploy tidb-test v4.0.0 ./mini.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

查看集群信息：

tiup cluster display tidb-test

 

页面也可以查看集群信息：

或者集群不了需求可以使用 TiUP 扩容缩容 TiDB 集群

编写扩容拓扑配置

在 scale-out.yaml 文件添加扩容拓扑配置：

vi scale-out.yaml

tidb_servers:   - host: 192.168.1.14ssh_port: 22     port: 4000     status_port: 10080     deploy_dir: /data/deploy/install/deploy/tidb-4000     log_dir: /data/deploy/install/log/tidb-4000

TiKV 配置文件参考：

tikv_servers:   - host: 192.168.1.14ssh_port: 22     port: 20160     status_port: 20180     deploy_dir: /data/deploy/install/deploy/tikv-20160     data_dir: /data/deploy/install/data/tikv-20160     log_dir: /data/deploy/install/log/tikv-20160

PD 配置文件参考：

pd_servers:   - host: 192.168.1.14ssh_port: 22     name: pd-1     client_port: 2379     peer_port: 2380     deploy_dir: /data/deploy/install/deploy/pd-2379     data_dir: /data/deploy/install/data/pd-2379     log_dir: /data/deploy/install/log/pd-2379

可以使用 tiup cluster edit-config  查看当前集群的配置信息，因为其中的 global 和 server_configs 参数配置默认会被 scale-out.yaml 继承，因此也会在 scale-out.yaml 中生效。

2. 执行扩容命令

tiup cluster scale-out tidb-test scale-out.yaml -y

tiup cluster scale-out tidb-test scale-Tikv.yaml -y

 3.执行缩容操作

tiup cluster scale-in tidb-test --node 192.168.1.14:4000

tiup cluster scale-in tidb-test --node 192.168.1.14:20160

HAProxy

HAProxy 简介

HAProxy 由 Linux 内核的核心贡献者 Willy Tarreau 于 2000 年编写，他现在仍然负责该项目的维护，并在开源社区免费提供版本迭代。最新的稳定版本 2.0.0 于 2019 年 8 月 16 日发布，带来更多 优秀的特性。

HAProxy 部分核心功能

1. 高可用性：HAProxy 提供优雅关闭服务和无缝切换的高可用功能；
2. 负载均衡：L4（TCP）和 L7（HTTP）负载均衡模式，至少 9 类均衡算法，比如 roundrobin，leastconn，random 等；
3. 健康检查：对 HAProxy 配置的 HTTP 或者 TCP 模式状态进行检查；
4. 会话保持：在应用程序没有提供会话保持功能的情况下，HAProxy 可以提供该项功能；
5. SSL：支持 HTTPS 通信和解析；
6. 监控与统计：通过 web 页面可以实时监控服务状态以及具体的流量信息。

安装：

yum install -y haproxy

配置：

 cat /etc/haproxy/haproxy.cfg

#全局配置

global

    log            127.0.0.1 local2   # 定义全局的 syslog 服务器，最多可以定义两个

    nbproc       40                      # 启动多个进程来转发请求，需要调整到足够大的值来保证 HAProxy 本身不会成为瓶颈

    chroot        /var/lib/haproxy  # 将当前目录为指定目录，设置超级用户权限启动进程，提高安全性

    pidfile         /var/run/haproxy.pid  # 将 HAProxy 进程写入 PID 文件

    maxconn    4000                     # 设置每个 HAProxy 进程锁接受的最大并发连接数

    user            haproxy                    # 同 uid 参数，使用是用户名

    group          haproxy               # 同 gid 参数，建议专用用户组

    daemon        # 让 HAProxy 以守护进程的方式工作于后台，等同于“-D”选项的功能。当然，也可以在命令行中用“-db”选项将其禁用。

    # turn on stats unix socket

    stats socket /var/lib/haproxy/stats   # 定义统计信息保存位置

defaults                                   # 默认配置

    log                         global    # 日志继承全局配置段的设置

    retries                    2                   # 向上游服务器尝试连接的最大次数，超过此值就认为后端服务器不可用

    timeout connect    2s              # HAProxy 与后端服务器连接超时时间，如果在同一个局域网内可设置成较短的时间

    timeout client      30000s          # 定义客户端与 HAProxy 连接后，数据传输完毕，不再有数据传输，即非活动连接的超时时间

    timeout server     30000s    # 定义 HAProxy 与上游服务器非活动连接的超时时间

listen admin_stats                   #为haproxy访问状态监控页面配置，取名为stats

    mode http                           #运行模式http

    option httplog                        # 表示开始启用记录 HTTP 请求的日志功能

    maxconn 10                          # 最大并发连接数

    stats hide-version                  # 配置隐藏统计页面上的 HAProxy 版本信息

    bind *:8088                            #监听端口

    stats enable                           #启用监听端口

    maxconn 10                           # 最大并发连接数

    stats refresh 30s                    #页面自动刷新时间30s

    stats uri /stats                        #监控页面的url访问路径，即http://ip/stats访问监控页面

    stats realm Haproxy\ Statistics         #监控页面的密码框提示信息

    stats auth admin:admin@123456        #监控页面的用户和密码admin,可以设置多个用户名

    stats admin if TRUE                     #当通过认证才可管理

listen Tidb     # 配置 database 负载均衡

    mode tcp                                    #HAProxy 中要使用第四层的应用层

    bind *:4001                          #配置浮动 IP 和 监听端口

# 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于实例启动慢的服务器，权重会在运行中作调整。

    balance  leastconn         

# 检测 4000 端口，检测频率为 2000 毫秒。如果检测出 2 次正常就认定机器已恢复正常使用，如果检测出 3 次失败便认定该服务器不可用。

    server  tidb1 192.168.1.11:4000 check inter 2000 rise 2 fall 3  

    server  tidb2 192.168.1.12:4000 check inter 2000 rise 2 fall 3

    server  tidb3 192.168.1.13:4000 check inter 2000 rise 2 fall 3

启动：

systemctl start haproxy

systemctl enable haproxy

systemctl status haproxy

详细安装参考官网：

https://docs.pingcap.com/zh/tidb/stable/overview