平凯数据库

黄东旭解析 TiDB 的核心优势

Thu, 02 May 2024 10:10:31 +0800

“云原生”、“分布式”，近几年云原生概念热度不减，成为了许多开发人员关注的焦点。在 CNCF 云原生基金会数据库领域，PingCAP 已毕业的项目 TiKV 与 TiDB 帮助了很多企业解决了传统数据库遇到的瓶颈性问题。未来数据库领域还有哪些想象空间？分布式实验室特约记者 Marico 采访了 PingCAP 联合创始人兼 CTO 黄东旭，从 PingCAP 明星级产品优势、如何保障开源产品的活力等方面进行了交流。

Marico：TiDB 行式数据引擎 TiKV，目前也是在 CNCF 中也是一个极其优秀的项目。相较于 Redis 一类的 KV 存储，TiKV 具有哪些独特的优势？更加适用于哪些业务场景？

黄东旭：

（当时 TiKV 刚加入 CNCF 的时候我发的一条 Tweet）

其实我们一开始受到 Google Spanner 和 F1 的影响，目标是构建 TiDB，一个分布式/支持 ACID 事务能力以及超强的高可用的能力的 SQL 数据库（关系型数据库）。

Google 的存储系统有个特点：模块之间的边界划分是很清晰的，例如 F1 是无状态的 SQL 层，Spanner 是分布式存储层，我很喜欢这种设计思想，所以 TiDB 也沿袭了这个思路，根据 Spanner 的论文描述， Spanner 在早期是一个和 BigTable 类似的表格系统（类似 KV 的接口，虽然在后来 Spanner 本身也加入 SQL 的支持），TiKV 其实就是类似 Spanner/F1 的组合中的 Spanner 部分，TiKV 最大的特点和 Spanner 一样，支持透明的分布式事务，传统的 NoSQL 几乎都没有支持跨行事务的能力，但是对于构建一个关系型数据库（TiDB）来说，事务能力是至关重要的。

另外 TiKV 的一个特点是使用了 Raft 共识算法来做为内部数据分片的多副本复制，比起传统的主从复制，我认为基于 Raft 或者 Paxos 这样分布式共识算法能给数据库带来更好可用性。

题目中提到了 Redis，Redis 是一个内存数据库，对于数据的持久化和高可用其实并不太关注，所以通常作为缓存的场景（因为能接受数据的丢失），但是 TiKV 是支持持久化和强一致的，同时默认多副本（Redis 通常为了追求低延迟不会配置副本策略）。

我认为大多数分布式系统，如果有一个支持 ACID 事务的分布式存储，能够节省很多的工作量，例如你想要做一个分布式文件系统，那么你肯定需要一个元信息的存储（用于存放目录文件结构，inode 等元信息），这个元信息系统通常是整个项目对数据一致性和安全性最高的模块，而且通常也有水平扩展的需求，这时候如果使用 TiKV 这样的支持事务和高可用的分布式 KV 数据库就能极大的降低构建大型系统的复杂性。

Marico：相较于云厂商提供的数据库解决方案，TiDB 更具哪些优势？

黄东旭：从产品层面来说：

TiDB 是采用和 Spanner 类似的 Shared-nothing 的设计，这意味着对于读写来说都能很好的水平拓展，从小数据规模（<1TB）到超过 500TB 的超大规模集群我们都有生产环境的案例，能够证明 TiDB 的扩展能力。

TiDB 提供标准的 SQL，兼容 MySQL 协议，会让应用开发变得很简单，应用开发者不需要关心分布式系统复杂的细节，不需要关心数据分片，也不需要关心高可用，这些能力都是 TiDB 内置的

TiDB 内部提供一个名为 TiFlash 的存储引擎，TiFlash 的特点是：它是列式存储，开启这个存储引擎后，一些复杂的 SQL 查询会通过列存加速，所以 TiDB 能提供实时分析能力，另外和第二点类似，用户也不需要关心行-列之间的数据同步问题。

TiDB 对于部署环境是中立的，TiDB 也不同公有云，包括阿里云/AWS/GCP 上有托管服务，另外，对于用户来说，也可以自己部署。所以跨云，甚至跨云上云下的统一体验是重要的优势。

另外从社区层面来说，TiDB 拥有庞大的开源社区生态，使用一个数据库，我认为最重要是这个数据库的生态有没有生命力，例如：如果遇到了问题，是否在网上有足够多的资料？是否有活跃的用户社区？如果使用商业服务，背后是否有商业公司支持？这点我认为是 TiDB 很独特的优势。

Marico：计算与存储分离、内置化的分表分库，行式存储与列示存储，随着数据库承担着越来越繁重的任务，未来数据库还能给我们提供哪些想象呢？

黄东旭：我认为对于数据库，甚至所有基础软件来说，一个最重要的趋势是：对于应用开发者来说越来越自然。

题目中提到的，分库分表/行-列存储，我认为这些都是很不自然的概念，仔细想想，我作为一个应用开发者在开发应用逻辑，为什么需要我把明明就应该在一起的数据拆散（分库分表）？其实是因为过去的数据库技术已经不能适应现代应用的需求，这些问题应该由数据库层面解决，而不是将复杂度转嫁给应用开发者。用一个类比：在自动挡的汽车发明出来后，会开手动挡的司机就越来越少了。

所以根据这个方向去想，我认为高学习门槛的技术（尤其是和底层实现细节相关的），例如：数据库性能调优，故障诊断，索引优化……这些技术可能都会在未来的数据库中变得很简单。这方面我很看好数据库技术与 AI 的结合（AI4DB）。

Marico：PingCAP 现在着力在发展的是 ChaosMatrix，Chaos 混沌工程与 TiDB 的工程领域并不相同，为什么 PingCAP 会选择参与混沌工程赛道？

黄东旭：ChaosMesh 并不是主业，它其实本来就是我们构建 TiDB 的过程中开发的一个内部工具。我认为构建一个数据库，最难的地方不是在于如何做出来，而是在于如何证明做对了，所以质量保证体系对于任何数据库厂商都是一个非常重要课题，其中混沌工程是测试分布式系统常用的一个手段，所以我们为了测试 TiDB，就做了 ChaosMesh，后来发现这个东西好像也可以测测其他系统，而且市面上也缺乏一个云原生的，好用的混沌测试系统，看来看去好像还真没有 ChaosMesh 那么好用的，于是就开源出来了，也许能帮到别人，后来没想到那么受欢迎，还挺欣慰的。

Marico：Docs 文档对于贵司的产品进行了详细的概述，且列举了很多实际应用场景。我想知道 PingCAP 是如何进行产品文档的维护的？是否存在一定的准则规范？

黄东旭：是的，我觉得对于一个数据库来说，文档也是产品质量的一部分，所以要像对待代码一样对待文档，例如一个简单的例子，我们的文档都是和版本对应的，每个不同的版本都有对应的文档。而且作为一个开源软件，文档本身也应该是开源的，我们的文档的源码也都是完全托管在 GitHub 上，也有着自己的自动构建系统，另外有详细的贡献指南和规范：https://github.com/pingcap/docs-cn/blob/master/CONTRIBUTING.md

另外，由于 TiDB 本身是个国际化项目，英文和中文文档都是1:1对应的，而且多数时候都是先有英文文档，然后才有中文，这个也是一个比较特别的。

Marico：CNCF 一直以来也孵化了很多优秀的开源项目，PingCAP 作为常年活跃于 CNCF 的中国企业，对于云原生市场的发展较为关注，为什么云原生市场拥有这么大的魅力？

黄东旭：就像上面我提到的，云是一个极大降低开发者构建应用门槛的东西，它基本改变了开发者开发软件的模式，所以我认为是不亚于个人计算机普及的重要里程碑，而且对于数据库厂商来说，在云上提供服务是一个更加可以规模化的商业模式，以为：

云上的环境相比云下是更标准的，在服务过程中，能自动化的东西都会被自动化

云提供 Pay-as-you-go 的基础设施，让软件提供商真正变成轻资产的公司，加速服务交付的效率

云的定价和付费，相对云下是透明的，这也会提升商业化的效率

Marico：个人作为一个开发者，也使用了 GitHub 上贵司开源的很多优秀类库。但是我也发现，大多数类库都选用了 Apache 开源协议，为什么采用自由度较高的开源协议？对产品商业化会造成一定的阻碍么？

黄东旭：我认为对于数据库软件来说不会，我认为数据库软件商业化的终点会是云服务（DBaaS），开源用户其实是很好的潜在客户群体，另外用一个比喻：假设你是开饭店的，你应该不会认为所有自己买菜在家做菜的人都是你的障碍吧？

来源：分布式实验室公众号

黄东旭关于基础软件产品价值的思考

Thu, 02 May 2024 10:05:24 +0800

作者：PingCAP CTO 黄东旭

前几年偶尔会写一些关于 TiDB 产品功能解读的文章，TiDB 5.0 发了那么长时间了，也应该写一写了。我其实在多个场合里表达过我对于 5.0 的重视，这个版本可能是对于 TiDB 来说的 MySQL 5.x，熟悉 MySQL 生态的朋友肯定知道我在说什么，MySQL 5.x，尤其是 5.5~5.7 这几个重要的版本基本上为 MySQL 的快速扩张奠定了坚实的基础，也培养了一大批 MySQL 的用户和人才。

对我而言，TiDB 是一个绝佳的样本，在此之前，中国本土很少有这样从零到一做出来的开源基础软件产品，多数工程师和产品经理都是这些软件的“使用者”，更多的是构建业务系统，而 TiDB 让我们第一次得以“设计者”的视角参与其中：每一个功能特性的设置背后的思考，对基础软件产品的价值呈现，体验还是很不一样的，借着这篇文章写点感受，另外这个文章是春节前我在 PingCAP 内部给 Presales 和 PM 培训上的分享整理而成，不一定正确，仅供参考。

1我们做的事情，对于用户意味着什么？

要讲好基础软件的产品价值，首先要克服的第一个关卡：学会换位思考。其实 TiDB 每个版本都带着数十个的特性和修复，但是多数时候我们的 Release note 只是忠实的反映了 “我们做了什么”：

TiDB 4.0 GA 的 Release Note 截图

各位这里请不要理解错我的意思，这种类型的记录是很有必要存在的，但是仅有这个是远远不够的。例如在 TiDB 5.0 ~5.5 的版本里面，我们引入了 n 多的新特性：聚簇索引，异步提交事务模型，优化了 SQL 优化器，支持了 CTE，引入了锁视图和持续性能诊断工具，改进了热点调度器，降低了获取 TSO 的延迟，引入 Placement Rules SQL…这些名字在 TiDB 的开发者看来是没问题的，但是请注意，更重要的问题是：这些对于用户（客户）意味着什么？

要回答这个问题的思路有两种，我分别讲讲：

通过一个假想的目标场景，然后通过产品去满足这个场景来展现价值。

解决现有的方案（包括自己的老版本）那些最恼人的问题来展现价值。

对于第一种思路，通常适用于比较新的特性，尤其是一些过去从来没有的新鲜东西。用一个比较好理解的例子：假如大家都在开马车的时候，你发明了一个汽车，这时候如果你以汽车解决了马儿要吃草的问题作为价值点显然是比较荒谬的，更合理的是描绘高速通勤的场景带来的便利性作为卖点。这种思路有两个关键点：

首先这个场景最初是产品经理假想的（当然肯定也会做过很多访谈和田野调查），所以如何确保这个场景是 “高价值” 且“具有普适性”的？对于一个成功的基础软件，这点尤其重要，通常在项目早期能抓到一个这样的点，就相当于成功了一半，当然这个对产品经理的要求是非常高的，通常需要有很强的 vision 和推动力，这就是为什么很多产品型公司的 CEO 都是早期的大号产品经理，因为在项目的早期 CEO 需要同时拥有这两样。当然更强的犹如乔布斯这种现实扭曲场，无中生有造出 iPod / iPhone 改变了整个世界，这是何等的魄力和远见（我相信 Jobs 在构思 iPhone 的时候应该能想象到今天的世界）。这个没啥办法，基本就是靠人。

你产品的价值是否在这个场景里有最直接的体现。最好的直接通常是直指人心的，是人直接能体会到的“感受”。对于开发者产品来说，我通常会选择的锚点是 “用户体验”，因为好的体验是不言自明的，汽车和马车对比在通勤舒适度和效率的时候，是完胜的；就像 TiDB 和 MySQL 分库分表的方案比弹性扩展能力时候也是一样，体验上也是完胜的。对于这一点倒是有很多方法去参考，有兴趣的可以参考我那篇关于用户体验的文章。

第一种思路本质上来说是 Storytelling，这种方式的好处在于：

非常好验证，当你把故事想明白了，那自然典型的用户旅程就出来了，这时候你把自己作为一个假想的用户完整的体验一遍即是验证，这也是我通常使用的检验我们自家产品经理工作的方式。

用户很好接受，道理很简单：人人都喜欢听故事，人人都喜欢看 Demo，人人都喜欢抄作业。

对于第二种思路，通常适用于一些改进型的特性，其中的关键点在于：待解决的问题到底多痛？没有完美的软件，在重度用户那边一定会有各种各样的问题，而且这类问题通常这个功能的开发者是难以体会到的，这时候要做的也很简单，就是弯下腰去了解，去使用，去感受。我经常会去和我们的客户交付团队的一线同学聊天，在做这次分享之前也不例外，大致的对话如下：

我：关于我们的 SQL 优化器，你觉得日常工作中，让你最头疼的问题是啥？

Ta：执行计划突变。

我：对了，那是 hint 不太够用吗？而且 3.0 就引入了 SQL Binding？这些帮上忙了吗？

Ta：对于一些疑难杂症来说你很难通过 hint 来指定的特定的执行计划（然后附上了一个真实的业务场景中的例子，一条百行的 SQL，确实无从下手），另外 SQL Binding 问题在于，我绑定了 SQL 执行计划以后，之后如果有更好计划，还需要重新来？

我：我们 4.0 不如引入了 SQL Plan Management 吗？里面的自动演进功能不正好是解决这个问题的吗？

Ta：没错，但是我们生产环境都不敢开，对于极端重要的 OLTP 场景，不能容忍执行计划自动变更带来的抖动风险。

我：我们的产品做什么事情，能让你觉得日子好过一点？

Ta：1. 对于复杂的 SQL 能够选择目标执行计划，让我选择 binding 就好，而不是通过 Hint 构造；2. SPM 发现更好的执行计划，只需要及时通知我，我来做变更，而不是自动决策变更。

上面最后一句的两个反馈，我听到以后觉得很有启发，其实这两个需求都是很中肯，而且开发的代价并不大，但是确实节约了很多的时间和 DBA 的心智负担。

类似的例子还有很多，但是重点是：找到产品的重度使用者，深入挖掘他最头疼的问题，有时候会有意想不到的收获（例如去 OnCall 的现场观察大家的操作）。而且这类问题的解决，通常也会伴随着很好的体感，TiDB 在最近几个版本中的一些关于可观测性的改进，基本都是通过类似的观察得来。

但是第二种思路的价值展现，一定要找到合适的听众，例如：通常我们为应用开发者（数据库的使用者）解决的问题和数据库运维者（DBA）是不一样的。面对错误的对象，结果有可能会是鸡同鸭讲。

2当用户在说：“我要这个”的时候，Ta 其实在说什么？

在中国基础软件的产品经理和解决方案工程师难找，我觉得是有历史原因的，就像上面我提到，过去很长时间，我们通常是站在一个“使用者”的视角去看待软件，这意味着从问题到解决方案通常是明显的，例如，假设我需要做一个高性能，支持亚毫秒低延迟读写的 User Profile 系统，数据量不大，可以容忍数据丢失，那我就用 Redis 好了！但是作为 Redis 的产品经理来说，ta 很难为了 User Profile 这个很特化的场景去设计 Redis 的功能。

优秀的基础软件产品经理通常会选择通用的技能点，用尽可能小的功能集合来包含更大的可能性（这样的灵活性是被鼓励的，例如：UNIX），所以这就对于基础软件厂商的售前和解决方案工程师提出了更高的要求：很多业务需要的“特性”是需要多个“技术点”组合出来的，或者通过引导到正确的问题从而提供更好的解决方案。下面我会通过几个例子来说明这个观点：

第一个例子，我们的经常被用户问到：TiDB 有没有多租户功能？这个问题的我的回复并不是简单的“有”或者“没有”，而是会去挖掘用户真正想要解决的问题是什么？潜台词是什么？在多租户的例子中大概逃不出下面几种情况：

潜台词 1：“每个业务都部署一套 TiDB，太贵了”，价值点：节约成本

潜台词 2：“我确实有好多套业务使用 TiDB, 对我来说机器成本不是问题，但是配置管理太麻烦，还要挨个升级，监控什么的还不能复用”，价值点：降低运维复杂度

潜台词 3：“我有些场景特别重要，有些场景没那么重要，需要区别对待，对于不重要的我要共享，但是对于重要的要能隔离”，价值点：资源隔离 + 统一管控

潜台词 4：“我有监管要求，例如不同租户的加密和审计”，价值点：合规

搞清楚情况后，对于这几种不同的情况，我就拿其中一个作为例子：节约成本，展开说说。下一步就是思考我们手上有什么菜了。

对于 TiDB 5.x 来说，大致有下面几个技术点和上面这个特性相关：

Placement Rule in SQL（灵活的决定数据放置的功能）

TiDB Operator on K8s

XX（PingCAP 的一个新的产品，暂时还没发布，请期待，大致是一个多集群可视化管控的平台）

TiDB Managed Cloud Service

对于节约成本的诉求，通常的原因是冷热数据比例比较悬殊，我们观察到多数大集群都符合 2/8 原则，也就是 20% 的数据承载 80% 的流量，而且尤其是对于金融类型业务，很多时候数据是永远不能删除的，这就意味着用户也需要为冷数据支付存储成本，这种情况按照统一的硬件标准去部署这其实是不划算的，所以站在用户的角度，是很合理的诉求。

下一步需要思考的是：世界上没有新鲜事，用户现在是通过什么办法解决这样的问题呢？

类似冷热分离这样的场景，我见过比较多的方案是冷数据用 HBase 或者其它比较低成本数据库方案（例如 MySQL 分库分表跑在机械磁盘上），热数据仍然放在 OLTP 数据库里，然后定期按照时间索引（或者分区）手动导入到冷数据集群中。这样对于应用层来说，就要知道的哪些数据去哪里查询，相当于需要对接两个数据源，而且这样的架构通常很难应对突发的冷数据读写热点（尤其是 ToC 端业务，偶尔会有一些“挖坟”的突发流量）。

然后下一个问题是：我们的产品解决这个问题能给用户带来哪些不一样？如果还是需要用户手动做数据搬迁，或者搭建两个配置不同的 TiDB 集群，那其实没什么大的区别，在这个场景里面，如果 TiDB 能够支持异构集群，并且自动能将冷热数据固化在特定配置的机器上，同时支持冷数据到热数据自动交换，对用户来说体验是最好的：一个 DB 意味着业务的改动和维护成本最低。在 TiDB 5.4 里面发布了一个新的功能，叫做 Placement Rules in SQL, 这个功能可以让用户使用 SQL 声明式的决定数据的分布策略，自然可以指定冷热数据的分布策略。更进一步，对于多租户要求的更复杂数据分布方式，例如不同租户的数据放置在不同的物理机上，但是又能通过一个 TiDB 集群统一管控，通过 Placement Rules in SQL 这个功能也能实现。

3Meta Feature：解决方案架构师的宝藏

说到这里，我想进一步展开一个概念，有一些功能和其它功能不一样，这类功能可以作为构建其它功能的基础，组合出新的特性。这类功能我称之为：Meta Feature，上面提到的 Placement Rule 就是一个很典型的 Meta Feature, 例如：Placment Rule + Follower Read 可以组合成接近传统意义上的数据库一写多读（但是更灵活，更加细粒度，特别适合临时性的捞数或者做临时的查询，保证数据新鲜的情况下，不影响在线业务），Placement Rule + 用户自定义的权限系统 = 支持物理隔离多租户；Placement Rule + Local Transaction + 跨中心部属 = 异地多活（WIP）；Placement Rule 还可以将精心设施数据的放置策略，让 TiDB 避免分布式事务（模拟分库分表），提升 OLTP 性能。

Meta Feature 通常不太会直接暴露给终端的用户，因为灵活性太强，用户会有一定的学习成本和上手门槛（除非经过精心的 UX 设计），但是这类能力对于架构师 / 解决方案提供商 / 生态合作伙伴尤其重要，因为 Meta Feature 越多，一个系统的“可玩性”越高，造出来的差异化方案也越多。但是通常我们会犯一个错误：灵活性是否等于产品价值？我认为不是的，虽然工程师（尤其是 Geek）对这类开放能力有天生的好感，但是对于终端用户到底能否说好这样的故事，我是存疑的，看看 Windows 和 UNIX 的终端用户的市场占有率就知道了。在这个例子上最近我听到了个绝佳的例子，和大家分享：你并不能对一个美式的爱好者说拿铁更好，因为你可以灵活的控制含奶量，奶量降低到 0 就包含了美式。

我们再看一个场景，关于批处理。熟悉 TiDB 历史的朋友肯定知道我们最早这个项目的初心其实是从 MySQL Sharding 的替换开始的，后来慢慢的很多用户发现：反正我的数据都已经在 TiDB 里了，为什么不直接在上面做计算？或者原来一些使用 SQL 做的复杂的数据变换工作遇到了单机计算能力瓶颈，而且因为一些业务要求，这些计算还需要保持强一致性甚至 ACID 事务支持，一个典型的场景就是银行的清结算业务。

本来年轻的我还不太理解，这类批处理业务直接 Hadoop 跑就好了，后来了解清楚情况以后才发现还是年轻了，对于银行来说，很多传统的清结算业务是直接跑在核心的数据库上的，而且业务也不简单，一个 Job 上百行的 SQL 家常便饭，很可能开发这个 Job 的开发商已经不见了，谁也不敢轻易改写成 MR Job，另外对于批量后结果，可能还要回填到数据库中，而且整个过程需要在短短几个小时内完成，完不成就是生产事故。原本如果数据量没那么大，跑在 Oracle，DB2 小型机上也没啥问题，但是最近这几年随着移动支付和电子商务的兴起，数据量越来越大，增长也越来越快，Scale-Up 一定迟早成为瓶颈。TiDB 在其中正好切中两个很高的价值点：

SQL 兼容的能力（尤其在 5.0 支持 CTE 后和 5.3 引入的临时表功能，复杂 SQL 的兼容性和性能得到很好提升），也支持金融级的一致性事务能力。

Scale-out 横向的计算扩展能力（尤其在 5.0 支持 TiFlash MPP 模式后，解锁了在列式存储上进行分布式计算的能力），理论上只要有足够多的机器，吞吐能够扩展上去。

对于银行的批量业务来说，令人头疼架构改造问题变成了简单的买机器的问题，你说香不香？但是在 TiDB 早期设计的解决方案中，有几个痛点：

大批量数据导入

分布式计算

对于第一个问题，通常一个典型的 TiDB 做批量任务的流程是：下档（每日的交易记录通过文件的形式发布）-> 将这些记录批量写入到 TiDB 中 -> 计算（通过 SQL） -> 计算结果回填到 TiDB 的表中。档案记录可能是一大堆文本文件（例如 CSV）格式，最简单的写入方式肯定就是直接一条条记录用 SQL Insert 的方式写入，这个方式处理点小数据量问题不大，但是数据量大的话，其实是比较不划算的，毕竟大多数导入都是离线导入，虽然 TiDB 提供大事务（单个事务最大 10G），但是站在用户的角度有几个问题：

批量写入通常是离线的，这种场景用户的核心诉求是：快！在这种场景下，完整的走完分布式事务的流程是没必要的。

虽然有 10G 的边界，对于用户来说也很难切割得精确。

大事务的写入过程中意味着需要更大的内存缓存，这点常常被忽略。

一个更好方式是支持物理导入，直接分布式的生成底层存储引擎的数据文件，分发给存储节点，直接插入物理文件，也就是 TiDB 的 Lightning 做的事情。在最近的一个真实用户的场景观察到，Lightning 使用 3 台机器，大概在 72h 内完成了 ~30T 的原始数据的转码和导入工作，大概导入吞吐能做到 380GB/h。所以在批量的场景中，能使用 Lightning 物理导入模式的话，通常是一个更快且更稳定的解。

另外的一个痛点，计算瓶颈（听起来还挺不合理的，哈哈哈），在早期 TiDB 还不支持 MPP 的时代，TiDB 只支持 1 层的算子下推，也就是 Coprocessor 分布在 TiKV 中的计算的结果只能汇总在一台 TiDB 计算节点上进行聚合，如果中间结果过大，超过了这个 TiDB 节点的内存，就会 OOM，这也就是为什么过去 TiDB 需要引入 Spark 来进行更复杂的分布式计算的原因（尤其是大表和大表的 Join），所以在过去对于复杂的批量业务还是需要引入一批 Spark 的机器通过 TiSpark 对 TiDB 的计算能力进行补充。但是在 TiDB 5.0 后引入了 TiFlash 的 MPP 模式，可以通过多个 TiDB 计算节点进行计算结果聚合，于是计算能力并不再是瓶颈了，这意味着，很有可能在一些 TiDB 的批量计算场景中，5.0 能够节省一批 Spark 的机器，意味着更简单的技术栈和更高的性能。

更进一步，引入 Spark 还有一个原因，就是在计算结果回填的阶段，由于 TiDB 的事务大小限制，以及提升并发写入的效率，我们会使用 Spark 来对 TiDB 进行分布式的数据插入。这个过程理论上也是可以通过 Lightning 改进的，TiFlash MPP 可以将结果数据输出成 CSV，Lightning 是支持 CSV 格式的数据导入的。

所以原来的链路理论上有可能变成：Lightning 导入数据到 TiDB -> TiDB 使用 TiFlash MPP 进行计算结果输出成 CSV -> 再次通过的 Lightning 将 CSV 结果写入到 TiDB 中；有可能比使用 TiSpark + 大事务的方案更快更省资源，也更稳定。

在这个方案上我们可以再延伸一下仔细想想，上面的方案优化其实是利用了 Lightning 的大批量数据写入能力，理论上有“大写入压力”的数据导入场景，都可以通过这个思路改进。我这里分享一个 TiDB 的用户真实反馈：这个客户业务系统上到 TiDB 后，会有定期大表导入的场景，他们希望先将大空表通过 Placement Rule 指定到特定空闲主机，然后通过 Lightning 快速导入数据，不需要考虑限流等措施也可以降低对整体集群的影响，实现快速导入；相反的，如果 TiDB 没有这个调度能力，客户只能通过限流的方式保持集群稳定，但是导入速度会很慢。这个例子是通过 Placement Rule + Lightning 实现了在线的批量写入，也是很好的呼应了一下前面关于 Meta Feature 的描述。

本来在线下的分享中还有关于“分库分表” vs TiDB 的例子，因为篇幅关系就不展开了，感兴趣的可以按照上面的思路去思考。

4更隐式，但更大更长期的价值：可观测性和 Troubleshooting 能力

最后一部分，大家也能看到，最近其实我一直在努力的传达这个 Message，对于一个基础软件产品来说，一个重要的长期竞争力和产品价值来自于可观测性和 Troubleshooting 能力。这个世界没有完美的软件，而且对于有经验的开发者来说，快速的发现和定位问题的能力是必备的，对于基础软件的商业化来说，服务支持效率和 Self-serving 也是规模化的基础，这一点在云的环境下也同样重要。我这里说一些我们最近做的一些新的事情，以及未来面临的挑战。

TiDB Clinic (tiup diag)

为什么要做这个事情？过去我们在做故障诊断的时候，是一个痛苦的过程，除了我在之前的关于可观测性的文章中提到的老司机的经验只在老司机脑子里的问题外，我观察到其实消耗时间的大头来自于收集信息，尤其是部署在用户自己的环境中，用户对于系统诊断并不熟悉，求助我们的服务支持的时候，经常的对话是：

服务支持：请运行这个命令 xxx，然后告诉我结果

客户：（2 小时后才给了结果）

服务支持：不好意思，麻烦在你们的监控界面上看某个指标的图表

客户：截图给你了

服务支持：不好意思的，时间段选错了。。。然后调整一下 grafana 的规则，再来一遍

客户：！@##￥#￥%

服务支持（隔了几天换了个人值班）：请运行这个命令 xxx，然后告诉我结果

客户：之前不是给过了吗？

这样一来一回异步又低效的问题诊断是很大的痛苦的来源，以及 oncall 没办法 scale 的核心原因之一。用户的痛点是：

你就不能一次性要完所有的信息吗？我并不知道给你哪些”

“信息太大太多太杂，我怎么给你？”

“我的 dashboard 在内网里，你看不到，我也只能截图”

“我不能暴露业务信息，但是可以提交诊断信息”

但是反过来，TiDB 的服务支持人员的痛点是：

“原来猜测的方向不太对，需要另一些 metric 来验证”

“无法完整重现故障现场的 metrics 和系统状态，我希望自由的操作 Grafana”

“不同的服务支持人员对于同一个用户的上下文共享”

于是就有了 Clinic 这个产品了，在用户同意的前提下：

通过 tiup 一键自动收集和系统诊断相关的各种指标

通过不断学习的规则引擎，自动化诊断一些常见错误

针对不同租户的诊断信息存储和回放平台（类似 SaaS）

如果熟悉 AskTUG （TiDB 用户论坛）的朋友，可能会看到类似这样的链接：https://clinic.pingcap.net/xxx（例如这个 case：https://asktug.com/t/topic/573261/13）

对于用户来说，只需要在集群内执行一个简单的命令，就会生成上面这样的一个链接，把重要的诊断信息与 PingCAP 的专业服务支持人员共享，我们在后台可以看到：

其实 TiDB Clinic 也是对于基础软件的维护性的一个新尝试：诊断能力的 SaaS 化，通过一个在云端不断强化的规则引擎，将故障的诊断和修复建议和本地的运维部署结耦。这样的能力会变成用户选择 TiDB 的一个新的价值点，也是 TiDB 很强的生态护城河。

TiDB Dashboard 中 Profiling

我心目中对于一个基础软件产品是不是好，我有一个特别的标准：自带 Profiler 的，基本上都是良心产品，能够把 Profile 体验做 UX 优化的，更是良心中的良心。例如 Golang 的 pprof，用过都说香。其实这个点说起来也不难做，但是关键时刻能救命，而且通常出事的时候也没法 Profile 了，这个时候如果系统告诉你，自己在故障的时候保存了一份当时的 profile 记录，这种雪中送炭似的帮助的体验是很好的。

其实这个功能来自于几个我们实际处理过的 oncall case，都是一些通过 metric 没法覆盖到的问题，有一大类故障，是遇到硬件瓶颈了，大概逃不过 CPU 和磁盘，磁盘瓶颈相对好查，大致看有没有大的 IO（Update / Delete / Insert）或者 RocksDB 本身的 Compaction 就好，但是 CPU 瓶颈的查找方式就模糊许多，Profiler 几乎是唯一的方式：

CPU 的关键路径上的 Call Stack 是什么样子

这些关键路径上的函数调用暗示了什么？第二个问题通常是查问题的关键，会给出一个优化的方向，例如我们发现 SQL Parse/ 优化的 CPU 消耗特别大，这就暗示了应该使用 Plan Cache 这样的机制能够提升 CPU 的利用率。

目前 TiDB 在 5.x 中提供了两种 Profile 方式：手动 Profile 和自动持续 Profile，两种应用场景不同，手动的通常用于针对性的性能优化；自动持续 Profile 通常用于系统出现问题后的回溯。

5面临的挑战

快结尾了，说点挑战。PingCAP 是在 2015 年成立的，到现在已经马上就要 7 岁了，在这 7 年里，正好经历了一些很重要的行业变革：

数据库技术从分布式系统过渡到云原生；虽然很多人可能觉得这两个词并不是一个层面上的概念，因为云原生也是分布式系统实现的呀？但是我觉得云原生是一种设计系统的思考方式的根本改变，这点我在我其他很多文章里提过，就不赘述了。

开源的数据库软件公司找到了可规模化商业化的模式：在云上的 Managed Service。

全球的基础软件领域正在经历从“能用”变成“好用”的阶段

这几点分别代表两个方向上的认知改变：

在技术上，需要完成从依赖计算机的操作系统和硬件变成依赖云服务，这一点对于技术的挑战是巨大的，例如：使用 EBS 的话，是否 Data Replication 还是必须的？使用 Serverless 的话，是否能够打破有限的计算资源的限制？如果这个问题再叠加上已有的系统可能有大量的现有用户会变得更加复杂，当然，云原生技术并不等于公有云 Only，但如何设计出一条路径，慢慢的过渡到以云原生技术为基础的新架构上？这会是对于研发和产品团队一个巨大的挑战。

第二个改变会是更大的挑战，因为商业模式在转变，在传统的开源数据库公司，主流的商业模式是以服务支持为主的人力生意，高级一点是类似 Oracle 这样的卖保险的生意，但是这些商业模式都没有办法很好的回答两个问题：

a. 商业版和开源版的价值差异

b. 如何规模化，已经靠人力是无法规模化的

而 SaaS 的模式则可以很好回答这两个问题，而且基础设施类的软件和 SaaS 的模式融合后会有更大的放大效应，我在《大教堂终将倒下，但集市永存》一文提及过，但是真正的挑战在于：一个面向传统软件售卖 + 服务支持导向的软件公司的组织如何调整为一个面向运营的线上服务公司？以研发体系为视角，举几个小例子：1. 版本发布，对于传统软件公司来说，一年发布 1～2 个版本就不错了，但是线上服务有可能一个礼拜就升级一次，不要小看这个发版节奏的差异，这个差异决定了整个研发和质量保障体系模式的差异。2. 如果在云上提供服务，那么就需要配套的运营支持系统（计费，审计，故障诊断等）以及相应的 SRE 团队，这些系统可能并不在传统的软件研发体系里面，另外对于用户体验和开发者体验的关注变得尤其重要。

当然挑战也不止这些，也都没有标准答案，不过我还是对未来充满信心的，毕竟这些趋势本质上都是在加速技术到社会价值和商业价值的转化以及降低门槛，都是好的且务实的转变，这对于 PingCAP 这样的公司来说当然是利好，前方是星辰大海，一切都是事在人为，大有可为。本来就想写一篇小文，没想到写着写着就扯得有点长了，就到这里吧。

麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践

Thu, 02 May 2024 10:00:17 +0800

前言

笔者最近在一个银行项目中做 PoC 测试，由于客户选择了使用 TiDB 数据库，于是笔者在 TiDB 中选择了一个相对稳定并且 bug 较少的版本：TiDB v5.1.2。

虽然 bug 较少，但是在测试过程中，还是不可避免的发现了一些问题，并通过参数来调整解决。

经过 PoC 测试和方案的制定，就迎来了生产环境的部署。生产环境的部署就不像是部署测试环境那么简单了。测试环境还能“从简”出发，减少一些非必要的配置项的设置，比如 CPU 频率的 cpufreq 模块是否选用 performance 模式；存储介质的 I/O 调度器是否设置为 noop。但是在生产环境中，我们必须把所有优化项都设置好，哪怕只是优化一点点也不能放过。

本文会把项目中的部署架构以及生产环境中需要注意的事项都整理出来，给大家一些参考。

一、同城两中心部署

在项目中，客户对容灾要求较高，希望不管是哪个数据中心出现问题，TiDB 数据库都可以无需人工干预并且无缝切换到另一个中心，直接提供服务。根据官网，目前有两种方案：

同城两中心自适应同步模式部署：在官网中的同城两中心自适应同步模式部署文档中是实现不了的，因为从数据中心虽然有完整数据，但是需要人工介入才能让 TiDB 恢复并提供服务。

两地三中心部署：两地三中心部署虽然可以满足客户的需求，不管哪个数据中心出现问题，TiDB 集群都可以正常对外提供服务，但是这就必须有三个数据中心才能够满足条件。现实的情况是，客户只有两个数据中心，所以这个方案也不行。

最后，根据目前的情况，商量出来了一个方案：在两个数据中心部署两套 TiDB 集群，用 TiCDC 组件同步两个集群的数据。由于是两个不同的集群，万一主数据中心出现问题，也不会影响到从数据中心。利用 F5 负载均衡实现主数据中心故障后，自动切换到从数据中心，达到无需人工干预就可以无缝切换到从数据中心的需求。

二、环境检查

生产环境检查和测试环境检查就有很大的区别了，主要体现在检查项目变多和检查更加细节，本文只列举，除官方文档之外需要检查的部分：

1、物理机配置查看

主要是查看物理机配置是否与客户给的一致，包括 CPU （观察核数以及是否开启超线程），网卡（是否万兆网卡），硬盘（数据盘是否为 NVME SSD 磁盘）等等。并且需要确认 NVME 磁盘使用率不能超过 5%。这些配置一般都没啥问题，但是该检查还是得检查一下，万一出现配置不对的情况，这个锅我们不背！

2、网络环境检查

网络环境一定要检查！网络环境一定要检查！网络环境一定要检查！

重要的事情一定要多说几遍。生产环境中的网络一般很复杂，所以一定要检查集群中网络是否符合要求。如果网络不到万兆，或者网络波动很大，都会对 TiDB 集群产生不好的影响。

推荐服务器双网卡做 bond1(master-salve) 或多网卡 team0(activebackup)，保障网卡高可用

主机间网络延迟：同机房内网络 < 0.5ms，同城 <1.5ms，异地 <20ms

主机间网络吞吐流量：若网络间吞吐远低于万兆网(1GB/S)，沟通用户、协同排查

主机间防火墙策略：TiUP 及各个节点需要开放的端口需要一一排查是否开放

3、磁盘环境检查

磁盘除了要使用 NVME 和检查挂载方式以外，还需要检查磁盘 IO 是否达到 TiDB 集群的最低要求：

指标标准值随机读测试 read iops不低于 40000随机读与顺序写混合测试 read iops不低于 10000随机读与顺序写混合测试 write iops不低于 10000随机读与顺序写混合测试 read latency (ns)不高于 250000随机读与顺序写混合测试 write latency (ns)不高于 30000

测试方法：

# 测试脚本准备 wget http://download.pingcap.org/fio-3.8.tar.gz tar -xzvf fio-3.8.tar.gz cd fio-3.8 ls fio parse_fio_output.py # 包含fio测试文件以及解析测试结果的python脚本1、随机读测试

随机读测试 read iops 不低于 40000

[root@tikv01 ~]# ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randread -size=10G -filename=fio_randread_test.txt -name=fio randread test -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_result.json [root@tikv01 ~]# rm fio_randread_test.txt [root@tikv01 ~]# python parse_fio_output.py --target=fio_randread_result.json --read-iops2、随机读与顺序写混合测试

随机读与顺序写混合测试 read iops 不低于 10000

随机读与顺序写混合测试 write iops 不低于 10000

[root@tikv01 ~]# ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randrw -percentage_random=100,0 -size=10G -filename=fio_randread_write_test.txt -name=fio mixed randread and sequential write test -iodepth=4 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_write_test.json [root@tikv01 ~]# rm fio_randread_write_test.txt [root@tikv01 ~]# python parse_fio_output.py --target=fio_randread_write_test.json --read-iops [root@tikv01 ~]# python parse_fio_output.py --target=fio_randread_write_test.json --write-iops

随机读与顺序写混合测试 read latency (ns) 不高于 250000

随机读与顺序写混合测试 write latency (ns) 不高于 30000

[root@tikv01 ~]# ./fio -ioengine=psync -bs=32k -fdatasync=1 -thread -rw=randrw -percentage_random=100,0 -size=10G -filename=fio_randread_write_latency_test.txt -name=fio mixed randread and sequential write test -iodepth=1 -runtime=60 -numjobs=1 -group_reporting --output-format=json --output=fio_randread_write_latency_test.json [root@tikv01 ~]# rm fio_randread_write_latency_test.txt [root@tikv01 ~]# python parse_fio_output.py --target=fio_randread_write_latency_test.json --read-lat [root@tikv01 ~]# python parse_fio_output.py --target=fio_randread_write_latency_test.json --write-lat

4、关于配置互信

关于互信，这里的操作与官方文档稍有不同。为了避免人为配置互信出现问题，笔者在这一步只创建了 tidb 用户，并且按照官方文档赋予了最高权限，并没有手动去配置互信。笔者在最后的部署阶段，是默认用 tiup 自动去配置各个主机间的互信的，这一步不需要人为干预。

三、NUMA 绑核

这次是把 TiDB 集群部署在国产海光 CPU 上，所以一定需要用 numa 绑核才能发挥出完全的性能。为什么一定要绑定 numa 才能发挥出应有的性能呢？这个可以看看秦老师的一篇文章：

专栏 - 单机 8 个 NUMA node 如何玩转 TiDB - AMD EPYC 服务器上的 TiDB 集群最优部署拓扑探索

关于 numa 绑核，笔者这次也是踩了坑。说说这是个什么坑吧，一句话概括就是，两个 NVME 硬盘都挂载到同一个物理 CPU 上了，而且想要挂载到不同的物理 CPU 上，条件还不允许。最优的情况是，两个 NVME 硬盘平均挂载到两个不同的物理 CPU 上，这样 CPU 去调用磁盘会更快。

为什么笔者的情况无法解决呢？因为物理机上有一个东西：背板。磁盘是先插到背板上的，由背板走线直接连接到不同的物理 CPU 上。但是背板是有不同型号的，笔者遇到的物理机背板只有两块，一块是只能插 sata 接口的，另一块是只能插 NVME 接口的，这种情况下，两块 NVME 只能插在同一个背板上，而背板只能连接到某一个物理 CPU 上，所以无法分开。所以，在前期规划部署的时候，这一点需要注意。

关于两块 NVME 连接到一个物理 CPU 的性能损耗，得到厂商回复：

连接到两块CPU和连接到一块CPU，访问延迟最多多了240纳秒，这240纳秒主要是CPU到CPU之间的访问延迟。

还有一个小坑要注意一下，麒麟v10是默认开启 numa 自动均衡的，所以一定要手动关闭：

sysctl -w kernel.numa_balancing=0

四、配置相关

目前来看，TiDB v5.1.2 的版本也算是有点老了，所以不可避免的还是有点小 bug 的，但是这些 bug 都可以根据参数的设置而避免。那么这个配置参数就非常重要了。根据 PoC 测试和从社区整理的拓扑配置最佳实践如下：

server_configs: tidb: # 日志最大保留的天数 log.file.max-days: 15 #日志的输出级别 log.level: info # 最长的 SQL 输出长度 log.query-log-max-len: 65536 # 输出慢日志的耗时阈值 log.slow-threshold: 300 # 用于设置新建索引的长度限制 max-index-length: 12288 # 单条 SQL 语句可以占用的最大内存阈值 mem-quota-query: 10737418240 #单条 SQL 超过内存限制时，取消执行该 SQL 操作 oom-action: cancel # 在单个事务的提交阶段，用于执行提交操作相关请求的 goroutine 数量 performance.committer-concurrency: 128 # 关闭对查询收集统计信息反馈 performance.feedback-probability: 0 # 单个事务允许的最大语句条数限制 performance.stmt-count-limit: 50000 # 单个事务大小限制 performance.txn-total-size-limit: 10737418240 # 缓存语句的数量 prepared-plan-cache.capacity: 100 # 开启 prepare 语句的 plan cache prepared-plan-cache.enabled: true # 防止 prepare plan cache 的内存用量过大 prepared-plan-cache.memory-guard-ratio: 0.1 #关闭批量发送 rpc 封包（解决 Compaction Filter GC 可能不删除 MVCC deletion 信息的问题，v5.1.3 修复） tikv-client.max-batch-size: 0 tikv: # 关闭 GC in Compaction Filter 特性（解决 Compaction Filter GC 可能不删除 MVCC deletion 信息的问题，v5.1.3 修复） gc.enable-compaction-filter: false # 日志等级 log-level: info tiflash: #解决因大量 delete 导致 tiflash 无法使用的 bug profiles.default.dt_enable_skippable_place: 0

系统参数最佳实践如下：

# 统计信息版本设置 set global tidb_analyze_version=1; # 关闭 Async Commit 特性 set global tidb_enable_async_commit=0; # 关闭一阶段提交特性 set global tidb_enable_1pc=0; # 唯一索引的重复值检查不推迟到事务提交时进行 set global tidb_constraint_check_in_place = 1; # 垃圾回收 (GC) 时保留数据的时限 Set globaltidb_gc_life_time= 8h; # sql mode设置 set global sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION;

笔者只写出了基本需要调整的参数，参数数值可以根据项目情况来更改。也可以增加一些笔者没写出来的参数并进行调整。

配置文件参数详情：TiDB 配置文件描述，TiKV 配置文件描述，PD 配置文件描述，TiFlash 配置参数

系统变量参数详情：系统变量

总结

规划好一个最适合的架构，现有的方案都不满足需求的话，那就到社区找找有没有同样需求的小伙伴，一起讨论讨论。

生产环境部署 TiDB 集群最重要的就是仔细。硬件和环境检查一定要全面，万一以后 TiDB 集群性能出现问题，也不至于说再去说是硬件或者是环境的锅。

numa 绑核要提前想好如何绑定，以及该如何规划磁盘的挂载。

配置文件尽量避免现有版本 bug，根据项目情况设置好最优参数。

高成本云服务？TiDB 帮你省钱

Thu, 02 May 2024 00:00:18 +0800

aws的费用是非常贵的云上rds的费用更高。我来给出一组数据。如果全部用aws来储存数据。一个月的费用是500w美元左右。某某某公司。

于是乎dba中的冯大嘴喊出了云数据库就是杀猪盘。让每个公司自建数据库。

云上数据疯狂扩张，阿里巴巴是十几万个数据库。开发了tddl。放弃了oracle，选择自建

云下也有几百上千个数据库。数据库多，一直告警。管又管不过来怎么办。

一堆告警。

前言

在高并发系统当中，分库分表是必不可少的技术手段之一，同时也是BAT等大厂面试时，经常考的热门考题。

你知道我们为什么要做分库分表吗？

这个问题要从两条线说起：垂直方向和水平方向。

1 垂直方向

垂直方向主要针对的是业务，下面聊聊业务的发展跟分库分表有什么关系。

1.1 单库

在系统初期，业务功能相对来说比较简单，系统模块较少。

为了快速满足迭代需求，减少一些不必要的依赖。更重要的是减少系统的复杂度，保证开发速度，我们通常会使用单库来保存数据。

系统初期的数据库架构如下：

此时，使用的数据库方案是：一个数据库包含多张业务表。用户读数据请求和写数据请求，都是操作的同一个数据库。

1.2 分表

系统上线之后，随着业务的发展，不断的添加新功能。导致单表中的字段越来越多，开始变得有点不太好维护了。

一个用户表就包含了几十甚至上百个字段，管理起来有点混乱。

这时候该怎么办呢？

答：分表。

将用户表拆分为：用户基本信息表和用户扩展表。

用户基本信息表中存的是用户最主要的信息，比如：用户名、密码、别名、手机号、邮箱、年龄、性别等核心数据。

这些信息跟用户息息相关，查询的频次非常高。

而用户扩展表中存的是用户的扩展信息，比如：所属单位、户口所在地、所在城市等等，非核心数据。

这些信息只有在特定的业务场景才需要查询，而绝大数业务场景是不需要的。

所以通过分表把核心数据和非核心数据分开，让表的结构更清晰，职责更单一，更便于维护。

除了按实际业务分表之外，我们还有一个常用的分表原则是：把调用频次高的放在一张表，调用频次低的放在另一张表。

有个非常经典的例子就是：订单表和订单详情表。

1.3 分库

不知不觉，系统已经上线了一年多的时间了。经历了N个迭代的需求开发，功能已经非常完善。

系统功能完善，意味着系统各种关联关系，错综复杂。

此时，如果不赶快梳理业务逻辑，后面会带来很多隐藏问题，会把自己坑死。

这就需要按业务功能，划分不同领域了。把相同领域的表放到同一个数据库，不同领域的表，放在另外的数据库。

具体拆分过程如下：

将用户、产品、物流、订单相关的表，从原来一个数据库中，拆分成单独的用户库、产品库、物流库和订单库，一共四个数据库。

在这里为了看起来更直观，每个库我只画了一张表，实际场景可能有多张表。

这样按领域拆分之后，每个领域只用关注自己相关的表，职责更单一了，一下子变得更好维护了。

1.4 分库分表

有时候按业务，只分库，或者只分表是不够的。比如：有些财务系统，需要按月份和年份汇总，所有用户的资金。

这就需要做：分库分表了。

每年都有个单独的数据库，每个数据库中，都有12张表，每张表存储一个月的用户资金数据。

这样分库分表之后，就能非常高效的查询出某个用户每个月，或者每年的资金了。

此外，还有些比较特殊的需求，比如需要按照地域分库，比如：华中、华北、华南等区，每个区都有一个单独的数据库。

甚至有些游戏平台，按接入的游戏厂商来做分库分表。

2 水平方向

水分方向主要针对的是数据，下面聊聊数据跟分库分表又有什么关系。

2.1 单库

在系统初期，由于用户非常少，所以系统并发量很小。并且存在表中的数据量也非常少。

这时的数据库架构如下：

此时，使用的数据库方案同样是：一个master数据库包含多张业务表。

用户读数据请求和写数据请求，都是操作的同一个数据库，该方案比较适合于并发量很低的业务场景。

2.2 主从读写分离

系统上线一段时间后，用户数量增加了。

此时，你会发现用户的请求当中，读数据的请求占据了大部分，真正写数据的请求占比很少。

众所周知，数据库连接是有限的，它是非常宝贵的资源。而每次数据库的读或写请求，都需要占用至少一个数据库连接。

如果写数据请求需要的数据库连接，被读数据请求占用完了，不就写不了数据了？

这样问题就严重了。

为了解决该问题，我们需要把读库和写库分开。

于是，就出现了主从读写分离架构：

考虑刚开始用户量还没那么大，选择的是一主一从的架构，也就是常说的一个master一个slave。

所有的写数据请求，都指向主库。一旦主库写完数据之后，立马异步同步给从库。这样所有的读数据请求，就能及时从从库中获取到数据了（除非网络有延迟）。

读写分离方案可以解决上面提到的单节点问题，相对于单库的方案，能够更好的保证系统的稳定性。

因为如果主库挂了，可以升级从库为主库，将所有读写请求都指向新主库，系统又能正常运行了。

读写分离方案其实也是分库的一种，它相对于为数据做了备份，它已经成为了系统初期的首先方案。

但这里有个问题就是：如果用户量确实有些大，如果master挂了，升级slave为master，将所有读写请求都指向新master。

但此时，如果这个新master根本扛不住所有的读写请求，该怎么办？

这就需要一主多从的架构了：

上图中我列的是一主两从，如果master挂了，可以选择从库1或从库2中的一个，升级为新master。假如我们在这里升级从库1为新master，则原来的从库2就变成了新master的的slave了。

调整之后的架构图如下：

这样就能解决上面的问题了。

除此之外，如果查询请求量再增大，我们还可以将架构升级为一主三从、一主四从...一主N从等。

2.3 分库

上面的读写分离方案确实可以解决读请求大于写请求时，导致master节点扛不住的问题。但如果某个领域，比如：用户库。如果注册用户的请求量非常大，即写请求本身的请求量就很大，一个master库根本无法承受住这么大的压力。

这时该怎么办呢？

答：建立多个用户库。

用户库的拆分过程如下：

在这里我将用户库拆分成了三个库（真实场景不一定是这样的），每个库的表结构是一模一样的，只有存储的数据不一样。

2.4 分表

用户请求量上来了，带来的势必是数据量的成本上升。即使做了分库，但有可能单个库，比如：用户库，出现了5000万的数据。

根据经验值，单表的数据量应该尽量控制在1000万以内，性能是最佳的。如果有几千万级的数据量，用单表来存，性能会变得很差。

如果数据量太大了，需要建立的索引也会很大，从小到大检索一次数据，会非常耗时，而且非常消耗cpu资源。

这时该怎么办呢？

答：分表，这样可以控制每张表的数据量，和索引大小。

表拆分过程如下：

我在这里将用户库中的用户表，拆分成了四张表（真实场景不一定是这样的），每张表的表结构是一模一样的，只是存储的数据不一样。

如果以后用户数据量越来越大，只需再多分几张用户表即可。

2.5 分库分表

当系统发展到一定的阶段，用户并发量大，而且需要存储的数据量也很多。这时该怎么办呢？

答：需要做分库分表。

如下图所示：

图中将用户库拆分成了三个库，每个库都包含了四张用户表。

如果有用户请求过来的时候，先根据用户id路由到其中一个用户库，然后再定位到某张表。

路由的算法挺多的：

根据id取模，比如：id=7，有4张表，则7%4=3，模为3，路由到用户表3。

给id指定一个区间范围，比如：id的值是0-10万，则数据存在用户表0，id的值是10-20万，则数据存在用户表1。

一致性hash算法

这篇文章就不过多介绍了，后面会有文章专门介绍这些路由算法的。

3 真实案例

接下来，废话不多说，给大家分享三个我参与过的分库分表项目经历，给有需要的朋友一个参考。

3.1 分库

我之前待过一家公司，我们团队是做游戏运营的，我们公司提供平台，游戏厂商接入我们平台，推广他们的游戏。

游戏玩家通过我们平台登录，成功之后跳转到游戏厂商的指定游戏页面，该玩家就能正常玩游戏了，还可以充值游戏币。

这就需要建立我们的账号体系和游戏厂商的账号的映射关系，游戏玩家通过登录我们平台的游戏账号，成功之后转换成游戏厂商自己平台的账号。

这里有两个问题：

每个游戏厂商的接入方式可能都不一样，账号体系映射关系也有差异。

用户都从我们平台登录，成功之后跳转到游戏厂商的游戏页面。当时有N个游戏厂商接入了，活跃的游戏玩家比较多，登录接口的并发量不容小觑。

为了解决这两个问题，我们当时采用的方案是：分库。即针对每一个游戏都单独建一个数据库，数据库中的表结构允许存在差异。

我们当时没有进一步分表，是因为当时考虑每种游戏的用户量，还没到大到离谱的地步。不像王者荣耀这种现象级的游戏，有上亿的玩家。

其中有个比较关键的地方是：登录接口中需要传入游戏id字段，通过该字段，系统就知道要操作哪个库，因为库名中就包含了游戏id的信息。

3.2 分表

还是在那家游戏平台公司，我们还有另外一个业务就是：金钻会员。

说白了就是打造了一套跟游戏相关的会员体系，为了保持用户的活跃度，开通会员有很多福利，比如：送游戏币、充值有折扣、积分兑换、抽奖、专属客服等等。

在这套会员体系当中，有个非常重要的功能就是：积分。

用户有很多种途径可以获取积分，比如：签到、充值、玩游戏、抽奖、推广、参加活动等等。

积分用什么用途呢？

退换实物礼物

兑换游戏币

抽奖

说了这么多，其实就是想说，一个用户一天当中，获取积分或消费积分都可能有很多次，那么，一个用户一天就可能会产生几十条记录。

如果用户多了的话，积分相关的数据量其实挺惊人的。

我们当时考虑了，水平方向的数据量可能会很大，但是用户并发量并不大，不像登录接口那样。

所以采用的方案是：分表。

当时使用一个积分数据库就够了，但是分了128张表。然后根据用户id，进行hash除以128取模。

需要特别注意的是，分表的数量最好是2的幂次方，方便以后扩容。

3.3 分库分表

后来我去了一家从事餐饮软件开发的公司。这个公司有个特点是在每天的中午和晚上的就餐高峰期，用户的并发量很大。

用户吃饭前需要通过我们系统点餐，然后下单，然后结账。当时点餐和下单的并发量挺大的。

餐厅可能会有很多人，每个人都可能下多个订单。这样就会导致用户的并发量高，并且数据量也很大。

所以，综合考虑了一下，当时我们采用的技术方案是：分库分表。

经过调研之后，觉得使用了当当网开源的基于jdbc的中间件框架：sharding-jdbc。

当时分了4个库，每个库有32张表。

4 总结

上面主要从：垂直和水平，两个方向介绍了我们的系统为什么要分库分表。

说实话垂直方向（即业务方向）更简单。

在水平方向（即数据方向）上，分库和分表的作用，其实是有区别的，不能混为一谈。

分库：是为了解决数据库连接资源不足问题，和磁盘IO的性能瓶颈问题。

分表：是为了解决单表数据量太大，sql语句查询数据时，即使走了索引也非常耗时问题。此外还可以解决消耗cpu资源问题。

分库分表：可以解决数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时和消耗cpu资源等问题。

如果在有些业务场景中，用户并发量很大，但是需要保存的数据量很少，这时可以只分库，不分表。

如果在有些业务场景中，用户并发量不大，但是需要保存的数量很多，这时可以只分表，不分库。

如果在有些业务场景中，用户并发量大，并且需要保存的数量也很多时，可以分库分表。

好了，今天的内容就先到这里。

是不是有点意犹未尽？

没关系，其实分库分表相关内容挺多的，本文作为分库分表系列的第一弹，作为一个开胃小菜吧，分享给大家。

这样就搞了一堆数据库

老板直接炸锅

有没有一种更好的办法呢？有就是同一账户数据库

在计算机行业google创业时搞了一堆x86机器做了一个bigtable的项目。就形成了hadoop的生态。

单机里面cpu不够用也就慢慢变成了双核三十二核心双路 256核心

之前在单机数据库的时代我们没办法发明一种可以无限扩容的数据库。所以采用了分库分表的方式但是现在tidb一台机器就能支撑之前分库分表的环境

而且这个数据库还支撑大数据分析再也不会出现妈妈说我查不动的情况了。

测试结果比较

差距最大的q1 q9 有100多倍，最小q4 也有5倍

q1q2q3q4q5q6q7q8q9q10mysql878.89s3.79s26.81s6.14s6.14s10.23s26.21s39.76s98.75s13.25stidb0.64s0.17s0.30s1.17s0.44s0.10s0.37s0.30s0.70s0.44s

原先需要这么多数据库

原先需要10套4xlarge的数据库顶a业务的账户系统

再需要10套4xlarge的数据库顶b业务的账户系统

再来十套数据库顶a业务的订单系统

再来十套数据库顶b业务的订单系统

40套数据库。另外还有其他100套这样组成了135套数据库

一套数据库需要2个cluster 一个cluster负责读业务。一个slave数据库负责同步功能

aws rds费用

cpu实例小时费用存储费用小时io1万次数总费用主读r5.4xlarge162.2800 USD每月每 GB 0.375 USD每月每 IOPS 0.30主写r5.4xlarge162.2800 USD每月每 GB 0.375 USD每月每 IOPS 0.30slaver5.4xlarge162.2800 USD每月每 GB 0.375 USD每月每 IOPS 0.30dms同步r5.4xlarge162544redshift最低配dc2.8xlarge324,449.35月费用76332304900019937

rds预估费用页面多可用区存储费率每月每 GB 0.45 USD 多可用区预调配 IOPS 费率每月每 IOPS 0.36 USD

也就是一套数据库20000一个月总共有四十套。

这些数据库容量都是很富裕的得应付突发事件。平时cpu就1%

一套数据库一个水桶。这120个水桶满满当当就存放了10桶水的业务。真是弃之可惜食之无味。

那么有没有一种数据库又便宜又好用呢。有哪就是tidb数据库。

之前用mysql数据库最好用的是阿里的tddl数据库。当年我师父谢睿告诉我

之前一个dba工程师的工作内容可能包括以下几个方面：

监控带宽、流量、并发、业务接口等关键资源及访问信息的变化趋势。

根据相应趋势变化不断演进和优化dba架构。

设计各类解决方案，解决公司业务发展中遇到的dba技术瓶颈。

编写各种自动化脚本（shell，python），自动化部署优化服务。

实现dba平台化运维。

制定dba运维流程、规范、制度，并有序推进。

研究先进dba运维理念、模式，确保业务持续稳定、有序。

但是现在dba还得帮公司省钱。如果贵公司的业务多。公司里面有个几百个数据库很正常。

这些数据库的月费用就是百万级别的。

那么我们能不能省下这些费用呢？没问题的tidb就是专门干这个的。

我们从两方面来省数据库的钱

双剑合璧

oltp，和olap数据库合二为一，同一套数据库即跑oltp也跑olap业务盛夏redshift的钱。

在用aws的物理机中

TiDB 资源控制和隔离：此部分主要介绍 TiDB 与 NUMA 和 cgroup 技术结合实现单机多实例部署时资源控制和隔离，以及 TiDB 自带的资源控制参数； TiDB 数据隔离：此部分主要介绍 TiDB Label 与 Placement Rules in SQL 技术实现数据存储隔离；基于上述资源控制和数据隔离技术实现单集群多业务融合架构；方案收益分析；监控和报警隔离说明：融合部署的业务应用可以根据重要性分别配置监控和报警。

把一台物理机当成2台使用通过绑定numa。节约了机器又提高了性能。解决了机器不够的问题。

多个业务A业务B业务用户中心公用一个数据库。做到了资源最大化利用。如果A用户量多就支援A业务。如果B用户量多就支援B业务。并由于大集群带来的业务容量的提升。无论各个业务量再怎么增长也能支撑的住。原本为了满足A的增长，B业务的增长得准备两套物理机器。现在由于共用，可以相互资源就节省了服务器的使用。并且把5套套业务机器并成一套。提升了5倍性能。TiDB 多业务融合方案是指将多个业务系统部署在同一套 TiDB 集群中，利用 Placement Rule 来实现资源隔离和负载均衡。

他就是线下的雪花模型

二

在这样的系统架构下我们采用了这样的

每类业务分配4核心8g内存的tidb，用于各类业务的oltp业务查询。在用资源管控来约束最大的cpu占比。把更多的资源，内存留给tikv tiflash

tiflash层采用s3作为冷存储因为s3本身可无限扩容费用又是最低的

而且tiflash的cpu 是可以动态扩容的这个时候就可以很好的利用aws的spot实例价格是ec2的10分之1

面对TiKV节点数据文件误删除，如何不换服务器快速恢复

Wed, 01 May 2024 10:15:38 +0800

社区里很多大佬总结了多副本丢失的灾难恢复方法，但是平时遇到最多的单节点故障快速恢复还没有人总结，本文为亲身实践后总结的问题处理过程，此过程保持集群可用无需停止其他节点服务。

背景

故事发生在炎炎夏日的某一天，通过一系列磁盘的iops的测试后，发了个工单质疑阿里云的ESSD磁盘性能不达标，阿里云的客服给我发了一份他们的测试文档，我在某个tidb集群上就开始测试，等我测试完后发现vdb的分区没了。

测试文档中提示，有可能会造成文件系统损坏。

tidb、pd、tikv是混合部署在一起的，TIDB集群变成了如下状态，得益于TIDB强大可用性设计，这个时候集群还是可用状态。

修复

最快速的修复办法是直接增加一台服务器扩容down掉的节点然后缩掉有问题的节点、回收服务器，但是为了节约资源，决定在原服务器上缩容扩容节点。

首先强制缩掉三个down掉节点：

tiup cluster scale-in tsp-prod-taos-cluster --node 10.20.10.138:4000 --force

tiup cluster scale-in tsp-prod-taos-cluster --node 10.20.10.138:2379 --force

tiup cluster scale-in tsp-prod-taos-cluster --node 10.20.10.138:20160 --force

集群变成如下状态：

重新给138服务器格式化vdb分区

在138服务器上扩容tidb、pd、tikv节点

tiup cluster scale-out tsp-prod-taos-cluster ./topo-kv02-tidb02-pd02.yaml --user root -p

global: user: "tidb" ssh_port: 22 deploy_dir: "/data/tidb-deploy" data_dir: "/data/tidb-data" server_configs: tikv_servers:- host: 10.20.10.138 port: 20160 status_port: 20180 pd_servers: - host: 10.20.10.138 tidb_servers: - host: 10.20.10.138

tidb和pd启动成功，kv启动失败

以下是报错日志：

Error: failed to start tikv: failed to start: 10.20.10.138 tikv-20160.service, please check the instances log(/data/tidb-deploy/tikv-20160/log) for more detail.: timed out waiting for port 20160 to be started after 2m0s[2023/08/09 10:37:25.985 +08:00] [ERROR] [util.rs:475] ["request failed"] [err_code=KV:PD:gRPC] [err="Grpc(RpcFailure(RpcStatus { code: 2-UNKNOWN, message: \"duplicated store address: id:406981 address:\\\"10.20.10.138:2 0160\\\" version:\\\"5.4.3\\\" status_address:\\\"10.20.10.138:20180\\\" git_hash:\\\"deb149e42d97743349277ff8741f5cb9ae1c027d\\\" start_timestamp:1691548641 deploy_path:\\\"/data/tidb-deploy/tikv-20160/bin\\\" , already registered by id:4 address:\\\"10.20.10.138:20160\\\" state:Offline version:\\\"5.4.3\\\" status_address:\\\"10.20.10.138:20180\\\" git_hash:\\\"deb149e42d97743349277ff8741f5cb9ae1c027d\\\" start_timestamp:1679983970 de ploy_path:\\\"/data/tidb-deploy/tikv-20160/bin\\\" last_heartbeat:1689209409692065070 \", details: [] }))"]

通过pd-ctl查看store 4处于offline状态，新的kv节点无法在pd中注册。

尝试删除store 4,虽然显示成功了，实际上并没有删除。

原因是：delete 成功，触发整个store下线（offline）、开始region迁移，在正常情况下，这个store所有region迁走后会变成tombstone状态。但是实际上这个store上region没有发生迁移（有效tikv数小于replica数）。

尝试设置该store状态为Tombstone，设置失败。

原因是在 5.0 及以上版本中，该接口只支持更改 state 为 Up 或者 Offline，废弃了直接更改为 Tombstone 这个功能。这是由于直接更改为 Tombstone 总是引起操作者意料之外的结果。

把store 4的physically_destroyed设置成ture

再看store状态

138新的kv节点也自动注册上来了

pd开始调度region到138新加入的kv中。

这个时候在pd中查看还是有4个store，由于有效tikv数>=replica数，region在迁移减少了。

适当调大region调度速度

region迁移结束，pd中sotre4消失

至此修复全部完成！

总结：

1 本文比较基础，提供了简单的处理流程，适合帮助对tidb理解不够深入的新手。

2 没事别瞎折腾服务器，另外需要吐槽下阿里云的ESSD磁盘性能是真的不行，测试下来大概只有nvme物理盘的五分之一。

3 遇到误删文件不要慌，无论是丢失少数副本无损修复还是丢失大多数副本有损修复，TIDB社区都有成熟案例和方案供大家选择。

零售业数据库选型与迁移ToC系统实践大规模场景应用

Wed, 01 May 2024 10:10:30 +0800

作者 | 云盛海宏 ToC 业务团队崔文涛，邓有才

云盛海宏是一家零售业科技公司，以科技的力量为门店和线上客户打造 360 度的优秀体验，目前服务中国 6000 余家的线下门店和千万级别的线上会员。云盛海宏的 To C 系统分为私域商城和会员营销两条业务线，它为 7000 多万注册会员提供了丰富的权益和服务，是我们非常核心的系统。

选型背景

随着近几年消费模式的升级，我们和消费者的互动与服务从传统线下逐渐延展至线上，使得 To C 系统的能力和规模越来越大，其数据库压力也越来越大。

最初在建设 To C 系统时，业务库主要使用 MySQL，既有单库架构，也有分库分表架构，时至今日我们面临的问题主要如下：

分库分表不合理导致的数据倾斜，某个分片负载居高不下，且难以动态调整

a. 分库分表规则为品牌名称，而不同品牌之间数据规模、用户规模有较大差异

b. 需要针对大分片再次进行二次拆分才能解决该问题，但同时复杂度将大幅提升

个别单库架构的 MySQL，数据增长远超预期，单表数据量过大，性能问题凸显

a. 数据量千万级以上表：87 张；亿级以上表：21 张

b. 需要将单库架构改造成分库分表架构才能解决

以上两个问题均需要大幅调整数据库架构来解决，解决成本高（人力、硬件），并且未来还可能再次面临这样的问题。为彻底解决以上问题，我们计划直接切换到原生分布式数据库 TiDB：

TiDB 兼容 MySQL 协议，并且是原生分布式，无需规划分片规则，对应用友好，能够很好的解决之前分库分表数据倾斜的问题

TiDB 架构下提供的动态水平扩展、热点自动调度等能力，大幅简化了一系列运维成本，能够支撑应用规模持续的增长，即使数据增长超过预期也能动态增加节点解决

另外我们的零售系统在去年成功切换到 TiDB，也给了我们团队很大的信心

数据库测试方案

对于数据库的切换我们比较关心以下几个问题：

迁移数据的完整性：数据是企业的核心资产，不容许丢失

SQL 兼容性及性能：这意味着我们迁移改造的成本

资源隔离能力：多个业务库合并后如何保障其服务质量

测试目的：识别关键问题，基于测试结果完善应用改造

测试一：迁移数据的完整性

数据同步

TiDB 提供 DM 数据同步工具，该工具支持 MySQL 全量、增量数据的同步，同时也支持分库分表的合并。对于分库分表的合并，我们的任务策略如下：

数据比对

为确保 DM 数据同步工具的可靠性，在切换过程中需要进行数据一致性校验。实测数据比对效率较高，能够达到 400MB/s 以上的全量比对速度，以下是数据比对映射关系：

测试二：SQL 兼容性及性能

针对生产的全量 SQL 语句进行兼容性以及性能的测试，靠人力手工完成测试是不现实的，所以我们引入了 Percona 开源的 playback 工具进行测试。

playback SQL 回放工具经验分享

playback 工具介绍

项目地址：https://github.com/Percona-Lab/query-playback.git

SQL 录制：MySQL 数据库在开启慢查询功能时，会将慢 SQL 输出到慢查询日志

SQL 回放：playback 工具解析慢查询文件中的 SQL，并连接到目标数据库进行回放

报告展示： 回放完成会输出报告（执行失败的 SQL 含结果不一致等、性能数据）

实际测试流程

由于我们是存在分库分表架构，而 TiDB 中存储的都是单表，所以我们步骤进行了一些调整：

SQL 录制：将生产 MySQL 库的 long_query_time 设置为 0，运行一个业务周期（一天），记录一天内所有 SQL（样本数越大测试结果越准确）

SQL 处理：部分慢查询日志未记录 schema 信息，通过脚本指定 schema（还存在将 db_1 映射成 db 这样的 schema 转换）

SQL 回放： 指定慢查询回放整个业务周期运行的 SQL 语句

回放结果分析

测试结果汇总

由于私域商城大表十分多，所以性能提升非常明显，2524 万条 SQL 的总执行时间约之前的 1/6；而会员运营之前进行过拆分，737 万条 SQL 的执行总时间约之前的 1/2。

错误详情分析：

无业务 SQL 错误，业务 SQL 均兼容

所有错误均为非业务 SQL：如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询，或慢查询格式调整时出现的一些格式错误等

1 处业务 SQL 错误：“during query: Data too long for column”，原因字段精度不够，调大后解决，其余业务 SQL 均兼容

剩余 1220855 次均为非业务 SQL 的报错：如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询，或慢查询格式调整时出现的一些格式错误等

会员运营：

私域商城：

兼容性基本没有问题

性能详情分析：

虽然总体执行时间缩短了，但我们还是需要排查下性能退化的 SQL 是哪些，需要保证原本正常的 SQL 还是要处于在一个基本对用户无感知的响应时间范围。

理论上来说，小于 100ms 的 SQL 基本都不影响前端用户的体验，所以分析时可以忽略这一部分的 SQL；而对于 100ms-1s 的 SQL，可能会影响用户体验，需要关注；1 秒以上 时基本上用户感知非常明显。

通过详细性能分析数据以及 SQL 回放执行总耗时，我们不难发现：

1. 由于 TiDB 是存储计算分离的分布式架构，1000us 内的 SQL 数很少，基础操作（如 show variables/start transaction/set ... 等）执行时间均高于 MySQL；同时另一个极端，大于 10 秒以上的 SQL 数，两个系统在 TiDB 中下降了一个数量级。

2. 通过一些采样分析，我们发现在 TiDB 中一些 commit/rollback 操作的时间也普遍高于 MySQL，个别操作从几百微秒变成几十 / 几百毫秒。查阅了 TiDB 中的事务机制，发现 TiDB 提交成本高于 MySQL，首先是 2PC 跨节点事务，另外就是事务中的脏数据直到 commit 时才开始刷到存储（计算节点 ->存储节点），对于这种类型的 SQL 在性能分析时也可以忽略掉。

3. 我们将样本数据整理成桑基图，将这部分性能退化、并且影响用户体验的 SQL 识别出来，进行分析和优化

以上为会员运营中 SQL 性能数据桑基图，如红色箭头以及红色框的这些 SQL，需要重点分析

以上为会员运营中原本 10 秒以上 SQL 性能变化

4. 私域商城的 SQL 性能提升很明显，100ms 内 SQL 数量均高于 MySQL，同时 1s 以上的 SQL 少于 MySQL，说明用户体验提升明显。但还是需要根据桑基图来分析是否存在异常的 SQL

以上为私域商城系统 SQL 性能桑基图，红框对应的 SQL 应该重点分析

以上为私域商城原本 10 秒以上 SQL 性能变化

测试三：资源隔离能力

资源隔离能力在我们这边的用途：

应用监控等定时调度操作往往比较复杂，如何限制其运行时的资源消耗

客户端数据查询场景难以避免 SQL 条件不规范的情况，当出现这种情况时，如何避免人工查询导致的系统不可用

当某个系统中出现一个大查询时，如何限制其资源消耗，避免对该应用、对整个集群造成影响

当某个系统中批量调度作业到白天还没跑完时，如何限制其资源消耗，避免对白天业务造成影响

系统间资源隔离：多个 MySQL 库上的应用系统合并到一个 TiDB 时，如何保障各个系统在业务高峰期的可用资源

系统内资源隔离：

其他场景的资源隔离

为解决以上几种问题，需要使用 TiDB 7.1 LTS 提供的 Resource Control 功能，该功能能够实现：

按用户设置资源规格

按会话设置资源规格

按 SQL 设置资源规格

以下是用户级别测试效果：

为数据库压测用户指定其 RU 为 500，并使用 Jmeter 压测应用，观察 TiDB 数据库是否能够限制资源，并且在达到资源限制时，应用是否报错。

该用户在达到 500RU 时，使用值轻微超过限制值，基本符合预期。

应用改造

分页 SQL 增加排序条件

这也是几乎所有的 MySQL 系统迁移到 TiDB 会遇到的问题：

当SQL 中无显示排序条件时，返回结果无顺序保障，这将导致分页结果不可靠

我们大概梳理了系统中存在的分页 SQL，大概 1600 余条，最终改造 + 测试工作量约 2 个月

性能退化的 SQL 优化

如特定的表关联方式，执行计划是全表扫描

改写成

从分库分表处理逻辑改成单库处理逻辑

业务 sql 中存在批量查询、批量更新的场景，调整成按照用户链接维度设置 batchquery

数据回写改造

应用切换到 TiDB 前，需要将 TiDB 的增量数据写回到 MySQL，保障紧急情况下的可回退：

之前是单库的场景，可以直接使用 TiCDC 提供的 mysql sink 完成回写。

分库分表的场景下，TiCDC 并不能直接写 MyCAT 组件；所以我们先将增量数据通过 TiCDC 发送给 Kafka，再消费写入到 MyCAT 下的分片中。

下游订阅改造

TiDB 不兼容 MySQL Binlog，原本的消息订阅链路（Binlog/canal/kafka）需要换成 TiCDC->Kafka 这条链路，TiCDC 提供 canal-json 格式的兼容，消费程序上要基于 TiCDC 的消息格式进行一定的调整。

生产切换效果

我们于双十一之前的两周完成消息中心等系统（4 个 MySQL 库）的切换，切换到 TiDB 后经受住了双十一大批量消息推送的验证，也增强了我们的信心。

在元旦后第一个工作日进行了私域商城系统（16 个 MySQL 库）的切换，切换过程比较顺利。以下是切换后第一个工作日的业务高峰，最大 QPS 4.4 万，P95 响应延迟 3.9ms，整体运行良好。

1.8 日某品牌大促，业务量是平时的一倍，数据库最大 QPS 6.5 万，P95 响应延迟 3.9-4.5ms 之间：

以下是切换 TiDB 的整体流程，可以看到切换到 TiDB 后了简化了其架构：由于 TiDB 无需设置分片规则，数据都在一个集群中，原本综合库（MySQL 单库）上的查询也直接切到 TiDB

以上为生产切换流程

总结

数据库迁移是一个复杂且高风险的工程，迁移前规划一个全面的测试方案必不可少，提前识别迁移风险，大幅降低迁移后的风险，当然像分阶段迁移、回退链路等保障措施也及其重要。

年后我们将继续把会员运营系统（20 个 MySQL 库）切换至 TiDB，实现 To C 系统从 MySQL 40 个库到 TiDB 的整体切换，支撑未来持续增长的数据规模。

阿毛哥与 TiDB 的成长故事探索顶级贡献者的旅程

Wed, 01 May 2024 10:05:26 +0800

大家好，我是毛康力，来自 PinCAP 的研发工程师。我的 github ID 是 tiancaiamao，目前在 TiDB 仓库的 commit 数排名在 top1。在 TiDB 相关的各个项目总计 PR 贡献累计超过 1000 了。

相遇

我在 TiDB 仓库的第一个 pr 应该是 2016 年的 6 月 21 号。因为工作原因，我在 2016 年 4 月份加入了 PingCAP，先是在 tikv 那边干了一阵子，但是写 Rust 不太习惯，然后就转到 TiDB 这边写 Go 了。对我自己来说，还是 Go 语言写起来比较舒适。再接下来就是持续的给 TiDB 提 PR 了，这一干就是持续好多年。

选择加入 PingCAP

我接触 Go 语言比较早，而早期使用 Go 语言的公司并不算多，PingCAP 是其中之一。然后也有关注到 TiDB 这样的 Go 语言实现的"明星"项目。

一个契机是，早期的活跃的 Go 语言用户同样也不算多，我自己有写博客的习惯，当时主要是一些关于 Go 方面的内容，东旭正好通过博客关注到我，于是就约着聊聊。就这样擦出了火花，于是我就来贵司了。

最初我是在广州的，而 PingCAP 在北京，所以对于换城市会有一定的顾虑。而正好 PingCAP 的文化是支持 remote 的，这点就非常有吸引力了。站在现在的角度看，虽然作为一个老司机，我已经 remote 好多年了，习以为常。但是当时还是挺震憾的，文化上非常的开放和自由，宽松的工作氛围，追求结果而关注过程。

现在 PingCAP 在全国几个大城市有了 office，海外也加入了不少同事。一个 team 可能遍布在好几个地方，并不能大家都在一个办公室，有事吼一嗓子，或者直接去工位找某某某。其实大家也都习惯了"线上"协作的模式，提 PR，review PR，线上会议等等，这都是跟开源的协作模式很契合的。

像我所在的团队就有分布在国内几个城市，以及在欧洲和北美。导致一个问题是，跨越了多个时区，开会聚集不到所有人。处理方式就是，比如今天由国内跟欧洲开会，明天再国内同步到北美那边。由于分布在不同的城市，一个 team 的同事可能都没线下见过，如果 team building 聚一聚时，会发现大家可能相互 review 过 PR 和线上讨论过问题，但是却又还"不认识"对方，于是我们戏称为 "网友见面"。

谈一谈 TiDB 贡献者们

TiDB 贡献者们来自各行各业，也都有着不一样的身份，但是他们都有一个共同的身份，就是 TiDB contributor 。

比如说有学生。尤其是有些国内排名靠前的大学，学生都很猛的，还没毕业就早早关注到一些开源项目，并参与贡献一些 PR。像我自己毕业时的那个年代，对于开源项目这些东西都还没有什么概念。现在实在是太"卷"了，没有一些开源项目的贡献，大公司实习之类的经历，可能简历关都过不了。我时常调侃，还好加入得早，要不然如果是换成他们先进来，再来面试我，我就被他们拍死在沙滩上了。

关于学生这块，我们有时候也组织一些面向高校的活动。比如说 TiDB-challenge-program 的活动，也是会吸引一些高校学生参加。我们会发布一些特定的小项目，我自己作为 mentor 带过一些，感觉真的是很优秀的同学，对比一下由开源这一块吸引到的贡献者，比简历投递过来的质量往往要高不少。所以这也是招聘的一个很好的来源。早些年，我们会给 TiDB 贡献过代码的外部贡献者发一些小礼物，比如说有送件文化杉啥的。如果发现了穿着我们送的文化衫的"野生"贡献者，要赶紧拉住要简历。因为公司内推是有奖励的，所以这种人被我们称之为 "行走的 iPhone"。

扯远了...说回 TiDB 贡献者的背景，除了学生，也有来自学术界的。印象很深的一个是 Samuel，是一个国外的大学教授。开发了一个 Squirrel 的测试工具，发了篇论文，里面用到了一些模糊测试的方法，在 TiDB 上面验证过，帮我们挖了不少 bug 出来。再后来，他有个博士生，github ID 是 bajinsheng。在 Samuel 的基础上继续深入，做了个叫 sqlance 的工具，也给我们找了好多 bug。工具太厉害了，效率很高，一个人的战斗力超过一个团队。那阵子他比我们自己的 QA 整个团队加起来找得 bug 都还要多。github issue 里面搜 label:fuzz/sqlancer 可以看到这些记录。贡献不一定是单指代码，像这种帮忙找 bug 发现问题，也是一种形式的贡献。

类似的还有 TAOBench 作者，也是有一篇 paper 的，他们构建一个性能测试的工具，里面的实验验证有用到 TiDB 和其它几款数据库产品的对比。这些研究工作对我们的产品性能提升会有帮助，后来我们内部也把这些成果纳入了我们 benchmark 测试的 workload 里面，日常跑着。严格来说 TAOBench 作者是来自 facebook 的，应该算是工业界了，但因为论文的关系，我还是归到学术界这边。

至于工业界，来自于这块的贡献就更大了。我们的不少的 committer 都是来自外部公司的。说明一下，给 TiDB 提过 PR 这种我们叫 contributor，当 contributor 持续提一些 PR，对某个模块具备足够的了解之后，我们会提名为 reviewer。足够活跃并且对整个 TiDB 做出了比较大的贡献之后，我们才会提名 committer。像 SpeedCloud 的李雨来就是为我们贡献了最初版本的 plan cache 的实现，于是成为了 commiter 的。还有晓光老师也是我们的 committer，之前是在知乎。在 PingCAP 内部，其实也是同样的流程，要一步一步提 PR 才从 contributor 到 committer 或者 maintainer，这点对公司员工跟外部贡献者并没有区别。

有很多公司在用 TiDB，会给 TiDB 发现一些 bug，有些是提 issue，有些就直接 PR 甩上来的。尤其是互联网公司，都是很有这种直接"撸起袖子就干"的风格的。于是这些用户也就成了我们的贡献者。

从地域角度来说，贡献者来自全世界的都有，虽然国内的更多一些。记得一个很好玩的事情是，以前有个俄罗斯的小哥，给我们提过 PR。我说过，我们当时都会给贡献者送些小礼物啥的，然后我们同事就联系到人家，说给寄点东西过去。对方持着很怀疑的态度，在担心我们是骗子或者是在套他的个人信息啥的。最后我们真的把礼物寄到俄罗斯了，小哥表示非常惊奇，也很高兴能收到礼物。虽然不是什么值钱的东西，这算是一种公司文化吧，我们一直是非常重视开发者的。

TiDB 代码贡献之路

我们的开发活动都是在 github 上面，公开透明。整体上看，日常的 workflow 都是围绕着 issue 和 PR 展开的。如果是简单的场景，直接提 PR(pull request) 就行了。PR 一般是需要得到两个 reviewer 以上的角色的 approve 之后，就可以将代码合入到 master 主干分支。

如果是对于复杂一些的场景，比较说开发一个新的 feature，流程上需要有文档，设计和讨论。内容也会以 issue 之类的形式放在 github 上面。比如说参见临时表的开发过程。

我想说的是，这一切都是对外开放的，真正的开源协作的模式。

用户的需求

github 上面的 issue 更加面向研发一点。如果是对于普通的用户，可以到 AskTUG 上面提问，这是一个属于用户群组的社区。

我们会收集用户的反馈，需求一般是几类来源，一类是这种社区的呼声比较高的问题。再一类是从企业版客户那边，在使用过程中得到的反馈。还有一些比如某些重要的 PoC，客户看中某一块的能力，我们还没支持。

PM 会整理这些需求，然后按优先级排期，研发这边会不断地改进产品。产品会不停地迭代，每个小版本我们都会有一些 feature 或者改进带出去，小步快跑的模式发布。

隔一定的时间，我们会发一个大版本，大版本往往都是带了比较重大的 feature 或者改动。现在我们会有 LTS(long term support) 的版本，追求稳定可以随 LTS 版本升级，而想快速尝鲜或者是等待某个新 feature 的用户可以用非 LTS 的版本。这样同时保证了稳定和快速迭代，满足不同场景的用户需求。

收获

我自己算是跟随 TiDB 一起在成长吧。早期的 TiDB 代码规模比较小，团队也没有划分得很细，每个人都会涉及许多个模块，这样基本上可以熟习整体架构和所有的模块。你可以在 parser，事务，分区表，DDL，优化器，执行器等等几乎所有角落看到我的代码提交记录(哈哈)。现在的团队划分更细了，专注各自的模块，可能就没有我当时那么好的学习的机会了。

除了涉及到的技术层面，我觉得一个很重要的收获是作为一个工程师的综合能力。这个听起来就比较虚了，只有经历过，才知道怎么样维护这么大一个开源项目。怎么样保证产品质量，并且可控地迭代。如何与他人协作去推进一个事情。大公司里面可能会有一些测试和 review 的规范化的流程，但是规范程度很难达到这种大型开源项目的标准。通过每一个 PR 提交细节，就可以看到这些工作的严谨。开源的项目可以知道谁，在某一次提交做了什么，被全世界所有的眼睛盯着，所有不规范的行为，都是被钉在耻辱柱上的。

开源文化

我觉得开源一定是要形成一个社区。把代码放出来，然后不管了，那样不叫开源。但有些公司就是喜欢这么玩，内部的产品竞争中败下阵来，于是直接把源代码往 github 一扔，就号称开源了。完全看不到后续 PR 和更新，也没有人在回答问题和解决 issue。

开源的概念火了起来，有些基础软件赛道的创业公司，PE 估值很高。就会有些人跟着蹭一波热度，这都是把开源当噱头，这都是假开源。更过火的甚至出现了某公司，做活动推广刷星，只要给他们 github 项目仓库点赞就送礼物。这种形式做出来的 star，对产品本身是毫无意义的。当然，如果投资人傻的话，也许给投资人看可以糊弄下: “你看，我们涨星趋势比当初的 TiDB 还要猛”。把开源当 KPI 来做，那肯定是做不成的。

不对的人对开源的文化有不同的理解。比如以 GPL 协议作为切入点来看，这是一个"病毒"传播协议，使用它的代码会被感染，也要求按 GPL 协议开源。但它确实是反技术垄断，打破专利壁垒的有效武器。对比一下，某头号数据库厂商，一个据说律师比程序多的公司，具体做了哪些贡献是推动技术进步，时代发展并且让所有人受益的事呢？源码在手，就意味着自由，而不是封闭，free! free 是自由，而不是免费的意思。也有像 MIT 这类的协议，放弃了对软件的诸多权利，这跟 GPL 不太一样，但在 free 这点上都是共通的。

不同的时期，推动开源运动的主力也在变化。早期更多一些个人英雄主义的开源项目。现在更多的是机构和大公司在主导着开源项目。这里面其实也有些利益的因素，是否拥抱开源，跟公司的认知有很大关联。

如果一个公司觉得，代码是核心资产，开源是劣势，会导致竞争对手抄袭自己的代码，从而后来居上，那么他就应该选择闭源。如果一个公司觉得，开发者才是核心资产，那他应该打造一个开放的社区，吸引到更多的贡献者，让这个社区变得更活跃，更强大，从而产品也能更完善。因为抄代码是好抄，但是构建一个活跃的社区却是有很高的壁垒的。

当然，也会有一些分裂社区的行为，比如说，如果一个公司觉得既然代码都开放了，那么何不 fork 过来，再自己改一套，然后闭源卖企业版或者啥的。这么做完全可以，只要没违反相应的开源协议。事情背后的本质，变成了这家公司，对抗整个社区的游戏。如果它的投入够大，它的迭代速度比原始项目更快，产品做得更好，用户就会吸引到它的阵营来。只是这个过程代价很大，需要这家公司的投入，大于整个社区的其它公司和个人贡献者的投入总和。

为了防止分裂，最好的做法就是让社区更活跃，参与者更多，由多家公司来一起推动。使得分裂社区的成本由单个公司无力承担。最后要么选择加入，要么对抗并失败。开源的规则就是这样玩的。有一个典型的例子就是 chromium，软件的复杂性使得没有哪一家公司能 fork 一个出去，然后自己另起炉灶的。一旦形成了事实标准之后，项目牵头的公司成为最大的受益者，属于是阳谋了。再比如 android 的例子，只有构建好生态，才能有无数的贡献者参与进来，写驱动，写 app，写各种东西，然后整体生态越来越强大。

从这个角度，我觉得开源的文化，就是反映人背后的认知。最终符合生产力发展规律的事物，会取得最后的胜利。相比于闭源/假开源，一开始就坚定选择开源的人，格局简直是在大气层了。

建议

如果说给最其他打算成为 TiDB 贡献者的人一些建议？硬核的方式，当然是 read the f*cking source code 啦。读代码的过程中，发现有什么问题可以在 github 提出 issue 讨论，或者代码方面有改进的点可以提 PR。读代码适合有一定基础，并且喜欢这种风格的程序员。

更平滑一些的方式，可以先从一些文档开始学习，了解一下系统的整体架构，官网的博客就是一个比较好的学习资源。有大概的熟习之后，可以从一些小的 PR 开始做起，在 TiDB 的 issue 里面搜索带 help wanted 标签的 issue，一般是比较适合于新人上手的。至于怎么提 PR，在项目的 README 里面有一块 How to contribute。

关键是参与进来，接受反馈并不断学习，相信 TiDB 一定会让贡献者有很好的收获的。

配置 webhook 告警在 TiDB 实践

Wed, 01 May 2024 10:00:21 +0800

prometheus-webhook 是对alertmanager 告警的一个扩展，支持钉钉，微信，邮件告警和自建告警模板

1、配置告警

1、下载并解压告警安装包

#下载

wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v2.1.0/prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz

#解压

tar -zxvf prometheus-webhook-dingtalk-2.1.0.linux-amd64.tar.gz

[tidb@vm172-16-201-64 prometheus-webhook-dingtalk-2.1.0.linux-amd64]$ ll

总用量 18744

-rw-r--r-- 1 tidb tidb 1299 4月 21 16:20 config.example.yml

drwxr-xr-x 4 tidb tidb 4096 4月 21 16:20 contrib

-rw-r--r-- 1 tidb tidb 11358 4月 21 16:20 LICENSE

-rwxr-xr-x 1 tidb tidb 19172733 4月 21 16:19 prometheus-webhook-dingtalk

[tidb@vm172-16-201-64 prometheus-webhook-dingtalk-2.1.0.linux-amd64]$

2、配置webhook启动脚本

more /data/webhook-dingtalk/webhook-dingtalk.sh

#!/bin/bash

set -e

WEBHOOK_BIN=/data/webhook-dingtalk/prometheus-webhook-dingtalk

exec $WEBHOOK_BIN \

--web.listen-address=":8060" \

--config.file="/data/webhook-dingtalk/jms_config.yml" \

--log.level="info" \

--log.format="logfmt" \

--web.enable-lifecycle \

--web.enable-ui \

3、配置webhook 配置文件

more /data/webhook-dingtalk_config.yml

## Request timeout

# timeout: 5s

## Uncomment following line in order to write template from scratch (be careful!)

#no_builtin_template: true

## Customizable templates path

#templates:

# - contrib/templates/legacy/template.tmpl

## You can also override default template using `default_message`

## The following example to use the legacy template from v0.3.0

#default_message:

# title: {{ template "legacy.title" . }}

# text: {{ template "legacy.content" . }}

## Targets, previously was known as "profiles"

targets:

webhook1:

# secret for signature

secret: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#webhook2:

webhook_legacy:

secret: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

# Customize template content

message:

# Use legacy template

title: {{ template "legacy.title" . }}

text: {{ template "legacy.content" . }}

#webhook_mention_all:

# mention:

# all: true

webhook_mention_users:

secret: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

mention:

mobiles: [XXXXXXXXXXXX]

4、配置alertmanager.yml

more /data/dm-deploy/alertmanager-9093/conf/alertmanager.yml

global:

# The smarthost and SMTP sender used for mail notifications.

smtp_smarthost: "localhost:25"

smtp_from: "alertmanager@example.org"

smtp_auth_username: "alertmanager"

smtp_auth_password: "password"

# smtp_require_tls: true

# The Slack webhook URL.

# slack_api_url:

route:

# A default receiver

receiver: "webhook"

# The labels by which incoming alerts are grouped together. For example,

# multiple alerts coming in for cluster=A and alertname=LatencyHigh would

# be batched into a single group.

group_by: ["env", "instance", "alertname", "type", "group", "job"]

# When a new group of alerts is created by an incoming alert, wait at

# least group_wait to send the initial notification.

# This way ensures that you get multiple alerts for the same group that start

# firing shortly after another are batched together on the first

# notification.

group_wait: 30s

# When the first notification was sent, wait group_interval to send a batch

# of new alerts that started firing for that group.

group_interval: 3m

# If an alert has successfully been sent, wait repeat_interval to

# resend them.

repeat_interval: 3m

routes:

# - match:

# receiver: webhook-kafka-adapter

# continue: true

# - match:

# env: test-cluster

# receiver: db-alert-slack

# - match:

# env: test-cluster

# receiver: db-alert-email

#配置的IP地址就是部署webhook的机器地址

receivers:

- name: webhook

webhook_configs:

- send_resolved: true

url: http://XX.XX.XX.:8060/dingtalk/webhook1/send

#- name: db-alert-slack

# slack_configs:

# - channel: #alerts

# username: db-alert

# icon_emoji: :bell:

# title: {{ .CommonLabels.alertname }}

# text: {{ .CommonAnnotations.summary }} {{ .CommonAnnotations.description }} expr: {{ .CommonLabels.expr }} http://1

72.0.0.1:9093/#/alerts

# - name: "db-alert-email"

# email_configs:

# - send_resolved: true

# to: "example@example.com"

# This doesnt alert anything, please configure your own receiver

#- name: "blackhole"

5、配置开机启动脚本

more /etc/systemd/system/prometheus-webhook.service

[Unit]

Description=prometheus-webhook service

After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]

LimitNOFILE=1000000

LimitSTACK=10485760

User=tidb

ExecStart=/data/webhook-dingtalk/webhook-dingtalk.sh

Restart=always

RestartSec=15s

[Install]

WantedBy=multi-user.target

6、启动webhook

#启动webhook

sudo systemctl start prometheus-webhook.service

#停止webhook

sudo systemctl stop prometheus-webhook.service

#查看服务状态

sudo systemctl status -l prometheus-webhook.service

7、重启alertmanager让告警生效

tiup clutster stop tidb-test -N x:9093

tiup clutster start tidb-test-N x:9093

#查看启动后状态

tiup clutster display tidb-jms -N x:9093

8、告警展示

[FIRING:1] tidb_tikvclient_backoff_seconds_count

Alerts Firing

TiDB tikvclient_backoff_count error

Description: cluster: tidb-test, instance: xxxx:10081, values:253.33333333333331

Graph:

Details:

alertname: tidb_tikvclient_backoff_seconds_count

cluster: tidb-test

env: tidb-test

expr: increase( tidb_tikvclient_backoff_seconds_count[10m] ) > 10

instance: xxxx:10081

job: tidb

level: warning

monitor: prometheus

type: regionMiss

9、注意事项

需要注意的是，TiUP 会使用自己的配置参数覆盖监控组件的配置，如果你直接修改监控组件的配置文件，修改的配置文件可能在对集群进行 deploy/scale-out/scale-in/reload 等操作中被 TiUP 所覆盖，导致配置不生效。

alertmanager_servers

config_file：该字段指定一个本地文件，该文件会在集群配置初始化阶段被传输到目标机器上，作为 Alertmanager 的配置

Plain Text

alertmanager_servers:

- host: 172.16.201.64

ssh_port: 22

web_port: 9093

cluster_port: 9094

deploy_dir: /data1/tidb-deploy/alertmanager-9093

data_dir: /data1/tidb-data/alertmanager-9093

log_dir: /data1/tidb-deploy/alertmanager-9093/log

arch: amd64

os: linux

config_file: /data1/tidb-deploy/alertmanager-9093/conf/alertmanager_test.yml

2、修改告警

1、到prometheus的conf 目录下找到对应的告警项

[tidb@vm172-16-201-64 ~]$ cd /data/tidb-deploy/prometheus-9090/conf/

[tidb@vm172-16-201-64 conf]$ ll

总用量 96

-rw-r--r-- 1 tidb tidb 3500 6月 28 15:34 binlog.rules.yml

-rw-r--r-- 1 tidb tidb 4492 6月 28 15:34 blacker.rules.yml

-rw-r--r-- 1 tidb tidb 37 6月 28 15:34 bypass.rules.yml

-rw-r--r-- 1 tidb tidb 1964 6月 28 15:34 kafka.rules.yml

-rw-r--r-- 1 tidb tidb 459 6月 28 15:34 lightning.rules.yml

-rw-r--r-- 1 tidb tidb 507 6月 28 15:34 ngmonitoring.toml

-rw-r--r-- 1 tidb tidb 5214 6月 28 15:34 node.rules.yml

-rw-r--r-- 1 tidb tidb 7920 6月 28 15:34 pd.rules.yml

-rw-r--r-- 1 tidb tidb 6199 6月 28 15:34 prometheus.yml

-rw-r--r-- 1 tidb tidb 6507 6月 28 15:34 ticdc.rules.yml

-rw-r--r-- 1 tidb tidb 6271 6月 28 15:34 tidb.rules.yml

-rw-r--r-- 1 tidb tidb 3112 6月 28 15:34 tiflash.rules.yml

-rw-r--r-- 1 tidb tidb 4685 6月 28 15:34 tikv.accelerate.rules.yml

-rw-r--r-- 1 tidb tidb 13977 6月 28 15:34 tikv.rules.yml

[tidb@vm172-16-201-64 conf]$

2、备份相应的文件，修改告警项

cp tidb.rules.yml tidb.rules.yml_20220628

vi tidb.rules.yml

3、重启prometheus，让修改生效

Plain Text

tiup clutster stop tidb-jms -N x:9090

tiup clutster start tidb-jms -N x:9090

#查看启动后状态

tiup clutster display tidb-jms -N x:9090

4、临时静默

https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/alert/alert-manager-inhibit

用户或者管理员可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式)，如果新的告警通知满足静默规则的设置，则停止向receiver发送通知。

进入Alertmanager UI，点击"New Silence"显示如下内容：

1、创建静默规则

用户可以通过该UI定义新的静默规则的开始时间以及持续时间，通过Matchers部分可以设置多条匹配规则(字符串匹配或者正则匹配)。填写当前静默规则的创建者以及创建原因后，点击"Create"按钮即可。

通过"Preview Alerts"可以查看预览当前匹配规则匹配到的告警信息。静默规则创建成功后，Alertmanager会开始加载该规则并且设置状态为Pending,当规则生效后则进行到Active状态。

活动的静默规则

当静默规则生效以后，从Alertmanager的Alerts页面下用户将不会看到该规则匹配到的告警信息。

告警信息

对于已经生效的规则，用户可以通过手动点击”Expire“按钮使当前规则过期。

配置 TiDB 集群故障自动转移的 TiDB Operator 教程

Wed, 01 May 2024 00:00:09 +0800

TiDB Operator基于statefulset管理pod 的部署和扩缩容,但statefulset在某些Pod或者节点发生故障时不会自动创建新Pod来替换旧Pod。为此，TiDB Operator支持通过自动扩容Pod实现故障自动转移功能。

实现原理

TiDB 集群包括 PD、TiKV、TiDB、TiFlash、TiCDC 和 Pump 六个组件。目前 TiCDC 和 Pump 并不支持故障自动转移，PD、TiKV、TiDB 和 TiFlash 的故障转移策略会有所不同。

PD故障转移

TiDB Operator 通过 pd/healthPD API 获取 PD members 健康状况，并记录到 TidbCluster CR 的.status.pd.members 字段中。

以一个有 3 个 Pod 的 PD 集群为例，如果其中一个 Pod 不健康超过 5 分钟（pdFailoverPeriod 可配置），TiDB Operator 将自动进行以下操作：

TiDB Operator 将此 Pod 信息记录到 TidbCluster CR 的 .status.pd.failureMembers 字段中。通过describe进行查询，如下图一

TiDB Operator 将此 Pod 下线：TiDB Operator 调用 PD API 将此 Pod 从 member 列表中删除，然后删掉 Pod 及其 PVC，如下图二。

StatefulSet controller 会重新创建此 Pod 并以新的 member 身份加入集群,如图三。

在计算 PD StatefulSet 的 Replicas 时，TiDB Operator 会将已经被删除过的 .status.pd.failureMembers 考虑在内，因此会扩容一个新的 Pod。此时将有 4 个 Pod 同时存在，如图四。

当原来集群中所有不健康的 Pod 都恢复正常时，TiDB Operator 会将新扩容的 Pod 自动缩容掉，恢复成原来的 Pod 数量，图五。

注意

TiDB Operator 会为每个 PD 集群最多扩容 spec.pd.maxFailoverCount (默认 3) 个 Pod，超过这个阈值后不会再进行故障转移。

如果 PD 集群多数 member 已经不健康，导致 PD 集群不可用，TiDB Operator 不会为这个 PD 集群进行故障自动转移。

图一

图二

图三

图四

图五

TiDB故障转移

TiDB Operator 通过访问每个 TiDB Pod 的 /status 接口确认 Pod 健康状况，并记录到 TidbCluster CR 的 .status.tidb.members 字段中。

用一个有 2 个 Pod 的 TiDB 集群为例，如果一个 Pod 不健康超过 5 分钟（tidbFailoverPeriod 可配置），TiDB Operator 将自动进行以下操作：

TiDB Operator 将此 Pod 信息记录到 TidbCluster CR 的 .status.tidb.failureMembers 字段中。

在计算 TiDB StatefulSet 的 Replicas 时，TiDB Operator 会将 .status.tidb.failureMembers 考虑在内，因此会扩容一个新的 Pod。此时会有 3 个 Pod 同时存在。

当原来集群中不健康的 Pod 恢复正常时，TiDB Operator 会将新扩容的 Pod 缩容掉，恢复成原来的 2个 Pod。

注意

TiDB Operator 会为每个 TiDB 集群最多扩容spec.tidb.maxFailoverCount (默认 3) 个 Pod，超过这个阈值后不会再进行故障转移。

TiKV故障转移

TiDB Operator 通过访问 PD API 获取 TiKV store 健康状况，并记录到 TidbCluster CR 的 .status.tikv.stores 字段中。

以一个有 3 个 Pod 的 TiKV 集群为例，当一个 TiKV Pod 无法正常工作时，该 Pod 对应的 Store 状态会变为 Disconnected。默认 30 分钟（可以通过 pd.config 中 [schedule] 部分的 max-store-down-time = "30m" 来修改）后会变成 Down 状态，然后 TiDB Operator 将自动进行以下操作：

在此基础上再等待 5 分钟（可以通过 tikvFailoverPeriod 配置），如果此 TiKV Pod 仍未恢复，TiDB Operator 会将此 Pod 信息记录到 TidbCluster CR 的 .status.tikv.failureStores 字段中。

在计算 TiKV StatefulSet 的 Replicas 时，TiDB Operator 会将 .status.tikv.failureStores考虑在内，因此会扩容一个新的 Pod。此时会有 4 个 Pod 同时存在。

当原来集群中不健康的 Pod 恢复正常时，考虑到缩容 Pod 需要迁移数据，可能会对集群性能有一定影响，TiDB Operator 并不会将新扩容的 Pod 缩容掉，而是继续保持 4 个 Pod。

注意

TiDB Operator 会为每个 TiKV 集群最多扩容 spec.tikv.maxFailoverCount (默认 3) 个 Pod，超过这个阈值后不会再进行故障转移。

TiFlash故障转移

TiDB Operator 通过访问 PD API 获取 TiFlash store 健康状况，并记录到 TidbCluster CR 的 .status.tiflash.stores 字段中。

以一个有 3 个 Pod 的 TiFlash 集群为例，当一个 TiFlash Pod 无法正常工作时，该 Pod 对应的 Store 状态会变为Disconnected。默认 30 分钟（可以通过 pd.config 中 [schedule] 部分的 max-store-down-time = "30m" 来修改）后会变成 Down 状态，然后 TiDB Operator 将自动进行以下操作：

在此基础上再等待 5 分钟（tiflashFailoverPeriod 可配置），如果此 TiFlash Pod 仍未恢复，TiDB Operator 会将此 Pod 信息记录到 TidbCluster CR 的 .status.tiflash.failureStores 字段中。

在计算 TiFlash StatefulSet 的 Replicas 时，TiDB Operator 会将 .status.tiflash.failureStores 考虑在内，因此会扩容一个新的 Pod。此时会有 4 个 Pod 同时存在。

当原来集群中不健康的 Pod 恢复正常时，考虑到缩容 Pod 需要迁移数据，可能会对集群性能有一定影响，TiDB Operator 并不会将新扩容的 Pod 缩容掉，而是继续保持 4 个 Pod。

注意

TiDB Operator 会为每个 TiFlash 集群最多扩容 spec.tiflash.maxFailoverCount (默认 3) 个 Pod，超过这个阈值后不会再进行故障转移。

配置故障转移

故障自动转移功能在TiDB Operator中默认开启。

TiDB Operator关于故障转移的配置

部署TiDB Operator时，可以在charts/tidb-operator/values.yaml文件中配置，TiDB 集群中 PD、TiKV、TiDB 和 TiFlash 组件故障转移的等待超时时间。示例如下：

其中，pdFailoverPeriod、tikvFailoverPeriod、tiflashFailoverPeriod 和 tidbFailoverPeriod代表在确认实例故障后的等待超时时间，默认均为 5 分钟。超过这个时间后，TiDB Operator 就开始做故障自动转移。

TiDB集群关于故障转移的配置

在配置 TiDB 集群时，可以通过 spec.${component}.maxFailoverCount 指定 TiDB Operator 在各组件故障自动转移时能扩容的 Pod 数量阈值。当 PD、TiDB、TiKV、TiFlash 这些组件的 Pod 或者其所在节点发生故障时，TiDB Operator 会触发故障自动转移，通过扩容相应组件补齐 Pod 副本数。

为避免故障自动转移功能创建太多 Pod，可以为每个组件配置故障自动转移时能扩容的 Pod 数量阈值，默认为 3。如果配置为0，代表关闭这个组件的故障自动转移功能。配置示例如下：

pd: maxFailoverCount: 3 tidb: maxFailoverCount: 3 tikv: maxFailoverCount: 3 tiflash: maxFailoverCount: 3

具体集群实例如下：

注意

对于以下情况，请显式设置 maxFailoverCount: 0：

集群中没有足够的资源以供 TiDB Operator 扩容新 Pod。该情况下，扩容出的 Pod 会处于 Pending 状态。

不希望开启故障自动转移功能。

关闭故障转移

集群级别关闭故障自动转移功能

在部署 TiDB Operator 时，请将 charts/tidb-operator/values.yaml 文件的 controllerManager.autoFailover 字段值配置为 false

controllerManager: ... # autoFailover is whether tidb-operator should auto failover when failure occurs autoFailover: false

组件级别关闭故障自动转移功能

组件级别关闭故障自动转移功能，在创建 TiDB 集群时，可以将 TidbCluster CR 中对应组件的 spec.${component}.maxFailoverCount 字段值配置为 0。

sped: ... pd: maxFailoverCount:0 tidb: maxFailoverCount: 0 tikv: maxFailoverCount: 0 tiflash: maxFailoverCount: 0

配置 TiDB Operator 实现高可用集群

Tue, 30 Apr 2024 10:16:06 +0800

TiDB Operator 提供了自定义的调度器，该调度器通过指定的调度算法能在 host 层面保证 TiDB 服务的高可用。目前，TiDB 集群使用该调度器作为默认调度器，可通过 spec.schedulerName 配置项进行设置。本节重点介绍如何配置 TiDB 集群以容忍其他级别的故障，例如机架、可用区或 region。

TiDB 是分布式数据库，它的高可用需要做到在任一个物理拓扑节点发生故障时，不仅服务不受影响，还要保证数据也是完整和可用。因此TiDB的高可用需要从Tidb服务高可用和数据的高可用进行说明。

TiDB服务高可用

通过 nodeSelector 调度实例

通过各组件配置的 nodeSelector 字段，可以约束组件的实例只能调度到特定的节点上。关于 nodeSelector 的更多说明，请参阅K8S官方说明 nodeSelector。

apiVersion: pingcap.com/v1alpha1 kind: TidbCluster # ... spec: pd: nodeSelector: node-role.kubernetes.io/pd: true # ...tikv: nodeSelector: node-role.kubernetes.io/tikv:true # ... tidb: nodeSelector: node-role.kubernetes.io/tidb: true # ...

通过 tolerations 调度实例

通过各组件配置的 tolerations 字段，可以允许组件的实例能够调度到带有与之匹配的污点 (Taint) 的节点上。关于污点与容忍度的更多说明，请参阅 Taints and Tolerations。

apiVersion: pingcap.com/v1alpha1 kind: TidbCluster # ... spec: pd: tolerations: - effect: NoSchedule key: dedicated operator: Equal value: pd # ... tikv: tolerations: - effect: NoSchedule key: dedicated operator: Equal value: tikv # ... tidb: tolerations: - effect: NoSchedule key: dedicated operator: Equal value: tidb # ...

通过 affinity 调度实例

配置 PodAntiAffinity 能尽量避免同一组件的不同实例部署到同一个物理拓扑节点上，从而达到高可用的目的。关于 Affinity 的使用说明，请参阅 Affinity & AntiAffinity。

下面是一个典型的高可用设置例子：

affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution:# this term works when the nodes have the label named region - weight: 10 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/instance: ${cluster_name} app.kubernetes.io/component: "pd" topologyKey: "region" namespaces: - ${namespace} # this term works when the nodes have the label named zone - weight: 20 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/instance: ${cluster_name} app.kubernetes.io/component: "pd" topologyKey: "zone" namespaces: - ${namespace} # this term works when the nodes have the label named rack - weight: 40 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/instance: ${cluster_name} app.kubernetes.io/component: "pd" topologyKey: "rack" namespaces: - ${namespace} # this term works when the nodes have the label named kubernetes.io/hostname - weight: 80 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/instance: ${cluster_name} app.kubernetes.io/component: "pd" topologyKey: "kubernetes.io/hostname"namespaces: -${namespace}

通过 topologySpreadConstraints 实现 Pod 均匀分布

配置 topologySpreadConstraints 可以实现同一组件的不同实例在拓扑上的均匀分布。具体配置方法请参阅 Pod Topology Spread Constraints。

如需使用 topologySpreadConstraints，需要满足以下条件：

Kubernetes 集群使用 default-scheduler，而不是 tidb-scheduler。详情可以参考 tidb-scheduler 与 default-scheduler。

Kubernetes 集群开启 EvenPodsSpread feature gate。如果 Kubernetes 版本低于 v1.16 或集群未开启 EvenPodsSpread feature gate，topologySpreadConstraints 的配置将不会生效。

topologySpreadConstraints 可以设置在整个集群级别 (spec.topologySpreadConstraints) 来配置所有组件或者设置在组件级别 (例如 spec.tidb.topologySpreadConstraints) 来配置特定的组件。

[root@k8s-master tidb]# cat tidb.yamlapiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: lqb namespace: tidb spec: version:"v6.1.0" timezone: Asia/Shanghai hostNetwork: falseimagePullPolicy: IfNotPresent enableDynamicConfiguration:true configUpdateStrategy: RollingUpdate ###Pod 拓扑分布约束，以主机名或区域为准，该配置能让同一组件的不同实例均匀分布在不同 zone 和节点上。 topologySpreadConstraints: - topologyKey: kubernetes.io/hostname - topologyKey: topology.kubernetes.io/zone pd: .... tidb ... tikv

当前 topologySpreadConstraints 仅支持 topologyKey 配置。在 Pod spec 中，上述示例配置会自动展开成如下配置：

topologySpreadConstraints: - topologyKey: kubernetes.io/hostname maxSkew: 1 whenUnsatisfiable: DoNotSchedule labelSelector: <object> - topologyKey: topology.kubernetes.io/zone maxSkew: 1 whenUnsatisfiable: DoNotSchedule labelSelector: <object>

数据的高可用

在 Kubernetes 上支持数据高可用的功能，需要如下操作：

为 PD 设置拓扑位置 Label 集合

用 Kubernetes 集群 Node 节点上描述拓扑位置的 Label 集合替换 pd.config 配置项中里的 location-labels 信息。

为 TiKV 节点设置所在的 Node 节点的拓扑信息

TiDB Operator 会自动为 TiKV 获取其所在 Node 节点的拓扑信息，并调用 PD 接口将这些信息设置为 TiKV 的 store labels 信息，这样 TiDB 集群就能基于这些信息来调度数据副本。

如果当前 Kubernetes 集群的 Node 节点没有表示拓扑位置的 Label，或者已有的拓扑 Label 名字中带有 /，可以通过下面的命令手动给 Node 增加标签：

kubectl label node ${node_name} region=${region_name} zone=${zone_name} rack=${rack_name} kubernetes.io/hostname=${host_name}

其中 region、zone、rack、kubernetes.io/hostname 只是举例，要添加的 Label 名字和数量可以任意定义，只要符合规范且和 pd.config 里的 location-labels 设置的 Labels 保持一致即可。

为 TiDB 节点设置所在的 Node 节点的拓扑信息

从 TiDB Operator v1.4.0 开始，如果部署的 TiDB 集群版本 >= v6.3.0，TiDB Operator 会自动为 TiDB 获取其所在 Node 节点的拓扑信息，并调用 TiDB server 的对应接口将这些信息设置为 TiDB 的 Labels。这样 TiDB 可以根据这些 Labels 将Follower Read 的请求发送至正确的副本。

目前，TiDB Operator 会自动为 TiDB server 设置 pd.config 的配置中 location-labels 对应的 Labels 信息。同时，TiDB 依赖 zone Label 支持 Follower Read 的部分功能。TiDB Operator 会依次获取 Label zone、failure-domain.beta.kubernetes.io/zone 和 topology.kubernetes.io/zone 的值作为 zone的值。TiDB Operator 仅设置 TiDB server 所在的节点上包含的 Labels 并忽略其他 Labels。

总结

从 TiDB Operator v1.4.0 开始，在为 TiKV 和 TiDB 节点设置 Labels 时，TiDB Operator 支持为部分 Kubernetes 默认提供的 Labels 设置较短的别名。使用较短的 Labels 别名在部分场景下有助于优化 PD 的调度性能。当使用 TiDB Operator 把 PD 的 location-labels设置为这些别名时，如果对应的节点不包含对应的 Labels，TiDB Operator 自动使用原始 Labels 的值。

目前 TiDB Operator 支持如下短 Label 和原始 Label 的映射：

region：对应 topology.kubernetes.io/region 和 failure-domain.beta.kubernetes.io/region。

zone：对应 topology.kubernetes.io/zone 和 failure-domain.beta.kubernetes.io/zone。

host：对应 kubernetes.io/hostname。

如果 Kubernetes 的各个节点上均没有设置 region、zone 和 host 这些 Labels，将 PD 的 location-labels 设置为 ["topology.kubernetes.io/region", "topology.kubernetes.io/zone", "kubernetes.io/hostname"] 与 ["region", "zone", "host"] 效果完全相同。

平凯数据库

黄东旭解析 TiDB 的核心优势

黄东旭关于基础软件产品价值的思考

麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践

前言

一、同城两中心部署

二、环境检查

1、物理机配置查看

2、网络环境检查

3、磁盘环境检查

4、关于配置互信

三、NUMA 绑核

四、配置相关

总结

高成本云服务？TiDB 帮你省钱

前言

1 垂直方向

1.1 单库

1.2 分表

1.3 分库

1.4 分库分表

2 水平方向

2.1 单库

2.2 主从读写分离

2.3 分库

2.4 分表

2.5 分库分表

3 真实案例

3.1 分库

3.2 分表

3.3 分库分表

4 总结

测试结果比较

面对TiKV节点数据文件误删除，如何不换服务器快速恢复

背景

修复

总结：

零售业数据库选型与迁移ToC系统实践 大规模场景应用

选型背景

数据库测试方案

测试一：迁移数据的完整性

数据同步

数据比对

测试二：SQL 兼容性及性能

playback SQL 回放工具经验分享

测试三：资源隔离能力

应用改造

分页 SQL 增加排序条件

性能退化的 SQL 优化

从分库分表处理逻辑改成单库处理逻辑

数据回写改造

下游订阅改造

生产切换效果

总结

阿毛哥与 TiDB 的成长故事 探索顶级贡献者的旅程

相遇

选择加入 PingCAP

谈一谈 TiDB 贡献者们

TiDB 代码贡献之路

用户的需求

收获

开源文化

建议

配置 webhook 告警在 TiDB 实践

1、配置告警

1、下载并解压告警安装包

2、配置webhook启动脚本

3、配置webhook 配置文件

4、配置alertmanager.yml

5、配置开机启动脚本

6、启动webhook

7、重启alertmanager让告警生效

9、注意事项

alertmanager_servers

2、修改告警

1、到prometheus的conf 目录下找到对应的告警项

2、备份相应的文件，修改告警项

3、重启prometheus，让修改生效

4、临时静默

1、创建静默规则

零售业数据库选型与迁移ToC系统实践大规模场景应用

阿毛哥与 TiDB 的成长故事探索顶级贡献者的旅程