TiDB分布式数据库运维实践

一、概述

1.1 背景介绍

TiDB 是 PingCAP 开发的开源分布式关系型数据库，兼容 MySQL 5.7 协议，底层存储基于 TiKV（分布式 KV 存储）和 RocksDB。它解决的核心问题是：当单机 MySQL 无法承载数据量或写入压力时，提供一个对应用透明的水平扩展方案。

TiDB 8.x 在性能、稳定性和 MySQL 兼容性上都有显著提升，TiFlash 列存引擎的成熟使其成为 HTAP（混合事务分析处理）场景的可行选择。但 TiDB 不是 MySQL 的直接替代品，它有自己的架构约束和使用边界，盲目迁移会踩很多坑。

1.2 架构组件

TiDB 集群由四个核心组件构成，每个组件职责清晰：

TiDB Server：无状态的 SQL 层，负责解析 SQL、生成执行计划、协调事务。可以水平扩展，多个 TiDB Server 共享同一份数据。

TiKV：分布式 KV 存储，数据以 Region（默认 96MB）为单位分片，每个 Region 有 3 个副本分布在不同 TiKV 节点上，通过 Raft 协议保证一致性。

PD（Placement Driver）：集群的大脑，负责存储集群元数据、分配全局唯一时间戳（TSO）、调度 Region 分布。PD 是强一致的，必须部署奇数个节点（通常 3 个）。

TiFlash：列存引擎，异步从 TiKV 同步数据，专为 OLAP 查询优化。TiFlash 副本与 TiKV 副本独立，不影响 OLTP 性能。

1.3 适用场景

单表数据量超过 5 亿行，MySQL 分库分表方案维护成本过高

写入 TPS 超过单机 MySQL 上限（通常 > 5 万 TPS）

需要同时支持 OLTP 和实时分析查询（HTAP）

需要跨地域多活部署，对 RPO/RTO 有严格要求

1.4 环境要求

组件	最小规格（生产）	推荐规格	说明
TiDB Server	8C 16GB	16C 32GB	无状态，按负载水平扩展
TiKV	8C 32GB，SSD 1TB	16C 64GB，NVMe 2TB	存储节点，I/O 密集
PD	4C 8GB，SSD 200GB	8C 16GB	3 节点，存储元数据
TiFlash	8C 32GB，SSD 1TB	16C 64GB，NVMe 2TB	按需部署，OLAP 场景
操作系统	CentOS 7.6+ / Rocky 8+	Rocky Linux 8	需要关闭 NUMA 绑定

二、详细步骤

2.1 部署前准备

2.1.1 系统配置

TiDB 对系统配置有严格要求，以下配置必须在部署前完成：

# 关闭 swap（TiKV 对内存压力敏感，swap 会导致性能抖动）
swapoff -a
sed -i'/swap/d'/etc/fstab

# 设置系统参数
cat >> /etc/sysctl.conf << 'EOF'
# TiDB 推荐配置
vm.swappiness = 0
net.core.somaxconn = 32768
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_syn_backlog = 16384
net.core.netdev_max_backlog = 16384
fs.file-max = 1000000
EOF
sysctl -p

# 设置文件描述符限制
cat >> /etc/security/limits.conf << 'EOF'
tidb    soft    nofile    1000000
tidb    hard    nofile    1000000
tidb    soft    stack     10240
EOF

# 关闭透明大页（THP），TiKV 在 THP 开启时延迟会显著增加
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echonever > /sys/kernel/mm/transparent_hugepage/defrag
# 持久化
cat >> /etc/rc.local << 'EOF'
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echonever > /sys/kernel/mm/transparent_hugepage/defrag
EOF

# 检查 NTP 时间同步（PD 的 TSO 依赖时钟同步）
timedatectl status
chronyc tracking | grep"System time"
# 要求各节点时钟偏差 < 50ms

2.1.2 安装 TiUP

TiUP 是 TiDB 的官方部署和管理工具，类似于 MySQL 的 mysqladmin：

# 安装 TiUP（在中控机上执行）
curl --proto'=https'--tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

# 加载环境变量
source~/.bashrc

# 验证安装
tiup --version

# 安装 cluster 组件
tiup cluster

2.2 集群部署

2.2.1 拓扑配置文件

# 文件路径：/opt/tidb/topology.yaml
# 最小生产集群：3 PD + 3 TiKV + 2 TiDB

global:
user:"tidb"
ssh_port:22
deploy_dir:"/tidb-deploy"
data_dir:"/tidb-data"
# 日志目录
log_dir:"/tidb-log"

# 服务器资源配置
server_configs:
tidb:
 log.slow-threshold:300    # 慢查询阈值，单位 ms
 performance.max-procs:0    # 0 表示使用所有 CPU
 prepared-plan-cache.enabled:true# 开启 prepared statement 缓存
 tikv-client.max-batch-wait-time:2000000# 批量请求等待时间，单位 ns

tikv:
 # RocksDB 配置
 rocksdb.defaultcf.block-cache-size:"8GB" # 根据内存调整，建议内存的 30-40%
 rocksdb.writecf.block-cache-size:"2GB"
 # Raft 配置
 raftstore.sync-log:true    # 生产环境必须开启
 raftstore.raft-base-tick-interval:"1s"
 # 存储配置
 storage.reserve-space:"5GB"  # 预留空间，防止磁盘写满导致 TiKV panic

pd:
 replication.max-replicas:3   # 数据副本数
 replication.location-labels:["host"]# 副本分布策略
 schedule.leader-schedule-limit:4
 schedule.region-schedule-limit:2048

pd_servers:
-host:10.0.1.10
-host:10.0.1.11
-host:10.0.1.12

tidb_servers:
-host:10.0.1.13
 port:4000
 status_port:10080
-host:10.0.1.14
 port:4000
 status_port:10080

tikv_servers:
-host:10.0.1.15
 port:20160
 status_port:20180
 config:
  server.labels:{host:"tikv-1"}
-host:10.0.1.16
 port:20160
 status_port:20180
 config:
  server.labels:{host:"tikv-2"}
-host:10.0.1.17
 port:20160
 status_port:20180
 config:
  server.labels:{host:"tikv-3"}

monitoring_servers:
-host:10.0.1.10

grafana_servers:
-host:10.0.1.10

2.2.2 部署和启动

# 检查拓扑配置
tiup cluster check /opt/tidb/topology.yaml --user root

# 自动修复可修复的问题
tiup cluster check /opt/tidb/topology.yaml --user root --apply

# 部署集群
tiup cluster deploy tidb-prod v8.1.0 /opt/tidb/topology.yaml --user root

# 启动集群
tiup cluster start tidb-prod

# 查看集群状态
tiup cluster display tidb-prod

# 连接 TiDB（默认 root 无密码，立即修改）
mysql -h 10.0.1.13 -P 4000 -u root

# 修改 root 密码
ALTER USER'root'@'%'IDENTIFIED BY'TiDB@Root2024!';

三、MySQL 兼容性边界

3.1 支持的功能

TiDB 兼容 MySQL 5.7 协议，大多数 DDL、DML、事务操作都能正常使用。以下功能完全支持：

标准 SQL（SELECT/INSERT/UPDATE/DELETE/JOIN）

事务（BEGIN/COMMIT/ROLLBACK，支持悲观和乐观两种模式）

存储过程、函数、触发器（8.x 版本已基本完善）

分区表（Range、Hash、List 分区）

JSON 数据类型和函数

窗口函数

3.2 不支持或有差异的功能

这是迁移到 TiDB 前必须逐一确认的清单：

-- 1. 不支持 FOREIGN KEY 约束（语法不报错，但不强制执行）
-- TiDB 会忽略外键约束，应用层需要自行保证数据完整性

-- 2. 不支持 FULLTEXT 索引
-- 需要改用 Elasticsearch 或其他全文搜索方案

-- 3. AUTO_INCREMENT 行为不同
-- TiDB 的 AUTO_INCREMENT 在分布式环境下不保证连续，只保证唯一和递增
-- 如果业务依赖 AUTO_INCREMENT 的连续性，需要改造
-- 推荐使用 AUTO_RANDOM 替代，避免写热点：
CREATETABLEorders (
 idBIGINTAUTO_RANDOM PRIMARYKEY, -- 随机分配，避免热点
  user_idBIGINTNOTNULL,
  created_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP
);

-- 4. 不支持 LOCK TABLES 和 UNLOCK TABLES
-- 需要改用事务或 SELECT ... FOR UPDATE

-- 5. 不支持 GET_LOCK() / RELEASE_LOCK()
-- 分布式锁需要用 Redis 或其他方案实现

-- 6. 存储过程中不支持游标的某些用法
-- 建议在应用层处理复杂逻辑

-- 7. 字符集：推荐使用 utf8mb4，其他字符集支持有限

3.3 事务模式选择

TiDB 支持两种事务模式，选择错误会导致性能问题：

-- 悲观事务（默认，8.x 版本）：行为与 MySQL 一致，适合高冲突场景
-- 乐观事务：提交时才检测冲突，适合低冲突场景，性能更好但需要处理冲突重试

-- 查看当前事务模式
SHOWVARIABLESLIKE'tidb_txn_mode';

-- 会话级别切换
SETtidb_txn_mode ='optimistic';

-- 全局切换（my.cnf 中配置）
-- tidb_txn_mode = "pessimistic"

四、热点问题排查

4.1 热点的成因

TiDB 的数据按 Region 分片，每个 Region 有一个 Leader 负责读写。热点问题是指大量请求集中到少数几个 Region，导致这些 Region 所在的 TiKV 节点 CPU 和 I/O 打满，而其他节点空闲。

常见热点场景：

AUTO_INCREMENT 写热点：顺序递增的主键导致新数据总是写入最后一个 Region

时间序列写热点：按时间排序的数据（日志、订单）写入模式与 AUTO_INCREMENT 类似

热门数据读热点：某些 key 被频繁读取（热门商品、用户信息）

4.2 热点排查

-- 通过 TiDB Dashboard 查看热点（推荐）
-- 访问 http://10.0.1.10:2379/dashboard

-- 通过 SQL 查看热点 Region
SELECT*FROMinformation_schema.TIKV_REGION_STATUS
WHEREIS_INDEX =0
ORDERBYWRITTEN_BYTESDESC
LIMIT20;

-- 查看热点表
SELECTTABLE_NAME, WRITTEN_BYTES, READ_BYTES
FROMinformation_schema.TIKV_REGION_STATUS
WHEREIS_INDEX =0
ORDERBYWRITTEN_BYTES + READ_BYTESDESC
LIMIT10;

-- 查看 Region 分布是否均匀
SELECTSTORE_ID,COUNT(*)asregion_count
FROMinformation_schema.TIKV_REGION_STATUS
GROUPBYSTORE_ID
ORDERBYregion_countDESC;

4.3 热点解决方案

-- 方案一：使用 AUTO_RANDOM 替代 AUTO_INCREMENT（推荐）
-- AUTO_RANDOM 在高位随机填充，数据均匀分布到所有 Region
ALTERTABLEordersMODIFYCOLUMNidBIGINTAUTO_RANDOM;

-- 方案二：SHARD_ROW_ID_BITS（对已有表）
-- 将行 ID 的高位用于分片，减少热点
ALTERTABLElogsSHARD_ROW_ID_BITS =4; -- 分成 2^4=16 个分片

-- 方案三：PRE_SPLIT_REGIONS（建表时预分裂）
-- 建表时就创建多个 Region，避免初始写入热点
CREATETABLEevents(
 idBIGINTAUTO_RANDOM PRIMARYKEY,
  event_typeVARCHAR(50),
  created_atTIMESTAMP
) PRE_SPLIT_REGIONS =4; -- 预分裂为 4 个 Region

-- 方案四：手动分裂热点 Region
-- 找到热点 Region ID 后手动分裂
-- 通过 TiDB Dashboard 或 pd-ctl 操作

五、故障排查和监控

5.1 Dashboard 监控关键指标

TiDB Dashboard（内置于 PD）提供了最直观的监控视图，访问地址：http://:2379/dashboard

关键监控面板：

Overview 面板：
- QPS：每秒查询数，区分 SELECT/INSERT/UPDATE/DELETE
- Latency：P99 延迟，正常应 < 100ms
- Connection Count：连接数，接近 max_connections 时告警

TiKV 面板：
- gRPC Duration：TiDB 到 TiKV 的 RPC 延迟，P99 > 50ms 需关注
- Storage：各 TiKV 节点的磁盘使用量，不均匀说明有热点
- Raft Store CPU：Raft 处理 CPU，持续 > 80% 说明写入压力过大

PD 面板：
- Region Health：unhealthy region 数量，正常应为 0
- Scheduler：Region 调度频率，频繁调度说明集群不均衡
- TSO：时间戳分配延迟，P99 > 2ms 需关注

5.2 慢查询分析

-- 查看慢查询日志（TiDB 将慢查询存储在系统表中）
SELECTquery_time, parse_time, compile_time, exec_details,
   query,user, db
FROMinformation_schema.SLOW_QUERY
WHEREquery_time >1-- 超过 1 秒
ORDERBYquery_timeDESC
LIMIT20;

-- 分析执行计划
EXPLAINANALYZESELECT*FROMordersWHEREuser_id =12345;

-- 查看是否走了全表扫描
-- 关注 task 列中的 "TableFullScan"，应尽量避免

-- 强制使用索引
SELECT*FROMordersUSEINDEX(idx_user_id)WHEREuser_id =12345;

-- 查看统计信息是否过期（统计信息不准会导致执行计划退化）
SHOWSTATS_METAWHEREtable_name ='orders';

-- 手动更新统计信息
ANALYZETABLEorders;

5.3 常见问题排查

5.3.1 日志查看

# TiDB Server 日志
tail -f /tidb-log/tidb/tidb.log | grep -i"error|warn"

# TiKV 日志
tail -f /tidb-log/tikv/tikv.log | grep -i"error|slow"

# PD 日志
tail -f /tidb-log/pd/pd.log | grep -i"error|warn"

# 通过 TiUP 查看集群状态
tiup cluster display tidb-prod

# 查看组件日志
tiup cluster audit tidb-prod

5.3.2 常见问题

问题一：写入延迟突然升高

# 检查 TiKV 磁盘 I/O
iostat -x 1 5

# 检查是否有 Region 调度风暴
# 访问 Dashboard -> PD -> Scheduler 面板

# 检查 RocksDB compaction 是否积压
grep"compaction"/tidb-log/tikv/tikv.log | tail -20

问题二：事务冲突导致大量重试

-- 查看事务冲突统计
SHOWSTATUSLIKE'tidb_txn_retry%';

-- 查看锁等待情况
SELECT*FROMinformation_schema.DATA_LOCK_WAITS;

-- 查看当前活跃事务
SELECT*FROMinformation_schema.TIDB_TRXWHEREstate ='LockWaiting';

问题三：Region 不均衡

# 使用 pd-ctl 查看 Region 分布
tiup ctl:v8.1.0 pd -u http://10.0.1.10:2379 region --jq'.regions | map(select(.leader.store_id)) | group_by(.leader.store_id) | map({store: .[0].leader.store_id, count: length})'

# 触发手动均衡
tiup ctl:v8.1.0 pd -u http://10.0.1.10:2379 operator add balance-region 

5.4 性能监控指标

指标名称	正常范围	告警阈值	说明
QPS P99 延迟	< 50ms	> 200ms	整体查询延迟
TiKV gRPC P99	< 20ms	> 100ms	TiDB 到 TiKV 的 RPC 延迟
PD TSO P99	< 2ms	> 10ms	时间戳分配延迟
Region 健康数	0	> 0	异常 Region 数量
TiKV CPU	< 70%	> 90%	TiKV 节点 CPU 使用率
Raft apply log duration	< 1ms	> 10ms	Raft 日志应用延迟

5.5 备份与恢复

# 使用 BR（Backup & Restore）工具进行全量备份
tiup br backup full 
 --pd"10.0.1.10:2379"
 --storage"local:///backup/tidb/$(date +%Y%m%d)"
 --log-file /var/log/tidb/br_backup.log 
 --concurrency 4

# 增量备份（基于上次备份的时间点）
tiup br backup full 
 --pd"10.0.1.10:2379"
 --storage"s3://your-bucket/tidb-backup/$(date +%Y%m%d)"
 --s3.endpoint"https://s3.amazonaws.com"
 --log-file /var/log/tidb/br_backup.log

# 恢复
tiup br restore full 
 --pd"10.0.1.10:2379"
 --storage"local:///backup/tidb/20240101"
 --log-file /var/log/tidb/br_restore.log

# 查看备份信息
tiup br validate decode 
 --field"end-version"
 --storage"local:///backup/tidb/20240101"

六、总结

6.1 TiFlash HTAP 场景

TiFlash 是 TiDB 的列存引擎，适合在不影响 OLTP 的前提下运行分析查询：

-- 为表创建 TiFlash 副本
ALTERTABLEordersSETTIFLASH REPLICA1;

-- 查看 TiFlash 同步进度
SELECT*FROMinformation_schema.TIFLASH_REPLICA
WHERETABLE_NAME ='orders';

-- 强制查询走 TiFlash（分析查询）
SELECT/*+ READ_FROM_STORAGE(TIFLASH[orders]) */
DATE(created_at)asdate,
COUNT(*)asorder_count,
SUM(amount)astotal_amount
FROMorders
WHEREcreated_at >='2024-01-01'
GROUPBYDATE(created_at)
ORDERBYdate;

-- TiDB 优化器会自动选择 TiKV 或 TiFlash
-- OLTP 查询走 TiKV，OLAP 查询走 TiFlash

6.2 迁移到 TiDB 的判断标准

满足以下条件之一，迁移到 TiDB 才有实际价值：

单表行数超过 5 亿，MySQL 分库分表方案的跨分片查询已成为瓶颈

写入 TPS 持续超过 3 万，单机 MySQL 主节点 CPU 长期 > 80%

需要在同一份数据上同时运行 OLTP 和 OLAP，不想维护两套数据同步链路

需要跨地域多活，MySQL 的主从延迟无法满足 RPO 要求

不适合迁移的场景：数据量 < 1TB、写入 TPS < 1 万、大量使用外键约束、依赖 MySQL 特有的存储引擎特性。

6.3 技术要点回顾

架构理解先行：TiDB Server 无状态、TiKV 存数据、PD 管调度，三者职责分离，故障排查要对应到具体组件

热点是头号敌人：AUTO_INCREMENT 在 TiDB 中是反模式，新表一律用 AUTO_RANDOM

兼容性边界要摸清：外键、FULLTEXT、LOCK TABLES 不支持，迁移前必须逐一确认

TiFlash 按需开启：不是所有表都需要 TiFlash 副本，只对有分析查询需求的表开启

监控要看 Dashboard：TiDB Dashboard 集成了热点分析、慢查询、集群拓扑，是日常运维的主要工具

6.4 参考资料

TiDB 8.x 官方文档

TiDB 最佳实践

TiKV 架构设计

TiUP 部署文档

附录

A. 命令速查表

# 查看集群状态
tiup cluster display tidb-prod

# 启动/停止/重启集群
tiup cluster start tidb-prod
tiup cluster stop tidb-prod
tiup cluster restart tidb-prod

# 滚动重启单个组件
tiup cluster restart tidb-prod -R tidb

# 扩容（添加新 TiKV 节点）
tiup cluster scale-out tidb-prod scale-out.yaml

# 缩容（移除 TiKV 节点，会自动迁移数据）
tiup cluster scale-in tidb-prod --node 10.0.1.18:20160

# 升级集群版本
tiup cluster upgrade tidb-prod v8.2.0

# 查看慢查询
mysql -h 10.0.1.13 -P 4000 -u root -p -e 
"SELECT query_time, query FROM information_schema.SLOW_QUERY ORDER BY query_time DESC LIMIT 10;"

B. 配置参数详解

参数	默认值	说明
tidb_slow_log_threshold	300ms	慢查询记录阈值
tidb_txn_mode	pessimistic	事务模式，pessimistic/optimistic
tidb_mem_quota_query	1GB	单个查询最大内存使用量
tidb_distsql_scan_concurrency	15	分布式扫描并发度
rocksdb.defaultcf.block-cache-size	系统内存 45%	RocksDB 块缓存大小
storage.reserve-space	5GB	TiKV 预留磁盘空间

C. 术语表

术语	英文	解释
区域	Region	TiKV 数据分片单位，默认 96MB，每个 Region 有 3 个 Raft 副本
放置驱动	PD (Placement Driver)	集群元数据管理和调度中心
热点	Hotspot	大量请求集中到少数 Region，导致负载不均衡
列存引擎	TiFlash	TiDB 的 OLAP 列存储引擎，异步同步 TiKV 数据
混合事务分析	HTAP	在同一系统中同时支持 OLTP 和 OLAP 工作负载
全局事务标识	TSO (Timestamp Oracle)	PD 分配的全局唯一单调递增时间戳，用于 MVCC