https://docs.pingcap.com/zh/tidb/stable/schedule-replicas-by-topology-labels#%E5%9F%BA%E4%BA%8E%E6%8B%93%E6%89%91-label-%E7%9A%84-pd-%E8%B0%83%E5%BA%A6%E7%AD%96%E7%95%A5
11 Contributors
 
注意

TiDB 在 v5.3.0 中引入了 Placement Rules in SQL。使用该功能,你可以更方便地配置表和分区的位置。在未来版本中,Placement Rules in SQL 可能取代通过 PD 配置放置规则的功能。

为了提升 TiDB 集群的高可用性和数据容灾能力,我们推荐让 TiKV 节点尽可能在物理层面上分散,例如让 TiKV 节点分布在不同的机架甚至不同的机房。PD 调度器根据 TiKV 的拓扑信息,会自动在后台通过调度使得 Region 的各个副本尽可能隔离,从而使得数据容灾能力最大化。

要让这个机制生效,需要在部署时进行合理配置,把集群的拓扑信息(特别是 TiKV 的位置)上报给 PD。阅读本章前,请先确保阅读 TiUP 部署方案

根据集群拓扑配置 labels

设置 TiKV 和 TiFlash 的 labels

TiKV 和 TiFlash 支持在命令行参数或者配置文件中以键值对的形式绑定一些属性,我们把这些属性叫做标签 (label)。TiKV 和 TiFlash 在启动后,会将自身的标签上报给 PD,因此可以使用标签来标识 TiKV 和 TiFlash 节点的地理位置。

比如集群的拓扑结构分成四层:机房 (zone) -> 数据中心 (dc) -> 机架 (rack) -> 主机 (host),就可以使用这 4 个标签来设置 TiKV 和 TiFlash 的位置。

使用命令行参数的方式启动一个 TiKV 实例:

tikv-server --labels zone=<zone>,dc=<dc>,rack=<rack>,host=<host>

使用配置文件的方式:

[server] [server.labels] zone = "<zone>" dc = "<dc>" rack = "<rack>" host = "<host>"

TiFlash 支持通过 tiflash-learner.toml (tiflash-proxy 的配置文件)的方式设置 labels:

[server] [server.labels] zone = "<zone>" dc = "<dc>" rack = "<rack>" host = "<host>"

设置 TiDB 的 labels(可选)

如果需要使用 Follower Read 的优先读同一区域副本的功能,需要为 TiDB 节点配置相关的 labels

TiDB 支持使用配置文件的方式设置 labels

[labels] zone = "<zone>" dc = "<dc>" rack = "<rack>" host = "<host>"
 
注意

目前,TiDB 依赖 zone 标签匹配选择同一区域的副本。如果需要使用此功能,需要在 PD location-labels 配置中包含 zone,并在 TiDB、TiKV 和 TiFlash 设置的 labels 中包含 zone。关于如何设置 TiKV 和 TiFlash 的 labels,可参考设置 TiKV 和 TiFlash 的 labels

设置 PD 的 location-labels 配置

根据前面的描述,标签可以是用来描述 TiKV 属性的任意键值对,但 PD 无从得知哪些标签是用来标识地理位置的,而且也无从得知这些标签的层次关系。因此,PD 也需要一些配置来使得 PD 理解 TiKV 节点拓扑。

PD 上的配置叫做 location-labels,是一个字符串数组。该配置的每一项与 TiKV labels 的 key 是对应的,而且其中每个 key 的顺序代表不同标签的级别关系(从左到右,隔离级别依次递减)。

location-labels 没有默认值,你可以根据具体需求来设置该值,包括 zonerackhost 等等。同时,location-labels 对标签级别的数量也没有限制(即不限定于 3 个),只要其级别与 TiKV 服务器的标签匹配,则可以配置成功。

 
注意
  • 必须同时配置 PD 的 location-labels 和 TiKV 的 labels 参数,否则 PD 不会根据拓扑结构进行调度。
  • 如果你使用 Placement Rules in SQL,只需要配置 TiKV 的 labels 即可。Placement Rules in SQL 目前不兼容 PD location-labels 设置,会忽略该设置。不建议 location-labels 与 Placement Rules in SQL 混用,否则可能产生非预期的结果。

你可以根据集群状态来选择不同的配置方式:

  • 在集群初始化之前,可以通过 PD 的配置文件进行配置:

    [replication] location-labels = ["zone", "rack", "host"]
  • 如果需要在 PD 集群初始化完成后进行配置,则需要使用 pd-ctl 工具进行在线更改:

    pd-ctl config set location-labels zone,rack,host

设置 PD 的 isolation-level 配置

在配置了 location-labels 的前提下,用户可以还通过 isolation-level 配置来进一步加强对 TiKV 集群的拓扑隔离要求。假设按照上面的说明通过 location-labels 将集群的拓扑结构分成三层:机房 (zone) -> 机架 (rack) -> 主机 (host),并对 isolation-level 作如下配置:

[replication] isolation-level = "zone"

当 PD 集群初始化完成后,需要使用 pd-ctl 工具进行在线更改:

pd-ctl config set isolation-level zone

其中,isolation-level 配置是一个字符串,需要与 location-labels 的其中一个 key 对应。该参数限制 TiKV 拓扑集群的最小且强制隔离级别要求。

 
注意

isolation-level 默认情况下为空,即不进行强制隔离级别限制,若要对其进行设置,必须先配置 PD 的 location-labels 参数,同时保证 isolation-level 的值一定为 location-labels 中的一个。

使用 TiUP 进行配置(推荐)

如果使用 TiUP 部署集群,可以在初始化配置文件中统一进行 location 相关配置。TiUP 会负责在部署时生成对应的 TiKV、PD 和 TiFlash 配置文件。

下面的例子定义了 zone 和 host 两层拓扑结构。集群的 TiKV 和 TiFlash 分布在三个 zone,z1、z2 和 z3。每个 zone 内有四台主机,z1 两台主机分别部署两个 TiKV 实例,另外两台分别部署一个 TiFlash 实例,z2 和 z3 其中两台主机分别部署一个 TiKV 实例,另外两台分别部署一个 TiFlash 实例。以下例子中 tikv-n 代表第 n 个 TiKV 节点的 IP 地址,tiflash-n 代表第 n 个 TiFlash 节点的 IP 地址。

server_configs: pd: replication.location-labels: ["zone", "host"] tikv_servers: # z1 - host: tikv-1 config: server.labels: zone: z1 host: h1 - host: tikv-2 config: server.labels: zone: z1 host: h1 - host: tikv-3 config: server.labels: zone: z1 host: h2 - host: tikv-4 config: server.labels: zone: z1 host: h2 # z2 - host: tikv-5 config: server.labels: zone: z2 host: h1 - host: tikv-6 config: server.labels: zone: z2 host: h2 # z3 - host: tikv-7 config: server.labels: zone: z3 host: h1 - host: tikv-8 config: server.labels: zone: z3 host: h2 tiflash_servers: # z1 - host: tiflash-1 learner_config: server.labels: zone: z1 host: h3 - host: tiflash-2 learner_config: server.labels: zone: z1 host: h4 # z2 - host: tiflash-3 learner_config: server.labels: zone: z2 host: h3 - host: tiflash-4 learner_config: server.labels: zone: z2 host: h4 # z3 - host: tiflash-5 learner_config: server.labels: zone: z3 host: h3 - host: tiflash-6 learner_config: server.labels: zone: z3 host: h4

详情参阅 TiUP 跨数据中心部署拓扑

 
注意

如果你未在配置文件中配置 replication.location-labels 项,使用该拓扑配置文件部署集群时可能会报错。建议在部署集群前,确认 replication.location-labels 已配置。

基于拓扑 label 的 PD 调度策略

PD 在副本调度时,会按照 label 层级,保证同一份数据的不同副本尽可能分散。

下面以上一节的拓扑结构为例分析。

假设集群副本数设置为 3 (max-replicas=3),因为总共有 3 个 zone,PD 会保证每个 Region 的 3 个副本分别放置在 z1/z2/z3,这样当任何一个数据中心发生故障时,TiDB 集群依然是可用的。

假如集群副本数设置为 5 (max-replicas=5),因为总共只有 3 个 zone,在这一层级 PD 无法保证各个副本的隔离,此时 PD 调度器会退而求其次,保证在 host 这一层的隔离。也就是说,会出现一个 Region 的多个副本分布在同一个 zone 的情况,但是不会出现多个副本分布在同一台主机。

在 5 副本配置的前提下,如果 z3 出现了整体故障或隔离,并且 z3 在一段时间后仍然不能恢复(由 max-store-down-time 控制),PD 会通过调度补齐 5 副本,此时可用的主机只有 4 个了,故而无法保证 host 级别的隔离,于是可能出现多个副本被调度到同一台主机的情况。

但假如 isolation-level 设置不为空,值为 zone,这样就规定了 Region 副本在物理层面上的最低隔离要求,也就是说 PD 一定会保证同一 Region 的副本分散于不同的 zone 之上。即便遵循此隔离限制会无法满足 max-replicas 的多副本要求,PD 也不会进行相应的调度。例如,当前存在 TiKV 集群的三个机房 z1/z2/z3,在三副本的设置下,PD 会将同一 Region 的三个副本分别分散调度至这三个机房。若此时 z1 整个机房发生了停电事故并在一段时间后(由 max-store-down-time 控制,默认为 30 分钟)仍然不能恢复,PD 会认为 z1 上的 Region 副本不再可用。但由于 isolation-level 设置为了 zone,PD 需要严格保证不同的 Region 副本不会落到同一 zone 上。此时的 z2 和 z3 均已存在副本,则 PD 在 isolation-level 的最小强制隔离级别限制下便不会进行任何调度,即使此时仅存在两个副本。

类似地,isolation-level 为 rack 时,最小隔离级别便为同一机房的不同 rack。在此设置下,如果能在 zone 级别保证隔离,会首先保证 zone 级别的隔离。只有在 zone 级别隔离无法完成时,才会考虑避免出现在同一 zone 同一 rack 的调度,并以此类推。

总的来说,PD 能够根据当前的拓扑结构使得集群容灾能力最大化。所以如果用户希望达到某个级别的容灾能力,就需要根据拓扑结构在对应级别提供多于副本数 (max-replicas) 的机器。同时 TiDB 也提供了诸如 isolation-level 这样的强制隔离级别设置,以便更灵活地根据场景来控制对数据的拓扑隔离级别。

[转帖]通过拓扑 label 进行副本调度的更多相关文章

  1. [转帖]Linux的进程线程及调度

    Linux的进程线程及调度 本文为作者原创,转载请注明出处:https://www.cnblogs.com/leisure_chn/p/10393707.html 本文为宋宝华<Linux的进程 ...

  2. Kubernetes集群调度器原理剖析及思考

    简述 云环境或者计算仓库级别(将整个数据中心当做单个计算池)的集群管理系统通常会定义出工作负载的规范,并使用调度器将工作负载放置到集群恰当的位置.好的调度器可以让集群的工作处理更高效,同时提高资源利用 ...

  3. Kubernetes K8S之调度器kube-scheduler详解

    Kubernetes K8S之调度器kube-scheduler概述与详解 kube-scheduler调度概述 在 Kubernetes 中,调度是指将 Pod 放置到合适的 Node 节点上,然后 ...

  4. k8s之list-watch机制、节点调度以及亲和性

    k8s之list-watch机制.节点调度以及亲和性 目录 k8s之list-watch机制.节点调度以及亲和性 一.list-watch机制 1. list-watch介绍 2. list-watc ...

  5. kubernetes 调度器

    调度器 kube-scheduler 是 kubernetes 的核心组件之一,主要负责整个集群资源的调度功能,根据特定的调度算法和策略,将 Pod 调度到最优的工作节点上面去,从而更加合理.更加充分 ...

  6. K8S群集调度器

    目录: 调度约束 Pod启动典型创建过程 调度过程 Predicate常见的算法 常见的优先级选项 指定调度节点 亲和性 键值运算关系 Pod亲和性和反亲和性 污点和容忍 污点 容忍 其他注意事项 c ...

  7. STORM_0009_Lifecycle-of-a-topology/拓扑的生命周期

    http://storm.apache.org/releases/1.0.1/Lifecycle-of-a-topology.html STORM拓扑的生命周期   本页的内容基于0.7.1代码,后来 ...

  8. YARN label 特性 & 指定队列及label提交任务

    以下基于 hadoop版本 hadoop-2.8.4 给各个节点打标签 yarn rmadmin -addToClusterNodeLabels fastcpu,normal # 是否独占默认是tru ...

  9. # kubernetes调度之nodeName与NodeSelector

    系列目录 Kubernetes的调度有简单,有复杂,指定NodeName和使用NodeSelector调度是最简单的,可以将Pod调度到期望的节点上. 本文主要介绍kubernetes调度框架中的No ...

  10. 深入kubernetes调度之NodeSelector

    Kubernetes的调度有简单,有复杂,指定NodeName和使用NodeSelector调度是最简单的,可以将Pod调度到期望的节点上. 1 NodeNamePod.spec.nodeName用于 ...

随机推荐

  1. [Python急救站]回文数的判断

    回文数判断:回文数是指这个数颠倒后,与原数一致,如32223.12221等. 第一个程序是由用户输入,并判断是否是回文数. a = eval(input("请输入一个五位数")) ...

  2. Langchain-Chatchat项目:1.1-ChatGLM2项目整体介绍

      ChatGLM2-6B是开源中英双语对话模型ChatGLM-6B的第2代版本,引入新的特性包括更长的上下文(基于FlashAttention技术,将基座模型的上下文长度由ChatGLM-6B的2K ...

  3. 问鼎CodeXGLUE榜单,华为云UniXcoder-VESO-v1算法取得突破

    摘要:华为云PaaS技术创新团队基于UniXcoder模型,在公开测试数据集(CodeXGLUE)上的代码搜索任务评测结果上取得突破,在CodeXGLUE榜单上排名中第一. 本文分享自华为云社区< ...

  4. 一文搞定Matplotlib 各个示例丨建议收藏

    摘要:Matplotlib 是 Python 的绘图库. 它可与 NumPy 一起使用 ,Matplotlib也是深度学习的常用绘图库,主要是将训练的成果进行图形化,因为这样更直观,更方便发现训练中的 ...

  5. 加快云原生技术转型, 智能调度登陆华为云DevOps: 增速,节源

    摘要:本文将探讨智能资源调度在华为云DevOps上的应用与实践. 本文分享自华为云社区<加快云原生技术转型, 智能调度登陆华为云DevOps: 增速,节源>,作者: DevAI. 1. 背 ...

  6. 分享两个常见的搜索算法:BFS和DFS

    摘要:本文为大家分享两个常见的搜索算法:BFS和DFS. 本文分享自华为云社区<BFS和DFS算法初探>,作者: ayin. 本次分享两个常见的搜索算法: 1.BFS 即广度优先搜索 2. ...

  7. XEngine:深度学习模型推理优化

    摘要:从显存优化,计算优化两个方面来分析一下如何进行深度学习模型推理优化. 本文分享自华为云社区<XEngine-深度学习推理优化>,作者: ross.xw. 前言 深度学习模型的开发周期 ...

  8. 字节跳动开源数据集成引擎 BitSail 的演进历程与能力解析

    导读 BitSail 是字节跳动开源数据集成引擎,支持多种异构数据源间的数据同步,并提供离线.实时.全量.增量场景下全域数据集成解决方案,目前支撑了字节内部和火山引擎多个客户的数据集成需求.经过字节跳 ...

  9. Axure 元件--基本元件

    图片:导入图看,根据图片实际大小显示,双击方框,再导入,根据控件的大小来显示图片 热区:1:增加锚点,制作点击事件:2:放在页面下方,控制滚动位置,比如其它控件在交互事件中找到它的坐标. 动态面版:交 ...

  10. .Net Core 多语言

    StartUp.cs public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseEndpoint ...