1. 项目概述为什么选择TiDB最近在折腾一个数据量增长飞快的项目MySQL单机实例开始有点力不从心了分库分表的方案评估下来开发和运维的复杂度又太高。正好团队里有人提了一嘴TiDB说这玩意儿兼容MySQL协议还能自动水平扩展听着挺玄乎。我花了几天时间从零开始把一套TiDB集群给搭了起来过程中踩了不少坑也总结了一些心得。这篇文章就记录一下TiDB数据库从零到一的安装与部署全过程重点不是照搬官方文档而是分享一个一线运维视角下的实操路径、避坑指南和原理性的理解。如果你也在考虑引入分布式数据库或者单纯想自己动手搭一个TiDB玩玩这篇内容应该能帮你省下不少查资料和排错的时间。TiDB的核心价值在于它用起来像MySQL但骨子里是分布式的。这意味着你现有的、基于MySQL的应用程序几乎不用改代码就能迁移过来同时获得了弹性伸缩、高可用、强一致性这些分布式数据库才有的能力。它特别适合两类场景一是业务数据量增长迅猛预估很快会碰到单机数据库天花板二是业务本身就带有“原生分布式”特性比如多租户SaaS、物联网数据平台等需要一套能轻松应对数据分布和增长的底层存储。2. 部署架构设计与核心组件解析在真正动手敲命令之前我们必须先搞清楚TiDB到底由哪些“零件”组成以及它们是如何协同工作的。盲目安装往往会导致后续运维的混乱。2.1 TiDB集群的核心四大组件一个标准的TiDB集群包含四个核心组件它们各司其职共同构成了一个完整的“数据库系统”TiDB Server计算层这是集群的“大门”和“大脑”。它对外暴露MySQL协议你的应用程序直接连接的就是它。TiDB Server本身是无状态的不存储数据只负责接收SQL请求、进行解析、优化并生成分布式执行计划然后下发给存储层TiKV执行。正因为无状态你可以轻松部署多个TiDB Server实例来实现负载均衡和高可用。这就像餐厅的服务员负责接待顾客、点单并把订单交给后厨。TiKV Server存储层这是集群的“保险柜”真正负责存储数据。数据以Key-Value的形式按照范围被自动切分成一个个Region默认约96MB分布在不同TiKV节点上。TiKV采用Raft共识算法来保证多个副本之间数据的一致性和高可用。每个Region通常会有3个副本分散在不同的物理服务器上即使一台机器宕机数据也不会丢失服务也不会中断。这相当于餐厅的后厨和多个备用的冷藏库。PD Server调度层Placement Driver简称PD是集群的“总指挥”和“调度中心”。它负责整个集群的元数据管理、TiKV节点的状态监控、Region副本的调度如负载均衡、副本迁移、Leader选举等以及分配全局唯一且递增的事务ID。PD通常也需要部署奇数个节点如3个来保证自身的高可用。它就像餐厅的经理掌握所有桌位Region和厨师TiKV的状态负责协调和调度。TiFlash分析引擎这是一个可选的列式存储组件。TiKV是行存擅长OLTP事务处理而TiFlash是列存擅长OLAP复杂分析。TiFlash通过Raft Learner协议从TiKV异步复制数据使得同一份数据同时拥有行存和列存两种格式实现了HTAP混合事务/分析处理能力。如果你的业务没有实时分析需求初期可以不部署TiFlash。2.2 部署拓扑规划生产与测试环境考量理解了组件我们就要规划它们如何部署在服务器上。拓扑规划直接影响到集群的性能和稳定性。对于测试或学习环境资源有限 你可以将所有组件部署在一台机器上这就是所谓的“All-in-One”部署。TiUPTiDB的部署管理工具的playground模式就是干这个的一键拉起一个单机集群非常适合快速体验。但切记这绝对不能用于生产因为所有组件竞争资源单点故障会导致整个集群不可用。对于生产或准生产环境 必须采用分布式部署。这里给出一个最小化的高可用方案需要至少4台物理机或虚拟机主机1: PD1, TiDB1主机2: PD2, TiKV1主机3: PD3, TiKV2主机4: TiDB2, TiKV3这个拓扑的考量点在于PD部署了3个实例形成高可用集群且分散在3台主机上避免主机宕机导致PD集群失联。TiDB部署了2个实例可以实现应用端的负载均衡和连接故障转移。TiKV部署了3个实例每个实例上运行一个TiKV进程。数据Region的3个副本会均匀分布在这3个TiKV节点上满足Raft协议的最小副本数要求确保数据高可用。特别注意TiKV是IO和CPU密集型组件应独占主机或与对资源不敏感的组件如TiDB混部但要避免与PD混部因为PD对磁盘IO延迟敏感。关键经验生产环境务必保证TiKV节点是奇数个如357并且每个TiKV实例配置的存储目录--data-dir必须挂载在高性能SSD磁盘上。使用机械硬盘会直接导致集群性能极差甚至不可用。3. 实战部署使用TiUP进行集群初始化官方推荐的部署和管理工具是TiUP它类似于Python的pip或CentOS的yum极大地简化了流程。我们以在4台CentOS 7.9服务器上部署上述生产拓扑为例。3.1 系统准备与前置检查在所有目标服务器上执行以下操作系统参数调整编辑/etc/sysctl.conf添加或修改以下参数优化网络和文件系统性能这对于分布式系统至关重要。# 增加TCP连接队列大小 net.core.somaxconn 32768 # 加快故障检测减少网络分区误判 net.ipv4.tcp_keepalive_time 60 net.ipv4.tcp_keepalive_intvl 10 net.ipv4.tcp_keepalive_probes 6 # 允许更多端口范围应对高并发连接 net.ipv4.ip_local_port_range 20000 65535 # 允许核心转储 kernel.core_pattern /tmp/core-%e-%p-%t执行sysctl -p使配置生效。资源限制调整编辑/etc/security/limits.conf解除对TiDB进程的资源限制。* soft nofile 1000000 * hard nofile 1000000 * soft stack 32768 * hard stack 32768退出当前会话重新登录后生效可通过ulimit -n验证。关闭防火墙或配置规则为了方便测试可以先关闭防火墙systemctl stop firewalld systemctl disable firewalld。生产环境则应开放必要端口TiDB: 4000, PD: 2379, TiKV: 20160, TiFlash: 3930, 监控组件端口等。时间同步分布式集群对时间一致性要求极高必须配置NTP服务确保所有节点时间同步。yum install -y ntp systemctl start ntpd systemctl enable ntpd ntpdate -u pool.ntp.org3.2 TiUP安装与拓扑文件编写选择其中一台机器作为中控机所有部署操作将从这里发起。安装TiUPcurl --proto https --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh安装完成后按提示执行source ~/.bashrc或重新打开终端。声明全局环境变量可选但推荐export TIUP_MIRRORShttps://tiup-mirrors.pingcap.com编写拓扑配置文件topology.yaml 这是部署的核心定义了我们之前规划的架构。以下是一个示例global: user: tidb # 建议创建一个专门的tidb用户来运行服务 group: tidb deploy_dir: /data/tidb-deploy data_dir: /data/tidb-data arch: amd64 pd_servers: - host: 192.168.1.101 name: pd-101 - host: 192.168.1.102 name: pd-102 - host: 192.168.1.103 name: pd-103 tidb_servers: - host: 192.168.1.101 - host: 192.168.1.104 tikv_servers: - host: 192.168.1.102 port: 20160 status_port: 20180 - host: 192.168.1.103 port: 20160 status_port: 20180 - host: 192.168.1.104 port: 20160 status_port: 20180 monitoring_servers: - host: 192.168.1.101 # 将监控部署在101上 grafana_servers: - host: 192.168.1.101注意deploy_dir是二进制文件和配置文件存放路径data_dir是真实数据存储路径。务必确保data_dir尤其是TiKV的所在磁盘有足够空间和IOPS。3.3 执行部署与初始化在中控机生成SSH互信TiUP需要通过SSH到各节点执行命令。tiup cluster deploy tidb-test v7.5.0 ./topology.yaml --user root -p这里tidb-test是集群名称v7.5.0是TiDB版本-p表示需要输入中控机到各节点的root密码。你也可以提前配置好SSH密钥免密登录这样更安全便捷。启动集群tiup cluster start tidb-test检查集群状态tiup cluster display tidb-test这个命令会输出一个表格显示所有组件的状态Up/Healthy/Down、监听端口等信息。务必确保所有组件的Status都是Up。4. 集群访问、监控与基本验证部署成功只是第一步我们需要验证集群是否真的工作正常。4.1 连接TiDB并执行测试TiDB Server默认监听4000端口使用任何MySQL客户端均可连接。mysql -h 192.168.1.101 -P 4000 -u root连接成功后你可以执行一些SQL来验证-- 查看TiDB版本 SELECT VERSION(); -- 创建一个测试库表 CREATE DATABASE test_tidb; USE test_tidb; CREATE TABLE t1 (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50)); -- 插入一些数据测试分布式事务 INSERT INTO t1(name) VALUES (node1), (node2), (node3); -- 查询数据验证功能 SELECT * FROM t1; -- 查看TiDB特有的集群信息表 SELECT * FROM information_schema.tikv_region_status LIMIT 5;4.2 使用内置监控平台GrafanaPrometheusTiUP在部署时会自动安装监控组件。这是排查问题、了解集群健康状况的利器。通过浏览器访问http://monitoring_server_ip:3000默认用户/密码admin/admin。在Grafana首页你已经可以看到TiDB集群的监控大盘如“Overview”、“TiDB”、“TiKV”、“PD”等。重点关注几个核心监控项TiDB Dashboard实际上更推荐使用TiDB Dashboard它内置于PD组件中。访问http://pd_ip:2379/dashboard功能更集成特别是对SQL语句分析、慢查询查看非常直观。TiKV面板查看Region count是否均匀Storage capacity使用情况99% command duration延迟是否在正常范围通常几毫秒到几十毫秒。PD面板查看Region health确保没有miss-peer或pending-peer的Region。系统面板查看各节点的CPU、内存、磁盘IO和网络流量确保没有资源瓶颈。4.3 执行简单的负载测试可以使用sysbench或go-tpc进行简单压测观察集群在压力下的表现。# 使用TiUP安装go-tpc tiup install bench # 创建测试数据在tpcc库下 tiup bench tpcc -H 192.168.1.101 -P 4000 -D tpcc --warehouses 10 prepare # 运行负载测试一段时间 tiup bench tpcc -H 192.168.1.101 -P 4000 -D tpcc --warehouses 10 --time 5m run压测期间实时观察Grafana监控关注QPS、延迟、各节点资源利用率是否均衡。5. 生产环境关键配置调优与安全加固默认部署的集群可以运行但要用于生产必须进行一些调优和加固。5.1 核心参数调优建议TiKV配置 (tikv.toml)readpool.storage/readpool.coprocessor处理读写请求的线程池大小根据CPU核心数调整。建议设置为逻辑核心数的75%-80%。raftstore.capacity单个TiKV实例的存储容量。务必设置为小于磁盘总容量的值例如2T的SSD盘设置为1.8TB为操作系统和日志留出空间。server.grpc-concurrencygRPC线程数默认4在高并发场景下可适当调大。rocksdb相关参数如max-background-jobs后台压缩线程数对写入性能影响大建议设置为CPU核心数。可以通过TiUP在线修改配置并滚动重启tiup cluster edit-config tidb-test # 在编辑器中修改tikv_servers下的config配置节 tiup cluster reload tidb-test -R tikvTiDB配置 (tidb.toml)token-limit每个TiDB实例的并发连接数限制默认1000。根据应用连接池大小调整。prepared-plan-cache启用执行计划缓存对OLTP重复查询提升明显。log.level生产环境建议设置为“info”避免“debug”级别产生大量日志。PD配置 (pd.toml)schedule相关参数控制Region调度如leader-schedule-limitregion-schedule-limit。初期可采用默认值在出现热点或负载不均时再调整。5.2 安全加固措施创建专属用户禁用root远程登录在TiDB内为应用创建专属数据库用户授予最小必要权限。CREATE USER app_user% IDENTIFIED BY StrongPassword123!; GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO app_user%;启用TLS加密传输对于生产环境强烈建议启用TiDB组件间及客户端到TiDB的TLS加密。这需要在拓扑文件中配置tls相关项并准备证书。过程稍复杂但能有效防止流量窃听。配置防火墙白名单严格限制可访问TiDB端口4000、PD端口2379和监控端口3000, 9090的源IP地址。定期备份使用BR (Backup Restore)或Dumpling工具进行逻辑/物理备份。备份策略是数据安全的最后防线。# 使用BR进行全量备份到S3兼容存储 tiup br backup full --pd 192.168.1.101:2379 \ --storage s3://bucket/backup-20240527/ \ --send-credentials-to-tikvtrue6. 常见运维问题与故障排查实录在实际运维中你肯定会遇到各种问题。这里记录几个典型场景和排查思路。6.1 集群启动失败或组件状态异常现象tiup cluster display显示某个组件状态为Down或Unhealthy。排查步骤查看日志首先使用tiup cluster log tidb-test -N 节点IP -R 组件名查看对应组件的错误日志。例如tiup cluster log tidb-test -N 192.168.1.102 -R tikv。常见原因端口冲突检查端口2379, 20160, 4000等是否被其他进程占用。目录权限检查deploy_dir和data_dir的所属用户和权限是否正确应为拓扑中指定的user如tidb。磁盘空间不足检查data_dir所在磁盘是否已满。内存不足TiKV启动需要较大内存如果机器内存不足可能会被操作系统OOM Killer杀掉。查看系统日志/var/log/messages。手动启动测试登录到问题节点切换到部署用户手动进入deploy_dir/bin目录尝试启动进程观察终端输出。例如./tikv-server --config ../conf/tikv.toml。6.2 业务写入或查询变慢现象应用侧反馈SQL响应时间变长。排查思路查看监控立即打开Grafana或TiDB Dashboard。检查慢查询在Dashboard的SQL语句分析页面查看是否有高延迟的SQL。检查TiKV查看TiKV的99% command duration延迟是否飙升。检查CPU usage、IO throughput是否饱和。查看Region leader分布是否均匀是否存在热点Region某个TiKV的Leader数量远高于其他。检查PD查看Region health是否有大量pending-peer副本同步延迟。分析热点如果发现热点Region可以使用pd-ctl工具手动切分热点Region或者从业务层面优化例如将单调递增的主键改为随机散列的UUID或使用Shard列。tiup ctl:v7.5.0 pd -u http://192.168.1.101:2379 operator show # 查看正在进行的调度 hotspot # 查看热点统计分析慢SQL对于具体的慢SQL使用EXPLAIN ANALYZE查看其执行计划和在TiKV上的实际执行耗时判断是索引问题、统计信息不准还是执行计划选择错误。6.3 TiKV节点磁盘空间告警现象监控报警显示某个TiKV节点的磁盘使用率超过80%。处理流程确认数据量在Dashboard查看集群总数据量和各TiKV存储用量判断是整体数据增长还是数据倾斜。扩容TiKV节点如果是整体增长最直接的方法是扩容TiKV节点。通过TiUP添加新节点并滚动重启集群PD会自动将部分Region迁移到新节点上实现存储容量和负载的均衡。tiup cluster scale-out tidb-test scale-out.yaml处理数据倾斜如果是个别TiKV数据过多可能是热点或Range分布不均。除了上述热点处理方法还可以检查表的主键设计。对于大表可以考虑使用SPLIT TABLE语句预分割Region。清理旧数据如果业务允许可以考虑归档或删除历史数据。TiDB从v6.1.0开始支持TTL (Time to Live)表可以自动删除过期数据这是一个非常实用的功能。6.4 PD集群Leader频繁切换现象监控发现PD的Leader频繁变更可能导致调度短暂停顿。可能原因网络问题PD节点间网络延迟高或丢包严重导致选举超时。使用ping和traceroute检查节点间网络质量。磁盘IO延迟高PD将元数据存储在本地如果磁盘特别是data_dir所在磁盘IO延迟高会导致心跳或日志落盘慢触发重新选举。务必为PD节点配置低延迟的SSD盘。系统负载过高PD节点CPU或内存资源耗尽。检查系统监控。时钟不同步这是分布式系统的大忌。务必确保所有节点包括TiDB, TiKV, PD的时钟通过NTP保持高度同步偏差最好在100ms以内。部署和运维TiDB集群是一个系统工程从硬件选型、拓扑规划、参数调优到日常监控每个环节都需要仔细考量。我的体会是前期规划越充分后期运维就越轻松。尤其是存储TiKV的磁盘性能、网络质量和时钟同步这三点是稳定性的基石千万不能将就。另外一定要善用TiDB Dashboard和监控它们能帮你把抽象的集群状态变得可视化很多问题在萌芽阶段就能被发现和解决。对于刚上手的团队建议先在测试环境充分演练故障场景如重启节点、模拟网络分区熟悉整个运维流程和工具链这样在面对生产环境的问题时才能心中有数手中有策。
1. 项目概述为什么选择TiDB最近在折腾一个数据量增长飞快的项目MySQL单机实例开始有点力不从心了分库分表的方案评估下来开发和运维的复杂度又太高。正好团队里有人提了一嘴TiDB说这玩意儿兼容MySQL协议还能自动水平扩展听着挺玄乎。我花了几天时间从零开始把一套TiDB集群给搭了起来过程中踩了不少坑也总结了一些心得。这篇文章就记录一下TiDB数据库从零到一的安装与部署全过程重点不是照搬官方文档而是分享一个一线运维视角下的实操路径、避坑指南和原理性的理解。如果你也在考虑引入分布式数据库或者单纯想自己动手搭一个TiDB玩玩这篇内容应该能帮你省下不少查资料和排错的时间。TiDB的核心价值在于它用起来像MySQL但骨子里是分布式的。这意味着你现有的、基于MySQL的应用程序几乎不用改代码就能迁移过来同时获得了弹性伸缩、高可用、强一致性这些分布式数据库才有的能力。它特别适合两类场景一是业务数据量增长迅猛预估很快会碰到单机数据库天花板二是业务本身就带有“原生分布式”特性比如多租户SaaS、物联网数据平台等需要一套能轻松应对数据分布和增长的底层存储。2. 部署架构设计与核心组件解析在真正动手敲命令之前我们必须先搞清楚TiDB到底由哪些“零件”组成以及它们是如何协同工作的。盲目安装往往会导致后续运维的混乱。2.1 TiDB集群的核心四大组件一个标准的TiDB集群包含四个核心组件它们各司其职共同构成了一个完整的“数据库系统”TiDB Server计算层这是集群的“大门”和“大脑”。它对外暴露MySQL协议你的应用程序直接连接的就是它。TiDB Server本身是无状态的不存储数据只负责接收SQL请求、进行解析、优化并生成分布式执行计划然后下发给存储层TiKV执行。正因为无状态你可以轻松部署多个TiDB Server实例来实现负载均衡和高可用。这就像餐厅的服务员负责接待顾客、点单并把订单交给后厨。TiKV Server存储层这是集群的“保险柜”真正负责存储数据。数据以Key-Value的形式按照范围被自动切分成一个个Region默认约96MB分布在不同TiKV节点上。TiKV采用Raft共识算法来保证多个副本之间数据的一致性和高可用。每个Region通常会有3个副本分散在不同的物理服务器上即使一台机器宕机数据也不会丢失服务也不会中断。这相当于餐厅的后厨和多个备用的冷藏库。PD Server调度层Placement Driver简称PD是集群的“总指挥”和“调度中心”。它负责整个集群的元数据管理、TiKV节点的状态监控、Region副本的调度如负载均衡、副本迁移、Leader选举等以及分配全局唯一且递增的事务ID。PD通常也需要部署奇数个节点如3个来保证自身的高可用。它就像餐厅的经理掌握所有桌位Region和厨师TiKV的状态负责协调和调度。TiFlash分析引擎这是一个可选的列式存储组件。TiKV是行存擅长OLTP事务处理而TiFlash是列存擅长OLAP复杂分析。TiFlash通过Raft Learner协议从TiKV异步复制数据使得同一份数据同时拥有行存和列存两种格式实现了HTAP混合事务/分析处理能力。如果你的业务没有实时分析需求初期可以不部署TiFlash。2.2 部署拓扑规划生产与测试环境考量理解了组件我们就要规划它们如何部署在服务器上。拓扑规划直接影响到集群的性能和稳定性。对于测试或学习环境资源有限 你可以将所有组件部署在一台机器上这就是所谓的“All-in-One”部署。TiUPTiDB的部署管理工具的playground模式就是干这个的一键拉起一个单机集群非常适合快速体验。但切记这绝对不能用于生产因为所有组件竞争资源单点故障会导致整个集群不可用。对于生产或准生产环境 必须采用分布式部署。这里给出一个最小化的高可用方案需要至少4台物理机或虚拟机主机1: PD1, TiDB1主机2: PD2, TiKV1主机3: PD3, TiKV2主机4: TiDB2, TiKV3这个拓扑的考量点在于PD部署了3个实例形成高可用集群且分散在3台主机上避免主机宕机导致PD集群失联。TiDB部署了2个实例可以实现应用端的负载均衡和连接故障转移。TiKV部署了3个实例每个实例上运行一个TiKV进程。数据Region的3个副本会均匀分布在这3个TiKV节点上满足Raft协议的最小副本数要求确保数据高可用。特别注意TiKV是IO和CPU密集型组件应独占主机或与对资源不敏感的组件如TiDB混部但要避免与PD混部因为PD对磁盘IO延迟敏感。关键经验生产环境务必保证TiKV节点是奇数个如357并且每个TiKV实例配置的存储目录--data-dir必须挂载在高性能SSD磁盘上。使用机械硬盘会直接导致集群性能极差甚至不可用。3. 实战部署使用TiUP进行集群初始化官方推荐的部署和管理工具是TiUP它类似于Python的pip或CentOS的yum极大地简化了流程。我们以在4台CentOS 7.9服务器上部署上述生产拓扑为例。3.1 系统准备与前置检查在所有目标服务器上执行以下操作系统参数调整编辑/etc/sysctl.conf添加或修改以下参数优化网络和文件系统性能这对于分布式系统至关重要。# 增加TCP连接队列大小 net.core.somaxconn 32768 # 加快故障检测减少网络分区误判 net.ipv4.tcp_keepalive_time 60 net.ipv4.tcp_keepalive_intvl 10 net.ipv4.tcp_keepalive_probes 6 # 允许更多端口范围应对高并发连接 net.ipv4.ip_local_port_range 20000 65535 # 允许核心转储 kernel.core_pattern /tmp/core-%e-%p-%t执行sysctl -p使配置生效。资源限制调整编辑/etc/security/limits.conf解除对TiDB进程的资源限制。* soft nofile 1000000 * hard nofile 1000000 * soft stack 32768 * hard stack 32768退出当前会话重新登录后生效可通过ulimit -n验证。关闭防火墙或配置规则为了方便测试可以先关闭防火墙systemctl stop firewalld systemctl disable firewalld。生产环境则应开放必要端口TiDB: 4000, PD: 2379, TiKV: 20160, TiFlash: 3930, 监控组件端口等。时间同步分布式集群对时间一致性要求极高必须配置NTP服务确保所有节点时间同步。yum install -y ntp systemctl start ntpd systemctl enable ntpd ntpdate -u pool.ntp.org3.2 TiUP安装与拓扑文件编写选择其中一台机器作为中控机所有部署操作将从这里发起。安装TiUPcurl --proto https --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh安装完成后按提示执行source ~/.bashrc或重新打开终端。声明全局环境变量可选但推荐export TIUP_MIRRORShttps://tiup-mirrors.pingcap.com编写拓扑配置文件topology.yaml 这是部署的核心定义了我们之前规划的架构。以下是一个示例global: user: tidb # 建议创建一个专门的tidb用户来运行服务 group: tidb deploy_dir: /data/tidb-deploy data_dir: /data/tidb-data arch: amd64 pd_servers: - host: 192.168.1.101 name: pd-101 - host: 192.168.1.102 name: pd-102 - host: 192.168.1.103 name: pd-103 tidb_servers: - host: 192.168.1.101 - host: 192.168.1.104 tikv_servers: - host: 192.168.1.102 port: 20160 status_port: 20180 - host: 192.168.1.103 port: 20160 status_port: 20180 - host: 192.168.1.104 port: 20160 status_port: 20180 monitoring_servers: - host: 192.168.1.101 # 将监控部署在101上 grafana_servers: - host: 192.168.1.101注意deploy_dir是二进制文件和配置文件存放路径data_dir是真实数据存储路径。务必确保data_dir尤其是TiKV的所在磁盘有足够空间和IOPS。3.3 执行部署与初始化在中控机生成SSH互信TiUP需要通过SSH到各节点执行命令。tiup cluster deploy tidb-test v7.5.0 ./topology.yaml --user root -p这里tidb-test是集群名称v7.5.0是TiDB版本-p表示需要输入中控机到各节点的root密码。你也可以提前配置好SSH密钥免密登录这样更安全便捷。启动集群tiup cluster start tidb-test检查集群状态tiup cluster display tidb-test这个命令会输出一个表格显示所有组件的状态Up/Healthy/Down、监听端口等信息。务必确保所有组件的Status都是Up。4. 集群访问、监控与基本验证部署成功只是第一步我们需要验证集群是否真的工作正常。4.1 连接TiDB并执行测试TiDB Server默认监听4000端口使用任何MySQL客户端均可连接。mysql -h 192.168.1.101 -P 4000 -u root连接成功后你可以执行一些SQL来验证-- 查看TiDB版本 SELECT VERSION(); -- 创建一个测试库表 CREATE DATABASE test_tidb; USE test_tidb; CREATE TABLE t1 (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50)); -- 插入一些数据测试分布式事务 INSERT INTO t1(name) VALUES (node1), (node2), (node3); -- 查询数据验证功能 SELECT * FROM t1; -- 查看TiDB特有的集群信息表 SELECT * FROM information_schema.tikv_region_status LIMIT 5;4.2 使用内置监控平台GrafanaPrometheusTiUP在部署时会自动安装监控组件。这是排查问题、了解集群健康状况的利器。通过浏览器访问http://monitoring_server_ip:3000默认用户/密码admin/admin。在Grafana首页你已经可以看到TiDB集群的监控大盘如“Overview”、“TiDB”、“TiKV”、“PD”等。重点关注几个核心监控项TiDB Dashboard实际上更推荐使用TiDB Dashboard它内置于PD组件中。访问http://pd_ip:2379/dashboard功能更集成特别是对SQL语句分析、慢查询查看非常直观。TiKV面板查看Region count是否均匀Storage capacity使用情况99% command duration延迟是否在正常范围通常几毫秒到几十毫秒。PD面板查看Region health确保没有miss-peer或pending-peer的Region。系统面板查看各节点的CPU、内存、磁盘IO和网络流量确保没有资源瓶颈。4.3 执行简单的负载测试可以使用sysbench或go-tpc进行简单压测观察集群在压力下的表现。# 使用TiUP安装go-tpc tiup install bench # 创建测试数据在tpcc库下 tiup bench tpcc -H 192.168.1.101 -P 4000 -D tpcc --warehouses 10 prepare # 运行负载测试一段时间 tiup bench tpcc -H 192.168.1.101 -P 4000 -D tpcc --warehouses 10 --time 5m run压测期间实时观察Grafana监控关注QPS、延迟、各节点资源利用率是否均衡。5. 生产环境关键配置调优与安全加固默认部署的集群可以运行但要用于生产必须进行一些调优和加固。5.1 核心参数调优建议TiKV配置 (tikv.toml)readpool.storage/readpool.coprocessor处理读写请求的线程池大小根据CPU核心数调整。建议设置为逻辑核心数的75%-80%。raftstore.capacity单个TiKV实例的存储容量。务必设置为小于磁盘总容量的值例如2T的SSD盘设置为1.8TB为操作系统和日志留出空间。server.grpc-concurrencygRPC线程数默认4在高并发场景下可适当调大。rocksdb相关参数如max-background-jobs后台压缩线程数对写入性能影响大建议设置为CPU核心数。可以通过TiUP在线修改配置并滚动重启tiup cluster edit-config tidb-test # 在编辑器中修改tikv_servers下的config配置节 tiup cluster reload tidb-test -R tikvTiDB配置 (tidb.toml)token-limit每个TiDB实例的并发连接数限制默认1000。根据应用连接池大小调整。prepared-plan-cache启用执行计划缓存对OLTP重复查询提升明显。log.level生产环境建议设置为“info”避免“debug”级别产生大量日志。PD配置 (pd.toml)schedule相关参数控制Region调度如leader-schedule-limitregion-schedule-limit。初期可采用默认值在出现热点或负载不均时再调整。5.2 安全加固措施创建专属用户禁用root远程登录在TiDB内为应用创建专属数据库用户授予最小必要权限。CREATE USER app_user% IDENTIFIED BY StrongPassword123!; GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO app_user%;启用TLS加密传输对于生产环境强烈建议启用TiDB组件间及客户端到TiDB的TLS加密。这需要在拓扑文件中配置tls相关项并准备证书。过程稍复杂但能有效防止流量窃听。配置防火墙白名单严格限制可访问TiDB端口4000、PD端口2379和监控端口3000, 9090的源IP地址。定期备份使用BR (Backup Restore)或Dumpling工具进行逻辑/物理备份。备份策略是数据安全的最后防线。# 使用BR进行全量备份到S3兼容存储 tiup br backup full --pd 192.168.1.101:2379 \ --storage s3://bucket/backup-20240527/ \ --send-credentials-to-tikvtrue6. 常见运维问题与故障排查实录在实际运维中你肯定会遇到各种问题。这里记录几个典型场景和排查思路。6.1 集群启动失败或组件状态异常现象tiup cluster display显示某个组件状态为Down或Unhealthy。排查步骤查看日志首先使用tiup cluster log tidb-test -N 节点IP -R 组件名查看对应组件的错误日志。例如tiup cluster log tidb-test -N 192.168.1.102 -R tikv。常见原因端口冲突检查端口2379, 20160, 4000等是否被其他进程占用。目录权限检查deploy_dir和data_dir的所属用户和权限是否正确应为拓扑中指定的user如tidb。磁盘空间不足检查data_dir所在磁盘是否已满。内存不足TiKV启动需要较大内存如果机器内存不足可能会被操作系统OOM Killer杀掉。查看系统日志/var/log/messages。手动启动测试登录到问题节点切换到部署用户手动进入deploy_dir/bin目录尝试启动进程观察终端输出。例如./tikv-server --config ../conf/tikv.toml。6.2 业务写入或查询变慢现象应用侧反馈SQL响应时间变长。排查思路查看监控立即打开Grafana或TiDB Dashboard。检查慢查询在Dashboard的SQL语句分析页面查看是否有高延迟的SQL。检查TiKV查看TiKV的99% command duration延迟是否飙升。检查CPU usage、IO throughput是否饱和。查看Region leader分布是否均匀是否存在热点Region某个TiKV的Leader数量远高于其他。检查PD查看Region health是否有大量pending-peer副本同步延迟。分析热点如果发现热点Region可以使用pd-ctl工具手动切分热点Region或者从业务层面优化例如将单调递增的主键改为随机散列的UUID或使用Shard列。tiup ctl:v7.5.0 pd -u http://192.168.1.101:2379 operator show # 查看正在进行的调度 hotspot # 查看热点统计分析慢SQL对于具体的慢SQL使用EXPLAIN ANALYZE查看其执行计划和在TiKV上的实际执行耗时判断是索引问题、统计信息不准还是执行计划选择错误。6.3 TiKV节点磁盘空间告警现象监控报警显示某个TiKV节点的磁盘使用率超过80%。处理流程确认数据量在Dashboard查看集群总数据量和各TiKV存储用量判断是整体数据增长还是数据倾斜。扩容TiKV节点如果是整体增长最直接的方法是扩容TiKV节点。通过TiUP添加新节点并滚动重启集群PD会自动将部分Region迁移到新节点上实现存储容量和负载的均衡。tiup cluster scale-out tidb-test scale-out.yaml处理数据倾斜如果是个别TiKV数据过多可能是热点或Range分布不均。除了上述热点处理方法还可以检查表的主键设计。对于大表可以考虑使用SPLIT TABLE语句预分割Region。清理旧数据如果业务允许可以考虑归档或删除历史数据。TiDB从v6.1.0开始支持TTL (Time to Live)表可以自动删除过期数据这是一个非常实用的功能。6.4 PD集群Leader频繁切换现象监控发现PD的Leader频繁变更可能导致调度短暂停顿。可能原因网络问题PD节点间网络延迟高或丢包严重导致选举超时。使用ping和traceroute检查节点间网络质量。磁盘IO延迟高PD将元数据存储在本地如果磁盘特别是data_dir所在磁盘IO延迟高会导致心跳或日志落盘慢触发重新选举。务必为PD节点配置低延迟的SSD盘。系统负载过高PD节点CPU或内存资源耗尽。检查系统监控。时钟不同步这是分布式系统的大忌。务必确保所有节点包括TiDB, TiKV, PD的时钟通过NTP保持高度同步偏差最好在100ms以内。部署和运维TiDB集群是一个系统工程从硬件选型、拓扑规划、参数调优到日常监控每个环节都需要仔细考量。我的体会是前期规划越充分后期运维就越轻松。尤其是存储TiKV的磁盘性能、网络质量和时钟同步这三点是稳定性的基石千万不能将就。另外一定要善用TiDB Dashboard和监控它们能帮你把抽象的集群状态变得可视化很多问题在萌芽阶段就能被发现和解决。对于刚上手的团队建议先在测试环境充分演练故障场景如重启节点、模拟网络分区熟悉整个运维流程和工具链这样在面对生产环境的问题时才能心中有数手中有策。
)
