https://tidb.net/book/tidb-monthly/2022/2022-04/usercase/tidb-cluster
由于各种场外因素导致我们不能自由选择的理想硬件环境，加之目前单台物理机的硬件配置往往都高于需求，为了更合理地规划资源，很多时候一台服务器不能够“奢侈地”只部署一个实例，而是会考虑单机多实例部署 TiDB 或者 TiKV。这就需要在现有的环境中尽可能地搭建满足高可用、高性能的TiDB集群。本文主要分享一次实际生产环境中混合部署TiDB集群的过程，供大家参考。
10台物理机，每台配置均为56C 384G 4块2TB NVME硬盘。监控、HA等机器使用虚拟机即可，因此不算在采购预算内。
配置达标，但是由于种种因素原本预计装一个集群的硬件需要混合部署2套集群。
集群1
| 实例 | IP |
|---|---|
| TiDB & PD | 10.0.0.1 |
| TiDB & PD | 10.0.0.2 |
| PD | 10.0.0.3 |
| 10.0.0.4 | |
| Tikv *2 | 10.0.0.5 |
| Tikv *2 | 10.0.0.6 |
| Tikv *2 | 10.0.0.7 |
| Tikv *2 | 10.0.0.8 |
| Tikv *2 | 10.0.0.9 |
| Tikv *2 | 10.0.0.10 |
集群2
| 实例 | IP |
|---|---|
| 10.0.0.1 | |
| PD | 10.0.0.2 |
| TiDB & PD | 10.0.0.3 |
| TiDB & PD | 10.0.0.4 |
| Tikv *2 | 10.0.0.5 |
| Tikv *2 | 10.0.0.6 |
| Tikv *2 | 10.0.0.7 |
| Tikv *2 | 10.0.0.8 |
| Tikv *2 | 10.0.0.9 |
| Tikv *2 | 10.0.0.10 |
如果拆解成单独的集群，他们的架构应该是这样
但是实际上是混合部署，那么他们的架构应该是这样
-1647272473002.jpg)
集群1拓扑tikv配置labels规划为：
集群2拓扑tikv配置labels规划为：
设置 PD 的 location-labels 配置：
location_labels = ["zone","rack","host"]
本次操作是想在目前服务器数量不变的情况下尽可能做到高可用，但是由于成本等多方面因素并没有选择异地容灾及同城多机房容灾方案，所以选择了该混合部署方案。
HA本身的可用性：
haproxy+keepalived实现ha的高可用。
PD server及TiDB server的可用性：
由于pd和tidb是混合部署的，所以这里放在一起说。10.0.0.1-10.0.0.0.4为2套集群tidb和pd混部，从架构图中可以看到，任意一台服务器宕机，都最多只影响一套集群内的一个tidb节点和一个pd节点。同一套集群内tidb节点仍有一个可用，pd节点剩余2副本，tidb和pd都满足高可用。
TiKV server的可用性：
为了在具有相近物理位置的 TiKV 上只放置一个副本，PD可以根据 TiKV 的物理位置进行最优调度以尽可能的提高 TiKV 集群的可用性。我们都知道 Raft Group 副本数选择为3的 TiKV 集群可以容忍一个节点宕机而不丢失数据且正常提供服务。一个集群同时有两个 TiKV 节点宕机可以通过合理规划让同时故障的两个 TiKV 出现在同一个隔离区的概率变高来提高可用性。本次部署同样选择为3副本，服务器10.0.0.5（host1）和 10.0.0.6（host2）在一个机柜，10.0.0.7（host3）和 10.0.0.8（host4）在一个机柜，10.0.0.9（host5）和 10.0.0.10（host6）在一个机柜，根据上面的规划，虽然一台服务器上有2套集群的各2个TiKV实例，但是PD知道哪些TiKV节点在同一台服务器上，也知道哪些服务器在同一个机柜上。PD 在副本调度时，会按照 label 层级，保证同一份数据的不同副本尽可能分散，至少能够保证任一服务器宕机2套集群的TiKV均可用。也可以设置isolation-level参数来进一步加强对 TiKV 集群的拓扑隔离要求。任一机柜故障后，例如10.0.0.5和10.0.0.6同时宕机，由于2套集群中这两台服务器都只存放一个副本，TiDB 集群依然是可用的。
第一次发文章，希望能对各位大佬有帮助，实际部署也是很早之前了，如果有不严谨或者纰漏的地方也请见谅。