TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。
数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。
提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。
专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。
兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。
众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。
随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。
随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。
当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。
TiDB 作为一款开源分布式 NewSQL 数据库，可以很好的部署和运行在 Intel 架构服务器环境、ARM 架构的服务器环境及主流虚拟化环境，并支持绝大多数的主流硬件网络。作为一款高性能数据库系统，TiDB 支持主流的 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 | 告警通信端口 |
基础配置：
mkfs.ext4 /dev/mapper/centos-home
mount /dev/mapper/centos-home /home -o nodelalloc,noatime
echo "vm.swappiness = 0" >> /etc/sysctl.conf
| 实例 | 个数 | 物理机配置 | 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 | 默认端口 全局目录配置 |
# # Global variables are applied to all deployments and used as the default value of
# # # the deployments if a specific deployment value is missing.
deploy_dir: "/home/tidb-deploy"
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 集群
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_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_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 <cluster-name> 查看当前集群的配置信息，因为其中的 global 和 server_configs 参数配置默认会被 scale-out.yaml 继承，因此也会在 scale-out.yaml 中生效。
tiup cluster scale-out tidb-test scale-out.yaml -y
tiup cluster scale-out tidb-test scale-Tikv.yaml -y
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 由 Linux 内核的核心贡献者 Willy Tarreau 于 2000 年编写，他现在仍然负责该项目的维护，并在开源社区免费提供版本迭代。最新的稳定版本 2.0.0 于 2019 年 8 月 16 日发布，带来更多 优秀的特性。
- 高可用性：HAProxy 提供优雅关闭服务和无缝切换的高可用功能；
- 负载均衡：L4（TCP）和 L7（HTTP）负载均衡模式，至少 9 类均衡算法，比如 roundrobin，leastconn，random 等；
- 健康检查：对 HAProxy 配置的 HTTP 或者 TCP 模式状态进行检查；
- 会话保持：在应用程序没有提供会话保持功能的情况下，HAProxy 可以提供该项功能；
- SSL：支持 HTTPS 通信和解析；
- 监控与统计：通过 web 页面可以实时监控服务状态以及具体的流量信息。
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”选项将其禁用。
stats socket /var/lib/haproxy/stats # 定义统计信息保存位置
retries 2 # 向上游服务器尝试连接的最大次数，超过此值就认为后端服务器不可用
timeout connect 2s # HAProxy 与后端服务器连接超时时间，如果在同一个局域网内可设置成较短的时间
timeout client 30000s # 定义客户端与 HAProxy 连接后，数据传输完毕，不再有数据传输，即非活动连接的超时时间
timeout server 30000s # 定义 HAProxy 与上游服务器非活动连接的超时时间
listen admin_stats #为haproxy访问状态监控页面配置，取名为stats
option httplog # 表示开始启用记录 HTTP 请求的日志功能
stats hide-version # 配置隐藏统计页面上的 HAProxy 版本信息
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 负载均衡
# 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于实例启动慢的服务器，权重会在运行中作调整。
# 检测 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
扫一扫
220
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
