单机Linux无法运行生产可用TiDB集群，仅推荐tiup playground用于开发测试：启动1个TiDB/PD/TiKV全内存实例，端口4000，退出即清空；必须确保chrony时间偏移＜50ms，否则TiKV拒绝注册。
单机 Linux 上跑不了生产可用的 TiDB 分布式集群——组件没隔离、时钟不同步、IO 干扰、拓扑不可感知，tiup cluster deploy 启动后大概率卡在 clock offset too large 或 scheduler failed: no available stores 就停了。
用 tiup playground 快速验证本地功能是否正常
这是唯一推荐给开发/测试场景的单机启动方式，不模拟真实拓扑，但能跑通 SQL、看懂组件交互：
-
tiup playground启动的是全内存模式，默认 1 个tidb、1 个pd、1 个tikv，所有日志和数据都在临时目录，退出即清空 - 必须确保
chrony已运行且同步有效：chronyc tracking输出的Offset应小于 50ms，否则tikv直接拒绝注册 - 如果提示
libnsl.so.1: cannot open shared object file（常见于 CentOS Stream / KOS），补装：dnf install libnsl - 连接端口固定为
4000：mysql -h 127.0.0.1 -P 4000 -u root，无需密码
tiup cluster deploy 前必须确认的三件事
这不是“配好 YAML 就能跑”的流程，失败几乎都卡在这三个硬性前提上：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
systemd必须启用且默认运行——tiup生成的 service 文件依赖systemctl daemon-reload和systemctl start tidb-server@xxx，Alpine 或最小化容器镜像直接报错静默退出 - 所有目标节点时间必须毫秒级同步：
chrony配置里必须含makestep 1 -1，禁用ntpd；timedatectl status的System clock synchronized必须为yes -
/data/tikv和/data/pd所在文件系统不能是ext4 + barrier=0或XFS + nobarrier——TiKV WAL 会损坏，现象是 Region 持续Down或Pending Peer
扩容时 tiup cluster scale-out 失败的典型原因
加机器不是改完 topology.yaml 就完事，PD 调度策略和标签识别才是关键：
-
pd-ctl config set region-schedule-limit 8—— 默认限流值是4，SSD 集群下 Region 平衡慢得肉眼可见，不调这个，新节点长期空载 - 新节点若打了
label（如rack=us-east-1a），但没同步更新 PD 全局拓扑配置：pd-ctl config set location-labels "zone,rack,host"，PD 会认为拓扑不完整，拒绝调度，日志反复出现scheduler failed: no available stores - 扩容后务必检查
pd-ctl store输出中新节点状态是否为Up，且leader_weight和region_weight不为0
为什么不用 Kubernetes 而坚持用 tiup 管物理机/VM
不是 K8s 不行，而是当你的硬件或业务有以下任一特征时，tiup 更可靠：
- 需要
taskset -c 0-7绑核给tikv-server——K8s 的cpuset在高负载下仍可能被内核调度器穿透，TiKV 对 CPU cache locality 敏感 - 用了 NVMe 直通或 DPDK 加速网卡——K8s CNI 插件难以绕过内核协议栈，而
tikv的 gRPC 流量对微秒级延迟抖动极其敏感 - PD 和 etcd 共享磁盘/CPU——K8s 上 etcd 常与
kube-apiserver同节点，API 压力上升时 PD 心跳超时，触发误判驱逐，日志里满屏lost leader
真正要建生产集群，3 台起，每台至少 64 核 / 128GB 内存 / NVMe SSD，pd 单独部署，tikv 和 tidb 混部但用 cgroups 隔离——这些细节漏掉任何一项，集群上线后都会在 Region 调度、时钟漂移或 WAL 刷盘上出问题。
