TiDB 扩容过程中 PD 生成调度的原理及常见问题丨TiDB 扩缩容指南(一)

导读

作为一个分布式数据库,扩缩容是 TiDB 集群最常见的运维操作之一。本系列文章,我们将基于 v7.5.0 具体介绍扩缩容操作的具体原理、相关配置及常见问题的排查。

通常,我们根据当前资源状态来决定是否需要调整 TiKV 节点的规模,无论是增加还是减少节点。我们希望在调整后,集群能够通过重新调度尽快实现所有在线 TiKV 节点资源的平衡利用。

因此对于扩缩容来说,我们主要关心的还是以下两点:

  • 资源均衡调度指令产生速度(PD 上调度产生的速度 )
  • 资源均衡调度指令执行速度(TiKV 间数据搬迁的速度)

本系列文章将围绕以上两个逻辑,重点介绍扩缩容过程中的核心模块及常见问题,分为以下几个部分:

  • 扩缩容调度生成原理及常见问题:
    • 扩容过程中调度生成原理及常见问题
    • 缩容过程中调度生成原理及常见问题
  • 扩缩容过程调度执行(TiKV 副本搬迁)的原理及常见问题

本文我们将重点介绍 TiDB 扩容过程中 PD 生成调度的原理和常见问题,希望能够帮助大家更好地理解和运维 TiDB。


扩容过程中 PD 生成调度的原理及常见问题

一般的,当集群中 TiKV 资源跑到 75% 左右时,一般的调优手段无法解决资源使用上的瓶颈,此时,我们就需要通过 添加 tikv 节点的方式,来提高集群的整体性能。

通过加节点的方式增加集群相关资源

如图,当集群只有 三个 tikv 时,能够使用的存储、CPU 、 memory 到达使用瓶颈时,我们可以通过加节点的方式增加集群相关资源。下面我们简单来看一下,三 tikv 节点下,增加一个 tikv 节点时,TiDB 集群是如何让新节点的物理资源能够被集群使用起来的。首先在三个 TiKV 节点的集群中,在我们 PD 的统一调度下,会尽量将三个 tikv 节点的资源得到均衡使用。

三个 tikv 节点的资源得到均衡使用

新加入一个节点时,PD 会慢慢的将相关数据以 Region 为单位迁移到新节点上,以充分使用新节点的 存储、memory 和 CPU 等资源。这当中最重要也是最耗时的就是将 Region 的副本数据从老节点搬迁到新节点上。如下图,PD 将 Region 1 的其中一个副本从 store-3 搬迁到了新节点 store-4 上,这个过程我们叫 balance-region.

balance-region

Balance region 具体步骤

Balance region 以 region 为单位执行,由 PD 计算需要搬迁的 region, 由 TiKV 执行。具体执行过程,简单的来说,主要分为以下三个步骤:

  1. 新节点上新增副本 learner 节点(leaner 节点不参与投票过程)。
  2. 将新节点的 learner 角色和老节点的 follower 角色互换
  3. 将老节点上的副本(learner) 删除以上步骤最终会变成一条条调度指令,下发给 KV 去执行,下面我们来看每个调度指令是如何从进行的:

Step1: Add learner

Add learner

  1. PD 中 balance-region-scheduler 生成balance-region operator, 制定具体执行步骤。
  2. PD 通过心跳的方式,告诉 leader 节点执行 add learner peer 操作
  3. Leader 所在节点在这个 Region 的 raft-group 里面广播这个消息,并最终从 leader 上生成 snapshot 发送给 store-4 , 添加 learner 节点完成。
  4. Leader 收到来自 learner 的消息,上报心跳给 PD 告知 add learner 这一步骤执行成功

Step2: Switch role

store-4 上的 learner 节点虽然有完整的数据,但不参与投票过程。我们期望是将 store-3 上的 follower 迁移到 store-4 上,因此,在这一步骤,我们会将 store-4 和 store-3 上的副本的角色互换,最终 store-3 上的老副本会变成 learner, 而新节点上的副本角色变成 voter 也就是 follower.这个过程为了保证数据的安全性,实际情况分为两条调度指令执行。

Switch role

具体执行步骤为:

  1. PD 通过心跳知道 learner 添加成功后,发送角色互换的指导给 leader 节点
  2. Leader 节点在 raft-group 里面广播消息
  3. 所有副本收到该心跳后,更新自己的配置。至此,该 raft-group 完成角色互换的配置更新。

这个过程因为只涉及逻辑变更,很快,也很难出问题。

Step3: Remove old peer

经过步骤 2,store-4 上已经有一个 follower, 且已经不会有数据访问到 store-3 上的 learner, 因此我们可以安全的删除这个副本。具体执行步骤如下:

  1. PD 发送心跳给 leader, 告知删除 store-3 上的副本
  2. Leader 在当前 region 的 raft-group 里面广播这个消息
  3. 所有副本在收到这个消息后,更新自己的配置信息,而 store-3 则会将自己这个副本完全删除。

Remove old peer

PD 上关键日志

以上过程,我们可以从 PD 的日

相关推荐

TiDB 可观测性解读(二)丨算子执行信息性能诊断案例分享

通常我们可以用 explain analyze 语句获得算子执行信息。explain analyze 会实际执行对应的 SQL 语句,同时记录其运行时信息,和执行计划一并返回出来,记录的信息包括: actRows 、 execution info 、 memory 、 disk。不同算子的 execution info 可以通过 TiDB 文档 ( https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze )了解。

TiDB_PingCAP 的博客 1020

TiDB × AI :DeepSeek 时代你需要什么样的数据基座

AutoFlow 是一套 GraphRAG 框架,不仅提供了类似于 LlamaIndex 的能力,而且还内置语义化的知识图谱构建和召回,以及我们在 AutoFlow 上实践得出的一系列行之有效的领先的 RAG 能力(这些接下来会介绍)。不过需要强调的是,Dify 是一个开箱即用的非常易用的界面,而 AutoFlow 虽然功能更强却则具有比较高的使用门槛,所以这两个选择其实面向了不同的群体,用户需要依据自己的实际需求进行选择。它并非传统的基于规则的优化工具,而是利用大模型的知识来优化不同类型的数据库。

TiDB_PingCAP 的博客 1417

架构师必看!现代应用架构发展趋势与数据库选型建议丨TiDB vs MySQL 专题(一)

随着业务系统数据量的增长,早起只能无奈采取分库分表方案以及架构,这不单为运维带 来了极高的复杂度,同时对业务开发也带来的极大的入侵,SQL 只能限定按照 shard key 维度进行编写,无法任意维度的进行 SQL 查询,开发不得不牺牲业务需求,业务的发展也不得不受限,同时又需投入大量的高精尖人才进行开发维护。这对数据库的承载能力提出了极高的挑战,不但需要承载大数据量,又需要保障业务读写性能的稳定性,而在数据的承载能力上,MySQL 的极限,是 TiDB 的起点。一行命令完成扩展,无需任何的人工干预。

TiDB_PingCAP 的博客 1233

TiDB 观测性解读(一)丨索引观测:快速识别无用索引与低效索

通过识别并优化未使用或低效的索引,可以减少资源浪费,并提高系统的响应速度和稳定性。在 TiDB 中,TIDB_INDEX_USAGE 系统表提供了相对丰富的索引使用统计数据,帮助 DBA 快速发现低效索引,并通过优化或删除它们来提升数据库效率。尽管删除索引的操作相对简单,但在实施时仍需注意潜在的限制和风险,尤其是在大数据量和高并发环境下。定期检查索引使用情况,尤其是对于大规模数据库。确保用于决策的统计数据涵盖足够长的业务周期,避免误判。

TiDB_PingCAP 的博客 973

海量数据融合互通丨TiDB 在安徽省住房公积金监管服务平台的应用实践

目前安徽省住房公积金监管服务平台已具备一系列功能模块,包括首页、运营分析、统计报表、智慧大屏、数据治理、风险检查和系统管理。其中,运营分析主要用于从不同维度分析公积金业务指标,统计报表则负责生成、填报和查询住建部规定的报表,同时也支持省级用户的报表导入、核对和更新。智慧大屏提供了综合和业务两大类可视化展示,而数据治理模块则涵盖了传数统计、数据检核和人工数据核对等功能,以确保数据的质量。风险检查方面,平台不仅支持公积金中心的自我检查,也支持省厅的检查,并可以根据需要添加新的检查模型。

TiDB_PingCAP 的博客 1133

TiDB 2024 年度报告:增长的故事

TiDB 2024 年度报告:增长的故事

TiDB_PingCAP 的博客 328

TiDB Chat2Query 深度解析:我们如何打造一款更高效、准确的智能 SQL 生成工具?

上个季度的销售额是多少?“哪个产品类别表现最佳?“本月客户投诉的趋势如何?相比其他工具,Chat2Query 能够对用户上传的大规模数据集进行理解和分析, 摒弃繁杂的专业术语和查询语句,Chat2Query 使得用户能够通过自然语言直接向数据库提问,并即时获得答案。

TiDB_PingCAP 的博客 1335

4.98 亿月活背后的国产数据库:咪咕视讯携手 TiDB 攻克内容分发核心系统挑战

咪咕大概是 2018 年左右正式开始对分布式数据库进行研究的,到现在为止我们看到和测试过太多的国内产品。但是在当时,敢用 LSM 树而不是 B+ 树做存储引擎,敢做分布式存算引擎分离的,能够行列副本共存、优化器路由分流做 MPP shuffle 的,市面上真的真的非常非常地不多见。比较多的是精致的分库分表外挂,或某些知名国外产品的模仿版。TiDB 的产品给我的印象是极具冲击性的,那么大胆、不随大流。验证和使用下来,效果也是切实的。

TiDB_PingCAP 的博客 1200

53 倍性能提升!TiDB 全局索引如何优化分区表查询?

在 TiDB 中,全局索引是一种定义在分区表上的索引类型,它允许索引分区与表分区之间建立一对多的映射关系,即一个索引分区可以对应多个表分区。这与 TiDB 早期版本中的本地索引(Local Index)不同,本地索引的索引分区与表分区之间是一对一的映射关系,即一个分区对应一个局部的索引块。全局索引能覆盖整个表的数据,使得主键和唯一键在不包含分区键的情况下仍能保持全局唯一性。此外,全局索引可以在一次操作中访问多个分区的索引数据,而无需对每个分区的本地索引逐一查找,显著提升了针对非分区键的查询性能。

TiDB_PingCAP 的博客 1356

一行代码不用写,用 Autoflow + Gitee AI 搭建本地知识库问答机器人

本文详解 AutoFlow 从部署到配置的完整流程,包括数据库连接、模型设置、知识库创建及聊天引擎配置,实现了一行代码不用写的问答机器人快速搭建。轻松上手,助力开发者探索智能问答解决方案。

TiDB_PingCAP 的博客 1046

TiDB 分布式数据库多业务资源隔离应用实践

本文将分享某客户在 TiDB 分布式数据库中实现多业务资源隔离的实践案例。

TiDB_PingCAP 的博客 1317

攻克多版本运维难题:爱奇艺百套 TiDB 集群升级至 v7.1.5 实战宝典来袭!

本文将深入探讨爱奇艺如何通过升级,成功将百套 TiDB 集群从多个旧版本升级至 v7.1.5,攻克多版本运维挑战,获得更稳更快的 TiDB 使用体验。

TiDB_PingCAP 的博客 1157

百亿大表的实时分析:华安基金 HTAP 数据库的选型历程与 TiDB 使用体验

明确需求:首先评估业务对 TP(事务处理)和 AP(分析处理)的需求比重,确定数据量、查询速度和响应时间,确保数据库能满足业务对实时性的要求。技术特性评估:考虑数据库的实时分析能力、可扩展性、高性能、安全性和灵活性,以支持业务人员实施的场景需求,特别是后台营销人员对数据实时性的需求。集成与兼容性:评估数据库与现有数据库、应用程序和其他关键系统的集成能力,确保数据同步策略的无缝实施。安全性与可靠性:重视数据库的安全性措施、容灾备份机制、数据恢复能力和错误处理机制,保障业务连续性和数据安全。

TiDB_PingCAP 的博客 1019

TiDB 的高可用实践:一文了解代理组件 TiProxy 的原理与应用

TiDB 是一款典型的分布式存算分离架构的数据库,其中计算层由多个无状态的 TiDB Server 组成,这些 TiDB Server 同时对外承担连接请求。为了可以将连接分发到多个 TiDB Server 节点上,一般需要借助外部负载均衡组件如硬件负载均衡 F5、软件负载均衡 HAProxy 等。为了实现全链路的高可用架构,我们经常也需要考虑负载均衡组件本身的高可用性,比如通过 KeepAlived 来保证 HAProxy 的高可用。

TiDB_PingCAP 的博客 1255

你需要什么样的资源隔离?丨TiDB 资源隔离最佳实践

通过本文的学习,相信大家对 TiDB 的资源隔离能力有了更全面的理解;大家可以根据不同的场景需求,选择合适的资源隔离方案。如果您有新的资源隔离需求或场景,欢迎与我们联系。

TiDB_PingCAP 的博客 1253

狂飙 50 倍丨TiDB DDL 框架优化深度解析

前面我们介绍了 TiDB DDL 任务的整体执行流程。接下来,让我们聚焦到在线 Schema 变更的细节上。执行单步变更:Job Worker 会根据任务定义,执行一次在线 Schema 的变更。每一次变更都代表着 Schema 向目标状态迈进了一步,即进入下一个状态,可能的状态包括 write-only 和 delete-only 等。状态更新:完成单步变更后,Job Worker 会将当前的 Schema 状态更新到元数据中。

TiDB_PingCAP 的博客 1202

唐刘:TiDB 的 2024 - Cloud、SaaS 与 AI

最后再说下产品,在今年,我们发布了TiDB 8.1和8.5两个版本。在 2025 年,我们会有一个重大的改变,就是会持续的投入到 8.5 版本的质量加固,同时收敛新功能的开发,只会在 2025 年发布一个有更高质量的 LTS 版本。关于 TiDB 8 系列,我后面再写一篇文章详细的介绍一下吧。在 2024 年,我们交付了非常不错的成果,当然,能取得这样的成绩,来自于我们不断地交付优异的产品,满足客户的需求,赢得客户的信任。

TiDB_PingCAP 的博客 1054

PingCAP 连续两年入选 Gartner 云数据库管理系统魔力象限“荣誉提及”

TiDB 凭借领先的 HTAP 架构设计,支持用户在云上的数据库中同时运行关键业务交易和实时分析任务,充分享受云的弹性优势和业务连续性优势,助力企业实现数据敏捷。PingCAP 是业界领先的企业级开源分布式数据库企业,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务,致力于为全球行业用户提供稳定高效、安全可靠、开放兼容的新型数据服务平台,解放企业生产力,加速企业数字化转型升级。

TiDB_PingCAP 的博客 702

TiDB 8.5 LTS 发版——支持无限扩展,开启 AI 就绪新时代

TiDB 8.5 扩展了Runaway Queries 的功能,新增“处理行数”和“用量(RU)”作为识别标准,实现更精确的识别,并允许将这些 Runaway Queries 放入一个资源可控的组中,确保在高负载环境下集群的稳定性。TiDB 8.5 通过实例级执行计划缓存功能,使得同一 TiDB 实例内的所有会话共享执行计划缓存,减少SQL编译时间,从而降低整体 SQL 运行时间,提高 OLTP 的性能和吞吐量,并有效地控制内存使用,提升数据库的稳定性。

TiDB_PingCAP 的博客 776

基于时间维度水平拆分的多 TiDB 集群统一数据路由/联邦查询技术的实践

通过该组件与 TiDB 分布式数据库的有效结合,可以实现近乎无容量上限的超大规模数据管理,尤其是对于重要程度高、吞吐量大、业务敏捷性强、数据冷热特征明显的业务系统。不仅能够支撑面向内外部客户业务无损的多维度、不受分片键制约的灵活高效访问,还可以有效控制和平衡单集群的负载、容量、资源利用率、稳定性等关键指标,在不增加过多复杂性的前提下实现更强的整体扩展能力。当然,组件的现有功能更多是聚焦在当前的客户场景,未来可以按需在功能性、易用性、高性能等方面进一步优化和提升。

TiDB_PingCAP 的博客 915

Rakuten 乐天积分系统从 Cassandra 到 TiDB 的选型与实战

Rakuten 乐天是一家成立于 1997 年的日本公司,总部位于东京,员工总数超过 30,000 人,业务遍及 100 多个国家和地区。除了电商业务外,乐天还涉及电信、金融等多个行业。乐天的积分系统在日本非常普及,用户通过使用乐天的服务,如银行卡、手机卡等,可以获得积分,并在乐天商城中使用这些积分进行购物或抵扣,我们每个季度还会举办促销活动、会有大量用户高频访问积分系统,因此,乐天积分服务平台的性能、延迟和可用性要求极高。

TiDB_PingCAP 的博客 1355

平凯星辰亮相开放原子开发者大会,TiDB 荣获年度活跃开源项目奖项

12 月 20 - 21 日,以“一切为了开发者”为主题的 2024 开放原子开发者大会暨首届开源技术学术大会在武汉成功举办。平凯星辰亮相本次大会,出品 AI 时代的数据库技术发展论坛,获评“校源行”优质开源课程合作单位。由平凯星辰创立的开源分布式数据库 TiDB 获评“2024 年度数据库领域国内活跃开源项目”,7 位 TiDB 开发者获评“2024 年度数据库领域国内活跃开源开发者”,彰显了 TiDB 在开源数据库领域的卓越影响力和社区活力。

TiDB_PingCAP 的博客 606

B 站数据库负责人赵月顺:助力海内外业务增长,百套 TiDB 的选型与运维实战

B 站的 TiDB 集群规模已达到 100 多套,计算节点超过 2000 个,存储节点超过 800 个。TiDB 的应用场景非常广泛,包括视频观看、一键三连、发送弹幕、撰写评论、阅读漫画以及视频后端的存储等。B 站的 TiDB 部署采取了存算分离的策略,计算节点被部署在容器中,这种做法的优势在于能够充分发挥容器化管理无状态服务达到水平弹性拓展能力,允许根据需求随时对计算节点进行扩展或缩减,整个过程仅需一次服务发版,有效提升了效率与灵活性。存储节点则继续部署在物理机上。

TiDB_PingCAP 的博客 1234

微众银行携手平凯星辰荣膺金融科技创新奖,共同打造纳管千台服务器的大规模数据库运维平台

在过去的十年中,平凯数据库在金融行业积累了丰富的实践经验,已经在国有大型银行的 PB 级别数据服务平台、头部商业银行的核心交易系统、头部保险公司的核心保单系统、头部证券公司的核心交易系统等领域,成功完成了对国外商业数据库和 MySQL 数据库的替换升级,部署了超过 1,000 套关键业务系统,集群节点总数超过了 10,000 个。为了应对这些挑战,同时满足金融行业对高可用、高可靠、高性能数据库的需求,微众银行开发了一套完整的运维体系,打造了大规模信创原生分布式数据库智能运维平台。

TiDB_PingCAP 的博客 804

知乎 PB 级别 TiDB 数据库集群管控实践

知乎的数据库团队以“致力于提供稳定、高效和易用的数据库服务”为目标,为公司业务团队提供更好的 TiDB 存储服务来应对高并发、复杂查询和大数据存储的需求。本文详细介绍了 TiDB 的生态架构,包括核心组件、数据迁移与同步、运维与监控平台、备份与恢复、生态集成、K8s 支持、工具集和安全与审计等方面。同时探讨了知乎如何在云上和云下环境中管控 TiDB 集群,以及如何通过自研的天穹平台实现数据库平台化建设,提升业务研发团队数据库变更和 DBA 团队的资源管控效率。

TiDB_PingCAP 的博客 1180

TiDB 优化器 | 执行计划管理及实践

本文深入解析了 TiDB 优化器的执行计划生成过程及其局限性,介绍了如何通过 Hint、SQL Binding、执行计划缓存等技术手段进行执行计划管理,确保查询性能的稳定性和高效性。

TiDB_PingCAP 的博客 1315

商业银行基于容器云的分布式数据库架构设计与创新实践

本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台,重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。通过引入 TiDB Operator 自动化管理与容器化技术,银行能够实现多个业务系统的高可用、弹性扩展与自动化运维,极大提高了运营效率与资源利用率。本文还详细阐述了平台架构设计、面临的技术挑战及创新解决方案,展示了 TiDB 在金融行业数字化转型中的应用前景。

TiDB_PingCAP 的博客 1360

PingCAP 荣膺 2024 亚马逊云科技合作伙伴两项殊荣

近日,在 2024 亚马逊云科技 re:Invent 全球大会上,PingCAP 荣膺亚马逊云科技年度技术合作伙伴和年度亚马逊云科技 Marketplace 合作伙伴两项殊荣。这是 PingCAP 连续第二年获得亚马逊云科技年度合作伙伴奖项,彰显了 PingCAP 在与亚马逊云科技合作服务客户的过程中所展现的卓越技术实力和专业服务能力,共同推动全球用户业务取得成功。

TiDB_PingCAP 的博客 569

基于 AutoFlow 快速搭建基于 TiDB 向量搜索的本地知识库问答机器人

通过本篇文章介绍,相信大家对使用 PingCAP 开源项目 AutoFlow 实现快速搭建基于 TiDB 的本地知识库问答机器人会有一个完整的了解。如果提前准备好 Docker、TiDB 环境,整个搭建过程估计在 10 分钟左右即可完成,无须开发任何代码。文中使用一篇 TiDB 文档作为本地数据源作为示例,在实际情况中,您可以基于自己的企业环境用同样的方法快速构造企业内部知识库问答机器人。

TiDB_PingCAP 的博客 1283

TiDB 关联子查询及半连接的优化实践

TiDB 针对子查询语句会执行多种子查询相关的优化,以提升子查询的执行性能。半连接语句和关联子查询语句是常用的两类子查询,TiDB 优化器默认包含一些自动优化策略,同时 TiDB 也提供额外的 HINT 用于影响优化器在特定场景下可以选择更高效的执行计划。本文针对半连接及关联子查询语句在 TiDB 中的用法及优化技巧进行说明。

TiDB_PingCAP 的博客 1405
上一篇: 基于 TiDB 资源管控 + TiCDC 实现多业务融合容灾测试
下一篇: 知乎 PB 级别 TiDB 数据库在线迁移实践
TiDB_PingCAP
TiDB_PingCAP 企业官方账号 企业官方账号
博客等级 码龄10年 2726粉丝 780原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值