4 台机器部署 TiDB 生产集群，其中 1 台硬件配置、型号不一致，能否直接上线生产？需要做哪些规避配置？

[大唐天子 (Ti D Ber Gt Qk Ceg E)]

【TiDB 使用环境】生产环境（业务替换 MySQL 分表，日均写入 80w+）
【TiDB 版本】v7.6.0
【操作系统】CentOS7.9
【部署方式】物理机 TiUP 离线部署
【机器硬件明细（共 4 台）】
机器 A/B/C：同配置，24 核 CPU、64G 内存、2 块 NVMe SSD；
机器 D：老服务器，12 核 CPU、32G 内存、普通 SATA SSD，整机性能约另外三台一半。

[克里克里克 (Ti D Ber H052ej9m)]

不用D，或者只在D上部署监控和HA类的软件吧。

[wbslxw (Ti D Ber Cl S0j Eng)]

D 机器 CPU / 内存 / 磁盘 IO 均短板，TiKV 负载高时成为性能瓶颈、热点拖慢全集群

[菩提老祖]

木桶效应。
放个tidb 监控也可以。

[kang]

升级前建议先看 release notes，大版本之间有些参数默认值会变。另外生产环境升级建议先在一个 TiKV 节点灰度验证，观察一段时间没问题再全量升级。

[独善其身 (Ti D Ber Bi Rqfz5 K)]

3台同规格高配：TiDB + TiKV + PD（2 台带 PD，第 3 台只 TiDB+TiKV）1 台异类低配：只部署 PD + Prometheus + ng-monitoring、不部署 TiKV/TiDB PD 凑 3 副本：2 高配 PD + 1 异类 PD，满足 Raft quorum 高可用；TiKV 全部集中在 3 台同规格服务器。

[Kongdom]

建议直接去掉D

[TiDB001 (Ti D Ber G Ec Kbxr N)]

TiDB 的 Raft 复制与调度依赖所有 TiKV 节点响应一致，低配（如慢盘、小内存、弱 CPU）会导致 Region Leader 切换延迟、写入阻塞、GC 压力升高，甚至引发集群不稳定。‌必须替换或避免部署 TiKV。

[TiDBer_lPQGLonR]

可以上线，靠 Label+Placement 限制 D 机不承接 Leader、只存副本

[mtmt (Ti D Ber O1 Snfo3y)]

1. TiUP 拓扑给 A/B/C 打perf:high、D 打perf:low，滚动重启 TiKV
2. PD 注册标签：pd-ctl config set replication.location-labels '["perf"]'
3. SQL 创建放置策略（3 副本：2 高性能 Voter、1 低性能 Learner）并全局绑定

sql

SET GLOBAL tidb_enable_alter_placement=1;
CREATE PLACEMENT POLICY bal
FOLLOWERS=2,CONSTRAINTS='[+perf=high]',LEARNER_CONSTRAINTS='[+perf=low]';
ALTER GLOBAL SET PLACEMENT POLICY bal;

4. 调低 D 存储权重：pd-ctl store <D-store-id> weight 5