写生产环境TiDB集群最怕的就是照着文档敲完命令结果监控面板一片飘红业务一上线就出幺蛾子。这篇是《二TIDB搭建正式集群》接着之前的环境准备往下走目标很明确——用TiUP在一批真实的服务器上把TiDB、PD、TiKV三个组件搭成一套高可用集群顺便把那些文档里不会写的坑都给你趟一遍。如果你正打算从测试环境往生产环境迁移或者第一次在公司内网部署TiDB这篇内容应该能帮你省下不少弯路。1. 正式集群规划先想清楚再动手1.1 为什么正式环境不能用单机“一把梭”很多朋友是这么入门的在自己的笔记本或者一台虚拟机上用TiUP playground命令一键拉起一个TiDB测试实例跑几个SQL查一下执行计划感觉挺简单。等到要上生产了就想着把playground里的配置搬到一台大内存服务器上照样跑。这个思路在数据量小、并发低的场景下能凑合但一旦进入正式业务问题立刻暴露。首先是单点故障。TiDB架构里TiDB无状态挂了可以再拉PD是整个集群的大脑负责存储元数据和调度PD宕机时间长了整个集群基本就不可写了TiKV是实际数据存储节点一个副本挂了数据就少了冗余。单机部署意味着这些组件全挤在一台机器上机器一宕全盘皆输。其次是性能隔离完全不存在。TiKV是CPU密集和IO密集型的PD虽然资源占用不算高但它是延迟敏感型服务对时钟和磁盘IO都有要求。TiDB是计算节点跑复杂查询时CPU会飙高。三者混部在同一个操作系统上相互干扰出了问题排查起来也非常痛苦你根本分不清是哪个组件把资源吃满了。最后是扩容能力受限。TiDB集群的扩展性在于水平扩展TiKV不够了加TiKV节点TiDB压力大了加TiDB节点。单机部署玩不了这套数据涨上去之后只能原地换机器而换机器这种事在生产环境里绝对是灾难级别的操作。所以正式集群的第一步就是物理隔离组件角色按职责分配机器。1.2 节点角色与硬件选型参考TiDB集群最小的高可用形态是三组件各至少两节点TiDB节点无状态前端负载均衡接入至少2个节点可以用相对均衡的配置CPU主频高一点更好。PD节点强一致性要求节点数建议3个奇数个方便选主磁盘IOPS和延迟要求高数据量不大但写入频繁。TiKV节点数据节点至少3个节点起步每个节点副本数为3时3个TiKV刚好满足一主两从的冗余策略。硬件选型上有一个容易犯的错误以为TiKV最吃内存就把所有钱都花在内存上结果CPU核数不够region调度和compaction压力一大写入就卡住了。TiKV的处理能力跟CPU核数直接挂钩每张表的数据分布、region分裂合并都要消耗CPU。建议TiKV节点CPU核数不少于16核内存不少于64GB而且在条件允许的情况下TiKV的数据盘必须用SSD机械盘在写入放大面前就是灾难。PD节点因为要做Raft选举和元数据读写磁盘延迟直接影响集群稳定性。之前踩过一个坑用了一台共享存储的虚拟机做PD结果宿主机上其他业务IO一忙PD的etcd读写延迟飙到几百毫秒集群leader不断切换业务端表现为间歇性写入失败。所以PD节点建议用独立物理机或者有IOPS保障的云盘。TiDB节点对磁盘要求没那么苛刻但它会缓存表结构信息和一部分统计信息同时承担复杂的计算任务。建议内存不低于32GBCPU 8核以上网络带宽要充足因为TiDB节点拿数据是从TiKV拉取的。1.3 端口规划与网络连通性清单部署之前把端口规划好省得到时候防火墙这边卡一下那边挡一下查半天都不知道问题出在哪。TiDB集群涉及的主要端口组件默认端口用途TiDB4000MySQL协议接入端口TiDB10080TiDB状态上报端口PD2379客户端连接PD的接口PD2380PD集群节点间通信端口TiKV20160TiKV gRPC通信端口TiKV20180TiKV状态上报端口Prometheus9090监控数据查询端口Grafana3000可视化监控面板端口节点之间的网络要求是内网互通延迟越低越好。如果在云环境部署需要保证同VPC内网通信不要走公网IP互通一来延迟不可控二来安全隐患很大。另外所有节点之间的防火墙策略要提前配置好我之前遇到过集群部署完之后监控面板连不上排查了半天发现是Prometheus所在节点访问TiKV状态端口被安全组挡住了。2. 环境初始化与TiUP部署准备2.1 系统配置与文件系统选择TiDB官方推荐的Linux发行版是CentOS 7.3或者RHEL 7.3实际测试下来Ubuntu 20.04 LTS和Debian 11也能稳定运行只是有些初始化脚本里的命令需要微调。内核参数方面TiUP部署工具会帮我们自动设置大部分参数但有三个点建议提前手动确认。文件系统方面强烈建议数据盘使用ext4或者xfs不要用zfs或者btrfs原因很简单——TiKV底层的RocksDB对文件系统有一些特殊的操作要求比如fallocate、O_DIRECT支持非主流文件系统容易出现兼容性问题而咱们部署生产环境稳定压倒一切没必要为了尝鲜给自己挖坑。挂载数据盘的时候有个细节TiKV的数据目录所在的分区mount参数建议加上 noatime关闭文件访问时间更新可以减少不必要的磁盘写入。另外建议给数据盘单独分区不要把系统盘和数据盘混在一起不然系统日志写满磁盘的时候TiKV直接就被拖死了。2.2 时钟同步是硬要求TiDB集群对时钟同步的要求比大多数分布式系统都要严格原因在于PD和TiKV的Raft协议依赖时间戳来保证事务的一致性。多节点之间如果时钟偏差过大会出现时间戳回退、事务冲突异常、备份恢复错乱等奇怪问题。生产环境强烈建议部署NTP或者chrony所有节点指向同一个时间源。之前部署过一个跨机房的集群两个机房的NTP源不一样导致节点间时钟偏差接近1秒表现出的症状非常诡异——写入偶发失败报错信息里夹着“timestamp mismatch”之类的字样。当时查了好久最后逐个节点执行date命令对比才发现是时钟不同步。验证方法很简单在每台服务器上执行chronyc sources -v或者用老一点的NTP工具ntpdate -q 时间服务器IP用每台机器的时间和基准时间源对比偏差控制在100ms以内为佳被测试环境过坑的朋友应该都懂这个数值的含义。2.3 系统资源限制与性能摸底TiKV在高并发写入场景下会打开大量文件建议提前调高open file limit。虽然TiUP部署的时候会自动设置但有时候受限于systemd服务文件的配置进程实际能打开的fd数可能不够。ulimit -n 1048576这个命令在当前shell下生效如果要永久生效需要修改/etc/security/limits.conf文件加上* soft nofile 1048576 * hard nofile 1048576性能摸底这一步很多人会跳过但我觉得值得做。在正式部署TiKV之前用fio对数据盘做一次简单的读写测试至少能发现磁盘是否存在隐藏的性能问题。比如有些云主机的数据盘虽然是SSD但IOPS被限流了等到上线之后才发现性能不足就晚了。fio -filename/data/testfile -direct1 -iodepth 64 -rwrandwrite -ioenginelibaio -bs4k -size1G -numjobs8 -runtime30 -group_reporting -nametest重点关注一下4K随机写入的IOPS和平均延迟如果平均延迟超过10ms那这块盘跑TiKV会非常吃力建议要么换盘要么调整TiKV的写入参数。3. 中间控制节点与拓扑文件编写3.1 控制节点部署TiUPTiUP是TiDB官方提供的包管理器它的作用有点像Linux下的yum或者apt但针对的是TiDB生态的各个组件。控制节点单独用一台机器不部署任何TiDB组件只装TiUP和相关的运维工具。curl --proto https --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh安装完成后重新加载环境变量source ~/.bashrc然后验证TiUP是否安装成功tiup --versionTiUP的组件安装都在用户目录下默认路径是~/.tiup如果需要统一管理可以在安装前设置TIUP_HOME环境变量指向一个空间充足的分区。之前碰到过一个问题控制节点的home目录挂载在根分区上根分区只有20G装了几套集群的离线镜像之后磁盘告警差点把控制节点的系统盘撑爆。3.2 编写拓扑文件的要点TiUP集群部署的核心是拓扑文件一个YAML格式的配置文件描述了集群里各组件部署在哪些节点、各自使用什么端口和目录。这一步是整个部署流程的“图纸”图纸画歪了后面全歪。global: user: tidb ssh_port: 22 deploy_dir: /tidb-deploy data_dir: /tidb-data server_configs: tikv: server.grpc-concurrency: 8 raftstore.apply-max-batch-size: 256 pd_servers: - host: 10.0.1.11 - host: 10.0.1.12 - host: 10.0.1.13 tidb_servers: - host: 10.0.1.21 - host: 10.0.1.22 tikv_servers: - host: 10.0.1.31 - host: 10.0.1.32 - host: 10.0.1.33 - host: 10.0.1.34有几个值得注意的点。第一global.user字段定义了集群进程的运行用户TiUP会自动在目标机器上创建这个用户生产环境建议用独立的用户而不是root。第二deploy_dir是组件部署目录data_dir是数据目录数据目录一定要指向你挂载的独立数据盘。第三如果某个TiKV节点的数据盘是单独挂载的可以在该节点下单独指定data_dir不必所有节点都用全局默认值。另外需要强调一下TiKV的CPU绑核配置这是很多生产集群容易忽略的。TiKV默认会使用机器上所有的CPU核心如果一台机器上还有其他业务进程比如监控agent、日志采集就会互相争抢CPU。可以在拓扑文件的server_configs中配置tikv: server.grpc-concurrency: 8 raftstore.store-concurrency: 4 storage.block-cache.capacity: 32GBstorage.block-cache.capacity这个参数直接决定了RocksDB的块缓存大小默认值是总内存的一定比例如果机器内存大且混部了其他进程建议显式指定一个合理的值避免TiKV把内存吃光。3.3 离线部署的镜像准备在企业内网环境服务器通常是不能直接访问外网的。TiUP默认从官方镜像源下载组件内网环境会安装失败。这时候需要在一台能联网的机器上提前下载好离线镜像包。tiup mirror clone tidb-community-${version}-linux-amd64 ${version} --all执行完之后会生成一个本地目录把这个目录整个拷贝到控制节点然后在控制节点上执行tiup mirror set tidb-community-${version}-linux-amd64这样TiUP就会从本地镜像源拉取组件无需联网。这个离线包里包含了TiDB、TiKV、PD、Prometheus、Grafana等所有组件一个包全搞定。离线部署模式在版本选择上要特别小心最好所有组件的版本保持一致。有些朋友喜欢某几个组件升级到小版本某几个不升结果TiDB、TiKV、PD之间的协议版本不兼容集群跑起来之后TiKV一直报“version mismatch”这属于自己给自己找麻烦。官方推荐的组合方式是在一个release版本内统一升级。4. TiUP集群部署实战4.1 从环境检查到正式部署拓扑文件写好了离线镜像准备好了接下来就是执行部署命令。我习惯分两步走先检查再部署。tiup cluster check ./topology.yaml --user root这个check命令会检查目标机器的CPU、内存、磁盘、时钟同步、系统参数等是否符合要求如果检查出警告项建议逐条看完不要一股脑忽略。有一些warning可以忽略比如内核版本比官方推荐的低一点点但有些error必须处理比如端口被占用、磁盘空间不足。检查通过后执行部署tiup cluster deploy tidb-prod ${version} ./topology.yaml --user root -p-p参数表示需要输入root密码来建立SSH信任关系。如果不希望交互式输入密码也可以用-i /path/to/ssh_key.pem指定SSH私钥。部署过程会持续几分钟控制台的输出可以看到每个组件的初始化和启动状态。有几个常见问题在这里提前预警。如果某个节点SSH登录特别慢或者超时先检查控制节点到该节点的22端口是否通很多内网环境只开了业务端口SSH端口被安全策略拦了。如果部署过程中报permission denied并且你用的是root用户部署看一下目标机器的SSH配置是否允许root登录有些安全要求高的服务器禁止root远程登录这时候要么改用有sudo权限的普通用户要么临时开放root登录权限部署完成后改回来。如果某个组件启动后立即退出查看组件日志是最直接的排查手段日志文件在deploy_dir对应组件的log目录下。4.2 集群启动与初始化部署完成后有一个初始化操作设置集群的root密码。tiup cluster enable tidb-prod tiup cluster start tidb-prod注意enable命令在systemd环境下是设置开机自启如果漏掉这一步服务器重启之后集群不会自动拉起这在生产环境是一场事故。建议部署完立即执行。启动之后可以用tiup cluster display tidb-prod查看集群状态如果所有节点都是Up状态说明基本通电了。然后执行初始化密码tiup cluster exec tidb-prod --commandtiup cluster change-password实际上更标准的操作是通过MySQL客户端连接TiDB用ALTER USER语句修改root密码mysql -h 10.0.1.21 -P 4000 -u rootALTER USER root% IDENTIFIED BY your-strong-password;这里的密码策略要遵循公司的安全规范至少包含大小写字母、数字和特殊字符长度不低于12位。4.3 验证集群内部的region调度集群起来之后别急着接业务先验证一下数据副本的分布情况。刚部署完的TiKV节点上还没有任何数据执行下面这条SQL看看集群健康状态SELECT * FROM information_schema.cluster_info;用pd-ctl查看region分布情况tiup ctl pd -u http://10.0.1.11:2379 store正常情况下每台TiKV节点都应该出现在store列表中状态是Up。如果某台TiKV节点状态显示Offline或者Disconnect需要马上看一下该节点的网络和磁盘是不是有问题别让集群带病上线。5. 监控告警与Dashboard使用5.1 Prometheus与Grafana面板配置TiUP部署集群时会自动带上Prometheus和Grafana监控数据默认从每个组件的status端口采集。部署完成后打开Grafana默认端口是3000初始账号密码是admin/admin登录后建议第一时间改密码。Grafana里预置了很多面板重点要关注这么几个TiDB Overview集群整体的QPS、延迟、连接数。TiKV Details每个TiKV节点的CPU、内存、磁盘IO、Raft store相关指标。PDPD的leader切换次数、etcd延迟、region数量变化。其中PD面板里有一个指标特别值得盯——leader change正常情况下这个数字应该长时间保持稳定如果频繁变化说明PD节点不稳定要么是网络抖动要么是磁盘延迟高这是集群健康度的晴雨表。5.2 告警规则的重要性很多人在测试环境搭集群从不配告警但生产环境没有告警监控等于裸奔。TiUP部署的Prometheus自带了一些基础的告警规则但默认只是记录在Prometheus内部没有对接告警通道。推荐的做法是配置Alertmanager把告警路由到企业内部的钉钉、企业微信或者邮件。TiDB官方提供的告警规则模板覆盖了大部分核心场景比如TiKV节点down、PD leader切换异常、region副本数不足、磁盘空间不足等。有一个告警阈值我觉得默认值偏宽松就是TiKV的磁盘空间使用率默认可能到80%或者90%才告警。但TiKV在磁盘空间不足时会触发region调度把数据往其他节点迁移如果所有节点都到了80%调度就会非常被动。建议提前在告警规则里把磁盘使用率阈值调到70%给自己留出处理时间。6. 常见问题与排查技巧实录6.1 部署阶段的高频故障问题现象执行tiup cluster deploy时长时间卡在某个组件不动。排查思路多半是网络问题控制节点到目标节点的某个端口连接不通。可以用telnet测试对应IP和端口如果通了再等如果没通调整防火墙之后重新部署。问题现象TiKV启动失败日志提示/tidb-data/tikv目录不存在或权限不足。排查思路检查拓扑文件里data_dir指向的目录是否存在以及global.user指定的用户对目录是否有读写权限。TiUP不会自动创建数据目录的挂载点需要提前建好并把属主改为运行用户。问题现象集群部署完成但tiup cluster display显示某个PD节点Down。排查思路第一时间查看PD日志常见原因是PD集群之间2379端口不通或者PD节点的etcd数据目录权限不对。PD是集群的命脉宁可慢一点排查也不能带病强行启动。6.2 运行期的隐患和排查心得集群运行一段时间后最常遇到的性能问题是TiKV的region分布不均。可以通过Dashboard的Key Visualizer功能查看如果发现某个节点的数据明显比其他节点多说明region调度不够积极。这时候需要检查PD的调度参数特别是region-schedule-limit和leader-schedule-limit如果这两个值过低调度就会被卡住。另一个容易被忽略的问题是多集群共用一套监控组件。如果公司在同一个网段部署了多套TiDB集群每一套都用默认的端口配置监控数据会互相覆盖面板上看到的指标张冠李戴。建议每套集群的Prometheus和Grafana都使用不同的端口或者在Prometheus的采集配置里严格区分job名称。6.3 安全加固的几点补充生产环境的集群需要做一些基本的安全加固TiDB的4000端口不对公网开放只允许业务应用的IP访问。PD的2379端口是内部管理端口绝对不要暴露给外部否则任何能访问到这个端口的人都可以用pd-ctl操作集群包括下线节点这种危险操作。Grafana和Prometheus端口建议通过反向代理加一层认证而不是直接裸奔在内网里。定期备份PD的元数据虽然PD本身有三副本但如果整个PD集群损坏恢复的复杂度远高于TiKV数据恢复。关于安全这块我得特意偏离一下那些不当联想强调一点TiDB本身的权限体系和MySQL兼容生产环境务必遵循最小权限原则为不同业务创建独立账号只授予必要的库表权限。不要什么应用都拿root去连出了问题连审计追踪都做不了。7. 扩容与后续演进建议7.1 TiKV节点扩容操作集群的数据量增长到一定程度三个TiKV节点扛不住的时候扩容是必然的操作。TiUP的扩容非常方便tiup cluster scale-out tidb-prod ./scale-out-tikv.yaml需要编写一个只包含新增节点的拓扑文件格式和部署时一样只是只写TiKV部分。扩容过程会自动把新节点加入集群PD会自动开始往新节点调度region整个过程业务不需要停机。扩容的时候有一点要注意不要一次性扩容太多节点比如一次加5个TiKV节点PD会因为要同时往5个新节点迁移数据而产生巨大的调度压力反而把线上性能拖垮。建议一次扩2个等region调度到基本均衡之后再加下一批。7.2 TiDB组件升级的节奏TiDB的版本迭代速度比较快很多团队喜欢跟着升级。我的建议是小版本升级可以积极一点通常包含bugfix和安全补丁大版本升级务必先在测试环境完整验证特别是业务SQL的兼容性和性能变化。TiUP的升级操作tiup cluster upgrade tidb-prod ${new-version}升级过程中TiUP会逐个节点滚动重启理论上可以在线完成。但实际生产环境我还是建议找业务低峰期操作哪怕TiDB宣称在线升级也要给自己留足回退的余地。从我个人的实操体验来说TiDB集群的搭建并不复杂真正需要用心的地方在于前期的资源规划和后期的运维监控。很多问题看着是部署不成功追根究底都是前面某个细节埋下的雷——比如PD的节点磁盘不行、TiKV的CPU核数不够、节点时钟不同步、监控端口没放开。把这几个基础盘打扎实了TiDB集群跑起来会非常稳后续维护的精力也能省下大半。最后再分享一个小建议集群搭好之后找一个业务空闲的窗口做一次完整的kill -9演练把TiKV节点强制杀掉一个看看集群是否会按照预期自动恢复。这个动作花不了多少时间但能让你在真实的故障来临之前心里先有个底。别等到生产环境挂了再去验证你的高可用方案那时候的代价就不是一顿加班能解决的了。