看多地多中心部署方式问题请教

🪐 TiDB 技术问题
, , ,
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】
v4.0.10
【问题描述】
观看同城多中心和两地三中心一些问题请教：
1、同城多中心中的zone是逻辑可用区层级，这个具体什么意思，我按照主机、机架、机房、地区，然后理解的是zone代表不同的地区对吗？
2、两地三中心部署时，这个zone参数又放在dc的后面，按照我上面地区的理解，不应该在dc的前面嘛？
3、两地三中心文档中，本来规划的是10个tikv机器，每个机器上面有两个tikv实例，但是配置文件中不一样，按照配置文件，我理解的是IDC1中有2台tikv机器，每台上面是1个tikv实例，IDC2也是2台tikv机器，每个上面是1个tikv实例，IDC3只有1台tikv机器，机器上有1个tikv实例，是吧？
image
image1021×455 11.5 KB

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

这里其实表示的四个级别的 Label 。其代表含义并不参与到具体逻辑中。

tidb 最小调度单位为 region。默认每个 region 有 3 个副本（peer）。
打 label 后的调度原则是 同 region 下的 peer 尽量放在 第一个层级 大于等于 raft 副本数量的层级
层级顺序 从左至右
dc -> zone -> rack -> host
以上面的例子 pd 中的 replica 设置为 5 那么就会保证每个 region peer 放在 zone 1-5 中，这里后面的 rack 和 host 其实已经无意义。

如果 是默认 replica 数量 ：3 那么 就是 dc 标签起作用。但是其中一个 peer 具体再哪个 zone 上 是不一定的 。调度迁移时候也会基于此策略

详细可以参考如下例子
https://docs.pingcap.com/zh/tidb/stable/multi-data-centers-in-one-city-deployment#tikv-labels-简介

3

ok，好的，谢谢，其实也就是：
1、没有表示不同城市的标签，如：北京、上海；
2、数据中心dc其实就是最高层级的标签，不同的数据中心就是不同的标签；
3、可用区zone则是根据具体的副本数来的保证每个region副本都落在不同的zone中，保证高可用性：5个副本的话，就需要有5个zone，3个副本的话，3个zone；
4、rack则是表示机架，有几个机架，就有几个rack的标签；
5、host是主机编号，一般使用网段的最后一位来表示，如10.168.172.200，则host表示为200，如果这个主机上部署了两个tikv实例的话，则可分别用200-1和200-2来表示；
1、我5个副本3地3中心，并且每台tikv主机上部署两个tikv实例，是可以这么写的，是吧？
server.labels: {dc: “1”, zone: “1”, rack: “1”, host: “143-1”}
server.labels: {dc: “1”, zone: “2”, rack: “1”, host: “143-2”}
server.labels: {dc: “2”, zone: “3”, rack: “2”, host: “144-1”}
server.labels: {dc: “2”, zone: “4”, rack: “2”, host: “144-2”}
server.labels: {dc: “3”, zone: “5”, rack: “3”, host: “145”}
2、这个同城多中心，dc对应的label不应该是3嘛？还是说由zone的3个标记了，dc的label就无所谓了？

image
image988×588 16.7 KB

4

标签组合是可以随意组合的

譬如 只用 Host
或者 用 Zone + Host

省略的标签层级也就不考虑了 其分配规则了

你这里的 host 想来是要 单 host 多实例混部

PD 天生不会将同一个 region 的多个副本调度到同一个 TiKV 实例上，增加 Label 信息后，PD 不会将同一个 region 的多个副本调度到同一个 host 上，以避免单台服务器的宕机导致丢失多个副本。

根据上面的原则 host 143-1 和 143-2 应该都改写为 143

labal 的用意只是为了 方便 PD 去识别调度。不需要真实的按照 物理架构的 原信息进行填写

5

1、哦，好的，其实这些标签都是灵活选择、组合排序变换的，是吧？
2、现在机器不够嘛，我这边想要试一下在有2个地区是1个dc的1台tikv机器上部署两个tikv实例，还有1个地区是1个dc1台tikv机器，部署1个tikv实例，我想的是将副本1放到143-1实例上，副本2放到143-2实例上，副本3放到144-1实例上，副本4放到144-2实例上，副本5放到145实例上：
server.labels: {dc: “1”, rack: “1”, zone: “1”, host: “143-1”}
server.labels: {dc: “1”, rack: “1”, zone: “2”, host: “143-2”}
server.labels: {dc: “2”, rack: “2”, zone: “3”, host: “144-1”}
server.labels: {dc: “2”, rack: “2”, zone: “4”, host: “144-2”}
server.labels: {dc: “3”, rack: “3”, zone: “5”, host: “145”}
我是从这个单机多实例联想的一些参数：

image
image719×497 9.74 KB

辛苦啦

6

非常不建议将一个 region 的 两个副本有机会调度到一台 host 上。如果一台 HOST 挂掉将会使部分表出现 不可用的 情况 。因为其已不满足 raft 多数派的的策略（3 副本）

如果是 按照现在的 拓扑，应用到生产环境。 5 副本其实意义并不大，主要还是和 tikv 混部与 host 宕机风险有关。且 5 副本带来的更多的写负载与通信开销

7

嗯，好的，确实最好不要将多个tikv实例都部署到同一个tikv机器上，主要是现在，我现在自己模拟一下，机器不是很多的嘛:expressionless:，想深入了解这个标签的意义，以及组合排序方式的，所有想让您看看，是不是我配置的那样，辛苦您了，大爷大神:grin:

8

一般是 DC -> Zone -> Rack -> host

按照现在的 情况
如果是 3 副本可以使用
dc -> rack -> host
3副本 ->3 机房 ,dc 留作后续扩展先预留 ，host 务必填写
5 副本
zone -> rack -> host 即可

分级较多 时候 一定要注意之前说的 原则

按照 label 等级 ，region 副本存放会按照 从高到低的级别第一个不同标签名称数满足副本个数的标签级别进行路由存储

9

大神你好，我看了一下视频，这里的zone表示的是bj，代表地区的意思是吧？那么我这个3个地区，5副本的表示
上zone的取值应该是类似于bj，sh，js这种吧，然后用host来区分副本调度到不同的主机上，是吧

image
image715×280 68.9 KB

10

如果是 5 副本 在后续的集群发展下。如果 一个 zone 下 host 多与 5 台，有可能会导致部分region 都调度到同一个 zone 下 。这就失去了 两地三中心的意义

建议还是 通过学习文档 与 实地测试来加深理解
https://docs.pingcap.com/zh/tidb/stable/multi-data-centers-in-one-city-deployment#样例部署图

具体的 region 与 store 的 对应 可以通过 内部视图来判断验证下

https://docs.pingcap.com/zh/tidb/stable/information-schema-tikv-region-peers

11

好的，先谢谢啦，我再看看理解一下。。。:thinking:

12

:+1:

13

大佬您好，我最近又在重新研究这个多地多中心的部署，对于同城多数据中心里面的这句话没有理解清楚：这个扩容数据中心的话，按照官网上是这样子是吧：
tikv_servers:

  • host: 172.20.146.147
    config:
    server.labels: { zone: “z1”, dc: “d2”, rack: “r1”, host: “147” }
  • host: 172.20.146.148
    config:
    server.labels: { zone: “z2”, dc: “d2”, rack: “r1”, host: “148” }

那么我用三个标签不是直接这个样子就好了嘛？
tikv_servers:

  • host: 172.20.146.147
    config:
    server.labels: { dc: “d4”, rack: “r1”, host: “147” }
  • host: 172.20.146.148
    config:
    server.labels: { dc: “d4”, rack: “r1”, host: “148” }
    这个两者的具体区别是什么呢？
    image
    image1147×617 36.5 KB
14

都可以的，根据你自己的情况来设定，只要可以区分开就可以。

举个例子，如果类似 AWS 有多个region的不同 AZ，那么你可能还要加上 region 和 az 的标签，方便以后扩展。如果你只有一个同城，那你就按照自己的维度来定义就可以了。只要考虑到以后扩容的时候，方便就行。

15

ok，好的，谢谢，我在多问一下，这个扩容缩容数据中心的具体内容的操作流程是什么？
比如在数据中心1扩容一台tikv机器，应该就是在tikv节点上打上标签：
{ dc: “d1”, zone: “z4”, rack: “r4”, host: “148” }
扩容一个数据中心:
{ dc: “d4”, zone: “z4”, rack: “r4”, host: “148” }
这两者之间具体的扩容和缩容的内部工作流程什么？拜托指导一下，谢谢！辛苦您了！:thinking:

16

维度不同，host可能就是影响具体一个主机，dc 可能就会影响整个dc中的host。没什么区别，最后都是要在实例级别去扩缩容。

17

哦，好的，知道了，谢谢，官网上的意思其实是：按照官网上的打标签，扩容时，不涉及dc的变化，不会影响整个dc中的host，而只会影响扩容的哪台机器。而如果按照我的打标签方式的话，那么就用可能影响整个dc的机器是吧！
那么大佬，这个扩容和缩容的具体原理流程步骤，如：tikv、pd、tidb节点上先扩容什么组件，执行什么协议等等，这方面你有什么推荐看的文章嘛？辛苦您了！

18

搜下官方文档的tiup运维

19

好的，辛苦您了，谢谢。。。

20

:handshake: