跳转至原帖查看：https://asktug.com/t/topic/573232
【 TiDB 使用环境】
【概述】：场景 + 问题概述
集群环境如下图
其中117，124，125在沈阳，27在顺义，187在北研（27，187这两台是新加节点）这5台虚机组成两地三中心（北研、顺义都在北京），我加的配置如下
然后重新reload，完成后，有几个小疑问：
1，reload后，在edit-config查看时，发现server.labels:中的顺序发生了变化，如下：
我们在配置时写的顺序是：server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang2”, host: “124” }
不知道这发生变化后是否有影响？
2，如果配置成5副本，那tikv按什么打labels呢？这里tidb是如何来判断的呢？
replication.location-labels: [“dc”,“zone”,“rack”,“host”]
server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang1”, host: “124” }
server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang2”, host: “125” }
server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang3”, host: “117” }
server.labels: { dc: “beiyan”, zone: “beiyan”, rack: “beiyan1”, host: “187” }
server.labels: { dc: “shunyi”, zone: “shunyi”, rack: “shunyi1”, host: “27” }
是先按dc判断，发现有三个dc，做不了5副本，然后再按zone判断，发现也是三个，做不了5副本，再按rack判断，发现可以做5副本，然后就按rack为打label了，是这样的吗？还是tikv在打label时有其他判断方法？
3，我们reload后，发现不生效
我们禁用中心（顺义机房）的 Raft leader 的调度，所以27上的leader_count为0，是正常的，但是所有节点的region_count数量不对，按咱们配置中，是3副本，那27上region_count数量应该是等于117、124、125三个节点上的region_count之和才对，（那187上region_count数量也应该是等于117、124、125三个节点上的region_count之和），但现在是均分的。
这是什么原因造成的呢？
【背景】：做过哪些操作
【现象】：业务和数据库现象
【问题】：当前遇到的问题
【业务影响】：
【TiDB 版本】：
v5.2.2
【附件】：
- 相关日志
- 配置文件
- Grafana 监控（https://metricstool.pingcap.com/)【 TiDB 使用环境】
【概述】：场景 + 问题概述
集群环境如下图
其中117，124，125在沈阳，27在顺义，187在北研（27，187这两台是新加节点）这5台虚机组成两地三中心（北研、顺义都在北京），我加的配置如下然后重新reload，完成后，有几个小疑问：
1，reload后，在edit-config查看时，发现server.labels:中的顺序发生了变化，如下：
我们在配置时写的顺序是：server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang2”, host: “124” }
不知道这发生变化后是否有影响？2，如果配置成5副本，那tikv按什么打labels呢？这里tidb是如何来判断的呢？
replication.location-labels: [“dc”,“zone”,“rack”,“host”]server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang1”, host: “124” }
server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang2”, host: “125” }
server.labels: { dc: “shenyang”, zone: “shenyang”, rack: “shenyang3”, host: “117” }server.labels: { dc: “beiyan”, zone: “beiyan”, rack: “beiyan1”, host: “187” }
server.labels: { dc: “shunyi”, zone: “shunyi”, rack: “shunyi1”, host: “27” }
是先按dc判断，发现有三个dc，做不了5副本，然后再按zone判断，发现也是三个，做不了5副本，再按rack判断，发现可以做5副本，然后就按rack为打label了，是这样的吗？还是tikv在打label时有其他判断方法？3，我们reload后，发现不生效
我们禁用中心（顺义机房）的 Raft leader 的调度，所以27上的leader_count为0，是正常的，但是所有节点的region_count数量不对，按咱们配置中，是3副本，那27上region_count数量应该是等于117、124、125三个节点上的region_count之和才对，（那187上region_count数量也应该是等于117、124、125三个节点上的region_count之和），但现在是均分的。
这是什么原因造成的呢？【背景】：做过哪些操作
【现象】：业务和数据库现象
【问题】：当前遇到的问题
【业务影响】：
【TiDB 版本】：
v5.2.2
【附件】：- 相关日志
- 配置文件
- Grafana 监控（https://metricstool.pingcap.com/)
