关于运维:如何构建企业内的-TiDB-自运维体系

39次阅读

共计 11290 个字符，预计需要花费 29 分钟才能阅读完成。

1. 前言

得物 App 从创建之初，关系型数据库始终应用的开源数据库产品 MySQL。和绝大部分互联网公司一样，随着业务高速增长、数据量逐渐增多，单实例、单库、单表呈现性能瓶颈和存储瓶颈。从选型和架构设计角度来看这很合乎倒退法则，一开始没必要引入过于简单的架构导致资源老本和开发成本过高，而是逐渐随着业务倒退速度去迭代架构。为了应答这些问题，咱们采取了诸多措施如单库按业务逻辑拆分成多个库的垂直拆分，分库分表的程度拆分、一主多从读写拆散等。这些技改同时也使得整个业务层架构更加简单，且无奈做到通明的弹性，因而咱们逐渐把眼光转向了曾经趋于成熟的分布式关系型数据库 TiDB。

自 2020 年初开始应用 TiDB，随着运维体系的逐步完善，产品本身能力的逐渐晋升，接入业务曾经波及得物的多个 业务线，其中个别为要害业务场景。业界对于 TiDB 的性能分析、场景落地、平台化建设都有很多优良的文章。本文基于得物外部的实际状况，会从选型策略、运维伎俩、经营形式、外围场景实际等几个方向讲述 TiDB 在得物实际落地过程。

2. TiDB 架构

上图是咱们目前的接入形式和整体架构。TiDB 的部署架构这里就不做赘述了，须要理解的同学能够参考官网文档。咱们之所以采纳 SLB 来做 TiDB 的负载平衡接入，就是为了简化接入老本与运维老本，拜访流量的负载平衡以及节点扩缩容能够通过调整 SLB 解决。当然如果可能实现 SDK 负载平衡与故障剔除，联合配置核心的流量调度也是十分好的解决方案。得物 TiDB 部署均采纳单机单实例部署，TiDB Server、PD 采纳无本地 SSD 机型，TiKV 采纳本地 SSD 机型。既兼顾了性能，又能降低成本。具体的机型抉择会在前面的内容提到。

3. MySQL 与 TiDB 的比照

圈内始终流传着一句话，没有一种数据库是 ” 银弹 ”。绝大部分用户抉择 TiDB 就是为了补救 MySQL 的有余，所以选型阶段对两者做些比拟也是在劫难逃的。本文基于咱们外部的现状和场景对两个产品咱们关注的点进行了简要比照。比照的目标不是为了去印证那个数据库产品能力更强。而是想通过比照来帮忙团队在适合的场景抉择适合的产品。

  • 扩展性

    • MySQL

    MySQL 就本身扩大能力而言次要是来自于垂直扩容，然而这个会受限于机器的规格下限。程度扩容波及业务革新和应用老本晋升。革新为分库分表，对研发来说是一个费力度很高的计划。须要引入 Sharding 逻辑，革新实现后须要业务 SQL 必须带 Sharding Key 能力执行或者高效执行。所以并不是说做不到可扩大。

    • TiDB

    因为 TiDB 是计算存储拆散的架构，且有状态的存储层 TiKV 是分布式存储。所以单从下面定义的扩展性来说，的确比照 MySQL 有很大劣势。集群解决能力和存储能力，能够通过扩容 TiDB Server、TiKV 简略实现。这里须要留神的是，TiKV 属于有状态服务，扩容会波及到数据的 Reblance，过程中 TiKV(region 迁徙) 和 PD(调度) 产生大量交互，为防止影响业务，扩缩容过程中须要关注集群状况，依据需要适当调整迁徙力度。

  • 性能

    • MySQL

    对于 RT。MySQL 因为是单机数据库，所以对于点查或简略查问的 RT、热点更新的 RT 与 TPS，相比分布式数据库有人造劣势。数据获取链路短(单机数据库本地调用，分布式数据库波及存算拆散)，且不必思考分布式事务的冲突检测。所以总体的拜访 RT 要低于 TiDB，具体数据这边就不列举了，社区有不少性能压测的帖子。

    对于聚合查问。互联网公司在 C 端根本不存在此类问题，也是不容许的。所以次要是场景在 B 端。解决办法个别是分为几种：1. 提供专门的只读实例给 B 端提供查问能力；2. 异构数据来解决（MySQL+ES、ADB 等等）。

    对于优化器。MySQL 多年的积攒，在优化器的稳定性尽管不如商用数据库那么牢靠，偶然也有走错索引的状况。个别只能通过批改 SQL、批改索引来解决，切记别用 force index 这种有坑的解决方案。然而总体来说咱们遇到的 MySQL 走错索引的状况要远低于 TiDB。

    • TiDB

    对于 RT。分布式数据库解决的更多是吞吐量和容量上的需要，比方点查或简略查问的 RT 无奈像单机数据库那么短，然而能够通过节点扩容的形式晋升 QPS 吞吐量。热点数据这里就不开展讲了，它自身也不是分布式数据库能解决的领域。如果你的业务场景是一个对 RT 要求很高的场景，那么优先应用 MySQL。如果是高吞吐量需要优先，能够尝试应用 TiDB。

    对于聚合查问。因为 TiDB 的存储节点 TiKV 不只是具备存储能力，TiKV 实现了 coprocessor 框架来反对分布式计算的能力。所以实践上通过加机器就能扩大计算能力，从咱们理论应用的场景来看也是如此，这部分的能力就要优于 MySQL。具体的成果在本文最初的章节会有体现。

    对于优化器。这个是大家对 TiDB 始终以来吐槽的点之一，有时候统计信息衰弱度 90 以上的状况下，还是会走错索引，当然这里有一部分起因可能是条件过多和索引过多导致的。为了解决问题，外围服务上线的 SQL 就必须一一 Review。如果无奈正确应用索引的就应用 SPM 绑定，尽管能解决，然而应用老本还是略高。心愿官网持续加油。

  • 资源老本

    • MySQL

    如果是一个数据量小且查问模型比较简单的需要(比方：1-2TB，简略查问为主)，那么必定是 MySQL 老本较低。以咱们 TiDB 根底配置为例，相比 MySQL 老本高出 27%(该老本是用高可用的 MySQL 对标 3 TiDB、3 TiKV、3 PD 的 TiDB)。所以得物外部选型，单从资源老本角度思考，还是首选 MySQL。

    TiDB 如果是一个数据量较大且持续增长或查问模型比较复杂的需要 (比方：3-5 TB 以上，多条件查问、聚合查问等)。个别该类型的业务都采纳分库分表的解决方案。以得物一个分库分表的集群(10 个写实例、10 个读实例) 为例，替换为 TiDB(6 TiDB、12 TiKV、3 PD)，老本相比 MySQL 老本节俭 58%。此例子只作为得物一个业务场景的替换后果，不代表所有场景。为了验证这个论断，本文前面的内容会讲到这个外围场景的实际。

  • 运维老本

    • MySQL

    MySQL 作为被应用最多的开源关系型数据库，从社区活跃度、产品成熟度、周边生态工具、解决方案积攒等方面来看都是十分优先的产品。主从架构的 MySQL 保护老本极低，当主库异样或无奈修复时，咱们只须要切换即可。

    另外得益于优良的社区生态，运维工具、数据库接入组件、数据同步组件都有十分多的成熟工具，稍加革新就能够实现本地化适配。

    • TiDB

    分布式的架构的设计没有像 MySQL 这样的主从，每个存储节点都是提供读写。当一个节点出问题的时候，会影响整个集群的拜访。无奈实现 MySQL 这样通过主从切换实现疾速的故障隔离。

    TiDB 由 3 个角色组成，当呈现问题的时候无奈疾速定位问题(当然也是咱们集体能力须要晋升的点)，比方当某个工夫点的查问超过预期的时候，须要排查执行打算、各个节点的负载状况、各节点的网络状况。尽管提供了欠缺的监控，然而指标与节点过多须要一一排查能力有论断。不像 MySQL 呈现查问超预期的问题，基本上通过几个外围指标就能判断出根因。

  • 构造变更(DDL)

    • MySQL

    这里以咱们次要应用的 MySQL 5.7 为例，较大数据量的状况下 DDL 老本较高，为了躲避锁表和主从提早的问题，个别都是用工具去执行。咱们通常应用的两个出名开源无锁 DDL 工具：Percona 开源的 pt-osc、Github 开源的 gh-ost。目前咱们和大部分公司一样都在通过定制化开发的 gh-ost 来变更。然而用工具只是解决了后面提到的锁表和主从提早问题，随着数据量规模回升，变更时长也逐渐回升。另外工具的 Bug 也会带来数据失落的危险。当然 MySQL 8.0 的个性 Instant Add Column 推出当前解决了加列的痛点，然而也只解决了一部分。

    • TiDB

    TiDB 的 DDL 通过实现 Google F1 的在线异步 schema 变更算法，来实现在分布式场景下的无锁，在线 schema 变更。DDL 变更中除过 add index 以外其余都不须要做数据回填，批改完元信息即可，所以能够立刻实现。而 add index 会做两件事件：1. 批改 table 的元信息，把 indexInfo 退出到 table 的元信息中去；2. 把 table 中已有了的数据行，把 index columns 的值全副回填到 index record 中去。变更速度取决于表中的数据和零碎负载。所以 TiDB 在 DDL 操作上解决了很多 MySQL 上的痛点，然而与 MySQL 相比，TiDB 的 DDL 还是有些不一样的中央的，也带来了一些限度：

    1. 不能在单条 ALTER TABLE 语句中实现多个操作。MySQL 下会把多个同一张表的 DDL 进行合并，而后应用 gh-ost 或者 pt-osc 工具一次性执行。TiDB 里只能一个个独自去执行；(6.2 曾经反对了 ALTER TABLE 语句增删改多个列或索引)
    2. 不反对不同类型的索引 (HASH|BTREE|RTREE|FULLTEXT)；
    3. 不反对增加 / 删除主键，除非开启了 alter-primary-key 配置项；
    4. 不反对将字段类型批改为其超集，例如不反对从 INTEGER 批改为 VARCHAR，或者从 TIMESTAMP 批改为 DATETIME，否则可能输入的错误信息 Unsupported modify column
    5. 更改 / 批改数据类型时，尚未反对“有损更改”，例如不反对从 BIGINT 更改为 INT;
    6. 更改 / 批改 DECIMAL 类型时，不反对更改精度 ;
    7. 更改 / 批改整数列时，不容许更改 UNSIGNED 属性 ;

这里大部分限度能够在构造设计阶段和前期标准来躲避掉，比方一个表的多个 DDL 操作无奈合并的问题，能够通过自动化伎俩升高复杂度；BIGINT 更改为 INT 这种长改短的就是日常变更标准中要管控的。

  • 产品风行度

    • MySQL

    如果咱们从 MySQL 1.0 开始算起至今曾经有 26 年了。这期间几经周转，最终归到了 Oracle 旗下。版本也从 1.0 来到了 8.0。作为一个久经锻炼的数据，特地是作为互联网流行期间依赖的支流数据库，不论是产品成熟度和社区活跃度都失去了极大的促成。MySQL 在 DB-Engines 的开源数据库中排名久居第一。

图片数据起源 DB-engines 官网

    • TiDB

    TiDB 从 2015 年创建并开源至今曾经 7 年，作为一个简单的根底软件来说的确还比拟年老。依赖晚期的 3 个创始人互联网背景出身，深知大家在关系型数据库上的痛点。所以 TiDB 推出后取得了不少用户的推崇，特地是互联网行业。社区在 TiDB 的倒退中也起到了至关重要的作用，从打磨产品、需要提炼、落地场景总结等。目前 TiDB 在 DB-Engines 排名为 98，进一步证实了根底软件的难度以及作为一款国产数据库在国际化过程中还有很大的空间。从墨天轮中国数据库排行的状况，能够看到 TiDB 长期以来放弃第一的地位。在 12 月跌落榜首，由 OceanBase 取代。

图片数据起源 墨天轮

4. TiDB 在得物的运维体系落地及摸索

4.1 选型

对于数据库选型，咱们一贯十分审慎，会依据具体的业务状况来举荐适合的数据库。要防止陷入“手拿铁锤的人, 看什么都像钉子”的误区。不是为了应用 TiDB 而应用，要去解决一些 MySQL 无奈满足或者革新老本比拟高的场景。关系型数据库咱们还是优先举荐 MySQL。能用分库分表能解决的问题尽量抉择 MySQL。毕竟运维老本绝对较低、数据库版本更加稳固、单点查问速度更快、单机 QPS 性能更高这些个性是分布式数据库无奈满足的。以下是咱们总结的对于选型的两个大方向。

适宜接入的场景：

  • 分库分表场景: 上游 MySQL 分库分表，业务查问时无奈应用到分片
  • 磁盘应用大场景: CPU 和内存使用率低但磁盘容量达到 MySQL 瓶颈
  • 剖析 SQL 多场景: 业务逻辑比较复杂，存在并发查问 + 剖析查问
  • 数据归档场景: 数据冷热拆散、定期归档、数据重要，不能失落
  • 日志流水场景: 日志流水业务、单表较大、写入安稳、查问不多

不适宜接入的场景：

  • 数据抽取场景: 上游存在大数据或者其余业务部门进行数据抽取
  • 读写拆散的场景: TIDB 没有主从的概念，无奈进行读写拆散
  • 指定点复原场景: 指定工夫点级别复原，须要复原到某个工夫点
  • 数据热点场景: 高并发单行更新、热点小表、热点库存

4.2 运维标准化

  • 业务接入

场景：当业务选型思考 TiDB 时，咱们会依据业务的应用场景和业务特点综合评估是否适宜 TiDB(优先 举荐应用 MySQL)。

配置：评估业务老本压力和将来一年数据量、TPS，抉择适合的 TiDB 集群配置。

应用：给应用方提供 MySQL 和 TiDB 的差别及其标准，防止减少开发周期和老本。

  • 资源规格

依据不同业务场景，咱们定义了不同的服务器配置。因为借助云上的资源交付能力和隔离能力，咱们无需像 IDC 那样，在高规格机器上采纳多实例部署。这样防止了混部带来两个问题：1. 多个实例之间的资源抢夺；2. 高规定机器部署密度与稳定性的衡量。

节点 数量 配置
TIDB 3 根底规格：8C32G200GB(云盘)高配规格：16C64G200GB(云盘)
PD 3 根底规格：8C16G200GB(云盘)高配规格：16C64G200G(云盘)
Monitor 1 4C16G200GB(云盘)
TIKV/TIFLASH 3 根底规格：8C32G1788G(本地 SSD)高配规格：16C64G1788G(本地 SSD)
  • 数据库备份

备份工具：BR[官网物理备份工具]

备份策略：凌晨低峰期进行数据全量备份

备份保留周期：7 天

    • 在线业务

对于在线业务，除了惯例的 BR 备份外会额定调整 tikv_gc_life_time 工夫为 1-3 天，当业务呈现误操作时能够复原三天内任意工夫的数据。

    • 离线业务

TiDB 集群离线业务大部分是从上游 RDS 同步到 TiDB 的场景。上游 RDS 会有一份最近的数据，所以对于离线业务只有惯例的 BR 备份。

4.3 稳定性治理

  • 变更治理

    • 面向 DBA 的流程管控

上图的流程次要是用于管控非白屏化的 TiDB 基础设施变更。通过变更文档整顿、运维小组 Review 的机制，确保简单变更的规范化。

    • 面向研发变更的零碎管控 DML\DDL 变更工单危险自动化辨认

语法查看：

  1. DDL 与 DML 类型判断，确保每次执行的内容是同一个类型
  2. SQL 语法查看，确保提交的 SQL 语法是正确的

合规查看：

变更合规性查看，确保提交的 SQL 是能够依照 DBA 定义的标准设计(能够应用的字段类型、字段命名、索引命名、索引数量，字段长度由长批改短等限度)，简略说就是要么容许，要么不容许

危险辨认：

  1. 该项的作用是将容许执行的进行危险辨认，研发能够依据危险等级抉择执行工夫，DBA 也能在审批阶段判断是否正当，并批改执行工夫。
  2. 相干危险定义

下图是基于以上提到的能力，实现的 TiDB 变更管控性能。

  • 稳定性巡检

数据库巡检伎俩是相当于告警比拟前置的一个动作，巡检阈值相比告警较低，目标是为了提前发现问题并跟进解决。收益是：1. 升高告警数量；2. 防止小问题逐渐积攒导致大问题。咱们的做法是依照自定义的评分规定，双日晨会对焦，对有危险的服务进行问题跟进。

巡检指标的数据采集来自于监控零碎，咱们会统计相干指标的峰值。每天记录一个点，展现近 30 天内的指标值。

某集群的巡检状况

  • 慢查治理

尽管 TiDB 自带的 Dashboard 能够提供慢查的白屏化，然而这须要提供账号密码给研发，5.0 之前的版本还必须应用 root 账号登录，另外就是咱们心愿慢查治理能够联合外部零碎进行治理。所以对于这部分做了些自研工作，将日志采集并加工后存入 ES。DBA 平台能够通过报表等伎俩进行推动治理。

上面两张图就是咱们外部的平台对慢查治理的闭环治理计划。DBA 或者研发 TL 在平台指派 SQL，解决人就会收到治理音讯，解决实现后能够在后盾进行状态变更。而后基于这些数据能够做报表优化治理成果。

  • 告警治理

基于 TiDB 官网的监控计划，咱们在告警局部做了些定制化，Prometheus 中配置的 rule 触发后会把告警信息推送至咱们本人的数据库治理平台 OneDBA，由平台解决后进行发送。平台的告警治理模块的实现相似于 Alertmanager，不同的咱们新增了自定义的需要，比方元信息关联、反对集群指标级别的阈值定义、告警缄默、告警降噪、告警治理闭环(有告警告诉和认领，确保及时跟进解决)。另外这里的 Prometheus 次要性能是做数据采集与告警，数据存储与趋势图查看在公司对立监控平台，升高不必要的存储资源投入。因为咱们治理的数据库类型比拟多，所以在告警计划上做了收敛。这里讲到的计划就是得物数据库团队目前针对负责的所有数据库的治理计划。

阈值治理

  • 故障演练

故障演练的目标是为了坚固目前的零碎高可用。咱们针对 TiDB 制订了一套成心演练流程，蕴含了 8 个场景。

【演练场景 1】TiKV Server 1 个节点宕机

【演练场景 2】TiDB Server 1 个节点宕机

【演练场景 3】PD Server 1 个节点宕机

【演练场景 4】PD Server 节点重启

【演练场景 5】TiKV Server 节点重启

【演练场景 6】利用高并发写入，CPU、IO 告警是否及时发送

【演练场景 7】PD Server Leader、follow 节点重启

【演练场景 8】TiDB 集群 宕机一个 TiDB Server 节点

以上的场景咱们通过 ChaosBlade 实现了 100% 自动化故障注入。故障演练也促使咱们达成整个技术部的指标：1 分钟发现，5 分钟止损，10 分钟定位。目前也正在打算将该流程引入新集群交付前以及版本升级后的标准化流程。

4.4 人才储备

  • 业余认证

PingCAP 目前有三个认证，别离是 PCTA、PCTP、PCSD。前两个是晚期推出面向 DBA 从业者岗位初高级认证。得物 DBA 团队有 6 位同学取得 TiDB 的 PCTA 认证考试、其中 5 位同学取得了进阶的 PCTP (TiDB 专家)认证考试。认证尽管不能齐全代表实力，然而代表了 DBA 团队对技术的谋求和 DBA 团队在得物做好 TiDB 服务反对的信心与态度。

通过 PCTP 认证学习，团队成员深刻理解 TiDB 数据库的体系架构、设计理念与各个组件的运行原理。学习并把握 TiDB 数据库的体系架构，设计实际，性能监控、参数优化、故障排除、SQL 优化和高可用设计。这个对于公司和团队来说就是人才和技术上的储备。

局部退职的 PCTP 得物 DBA 证书截图

  • 运维小组

对自建数据库服务咱们采纳了小组负责制，以 TiDB 为例，会有 3 名同学负责基础设施运维的工作(资源评估、变更流程评估、二线问题解决等)，其中一名是 Owner。对于日常业务侧的变更、SQL 优化等由具体对接业务的 DBA 负责解决。这样既解决了人员互备问题，又解决了变更危险评估问题，还解决了运维小组运维压力的问题。

4.5 技术经营

对于一个新兴数据库，DBA 基于产品个性介绍、场景剖析、案例分享等，在公司外部的技术经营也十分重要。它决定了研发同学对这个产品的认知和信念。好的技术气氛肯定是得益于公司外部欠缺的机制和平台，同时你也能正当的加以利用。这里没有讲到对外分享，是因为咱们的准则是先外部积淀修炼，而后再对外分享。以下是咱们对于 TiDB 的技术经营在公司外部的 3 个主战场。

  • 技术分享

技术夜校是得物技术部技术文化的特色之一。为技术部无意分享的同学提供一个平台，就现有技术实战经验、技术研究成果、重点项目回顾等，在技术部与同学们做分享和交换，营造浓重的技术分享气氛，造成技术常识积淀，打造学习型组织，晋升技术影响力，拓宽技术同学的知识面。

这是一个可能无力促成技术影响力和产品影响力的机会，咱们当然也不能错过。本文的作者在刚入职得物的时候就分享了《分布式数据库 TiDB 的设计和架构》，培训教室座无虚席，参加人次创下新高。这次分享让研发对 TiDB 也有了一个全面的意识。所以技术分享肯定水平上解决了后面说的产品能力认知问题。

  • 技术博客

“ 毒 ” 家博客也是得物技术部技术文化的特色之一。初衷是为了各位同学们交换技术心得，通过输出与输入的形式促成提高、互相成长。很多高质量文章也被推送到了得物技术公众号。

DBA 团队借助外部的技术博客平台，输入了多篇无关 TiDB 的技术文章。内容涵盖外围原理剖析、优化案例、故障 case 剖析、业务场景落地等。在整个气氛的带动下，不少研发同学也发表了对于 TiDB 的学习和落地的技术文章。

  • 课程录制

组织外部的技术分享的投入较大，分享的频次不宜太高，否则参与度也会比拟低。而且从内容深度、常识获取效率、自助学习来看，分享也不是长期的计划。录制视频课程的事件就提上日程了，视频课程的益处是能够稀释知识点，将技术分享 40 分钟的内容 (有一些不必要的内容，比方反复的话、口头语等) 压缩至 15 分钟。完满解决了后面提到的问题。正好公司外部有一个自研的学习平台，日常就用于公布各种培训、学习的视频。为确保录制成果和效率咱们后期的课程都筹备了稿件。咱们基于这个平台也公布了一期 (5 节) 课程，最近曾经在筹备第二期的课程内容了。

课程录制也能够使 DBA 再一次温习细节常识，因为要讲清楚知识点，就必须本人深刻了解。这个肯定水平上表明了咱们对 TiDB 的理解水平和做好它的信心，也给了研发应用的信念。

5. TiDB 在外围业务场景实际

5.1 业务痛点

得物商家订单库由晚期 MySQL 单库进阶到 MySQL 分库分表，这个计划撑持了业务的高速倒退。而以商家 ID 做 shareding-key，会使的同一个商家的订单数据都会在一个表中，随着订单量的逐渐晋升，最终大商家的查问会造成了单点性能问题。次要体现在慢 SQL 较多和 数据库负载回升，每天约 1W 条慢 SQL，局部统计类查问曾经超 10S。另外就是单机容量也有下限，垂直扩容受限。随着订单量的回升，零碎整体的性能和容量须要最进一步的布局。

5.2 解决思路

基于以上提到的问题，咱们对所有的解决方案都做了比照。表格中是对四种解决方案的要害信息提炼。咱们心愿可能抉择一个比拟长期的计划，能够撑持将来 3-5 年的需要，既要解决性能问题，还要解决容量问题，又要比拟低的研发老本。所以最终抉择了引入分布式数据库的计划。

5.3 数据库选型

基于目前得物在应用的数据库进行了评估，次要蕴含以下三种抉择。

因为得物在 2020 年就引入了 TiDB。尽管没有大规模推广，然而陆续也有不少业务接入。大部分的业务把它作为 MySQL 分库分表的聚合库应用，有一小部分业务是间接接入了读写需要。基于之前的实践经验和业务需要，通过和研发团队的协商，间接采纳的读写库的应用计划。另外一个方面是从只读过渡到全量读写的周期会比拟长，会产生不必要的并行老本和提早我的项目工夫。

5.4 兼容性 & 性能测试

  • 兼容性测试

SQL 兼容性的问题，咱们并没有齐全依赖前期的业务测试来验证。而是通过获取 MySQL 上的全量 SQL 的形式进行验证。因为咱们将全量 SQL 存储在了 Clickhouse，并且存储前做了 SQL 指纹提取。所以很容易能够取得去重后的业务 SQL。而后将所有类型的 SQL 样本在 TiDB 中进行回放，这里次要针对 Select。最终测试所有业务 SQL 100% 兼容。

SQL 指纹

  • 性能测试

    • 单量较少的商家场景性能测试

和预期的后果一样，因为 TiDB 分布式的架构，数据获取门路比 MySQL 要长，所以 RT 上相比 MySQL 别离多出 91%、76%、52%。从这里能够看出随着并发的回升，TiDB 和 MySQL 之间的 RT 差距也逐渐缩短。因为 TiDB 能够通过扩大 DB 和 KV 节点晋升 QPS 能力，咱们在压测中也做了相干验证，合乎预期。包含现有数据量翻一倍的根底上对性能的影响也做了验证，论断是无影响。为了不便和前面的内容比照，咱们这里只提供了 RT 的指标。

    • 单量较多的商家场景性能测试

咱们挑了几个呈现频率较高且查问较慢的 SQL 进行测试，详情参照以下内容。

SQL1

SELECT *
  FROM table_name
 WHERE xx_id= 1203030
   AND xx_status IN(4000, 3040)
   AND is_del= 0 ORDER BY id DESC,
         create_time DESC  LIMIT 20

SQL2

SELECT [column_name] FROM table_name
WHERE xx_id = 1203030
        AND xx_status = 8010
        AND close_type = 13
        AND close_time >‘2022-06-19 18:16:24.519'
LIMIT 0, 30000

SQL3

SELECT * FROM table_name
 WHERE xx_id= 1203030
   AND xx_status IN(7000, 8000, 8010)
   AND is_del= 0
ORDER BY id DESC,create_time DESC 


LIMIT 20

SQL4

select count(*)  from table_name
 WHERE(seller_id= 1203030
   and is_del= 0
   and biz_type in('0', '12')
   and create_time>= '2021-11-01 00:00:00.0'
   and create_time< '2021-11-30 23:59:59.0'
   and(xx_status<> 1000 R biz_type<> 21))

对于 xxDB 特地做了解决，大家能够疏忽，因为咱们次要比照的是 MySQL 和 TiDB。从测试后果来看成果很好，齐全满足业务侧的要求。

5.5 遇到的一些问题

  • SQL 执行打算

问题：

首先阐明一下，统计信息衰弱度是 90 以上。SQL 还是会选错索引。咱们剖析了一下，次要是两个问题：1. 查问条件比拟多，索引也比拟多；2. 优化器的能力待晋升。

解决方案：

上线前和研发对已有 SQL 进行了全面的 Review，如果执行打算不对，就通过 SPM 解决。

  • Bug

问题 1：

Update 语句并发执行耗时 3S，通过排查是因为研发未应用显示事务，所以第一次执行是乐观事务，第二次重试才是乐观事务。调整当前遇到了乐观事务下，偶发性的写写抵触的问题。经排查是因为乐观锁未获取到导致的写写抵触，须要降级到 5.3.2 能力解决。

解决方案：

降级版本到 5.3.2 解决

问题 2：

TiDB 呈现局部节点不可用，SQL 执行报 Region is unavailable 谬误。经排查是 5.3.2 引入的 TiKV bug。

PD leader 产生切换后，TiKV 向 PD client 发送心跳申请失败后不会重试，只能期待与 PD client 重连。

这样，故障 TiKV 节点上的 Region 的信息会逐渐变旧，使得 TiDB 无奈获取最新的 Region 信息，导致 SQL 执行出错。

解决方案：

这是一个让人后背发凉的 bug。过后的判断是因为 PD 切换导致的，然而不分明是 bug。咱们采纳了影响最小的故障复原计划(把 PD leader 切回去，因为原 PD Leader 没有挂，只是产生了切换)。问题解决后在官网发现了这个 bug fix。所以又安顿了降级。

这是咱们上线过程中遇到的几个典型问题。总体来说引入一个新数据库就会带来肯定的试错老本，所以咱们仍然处于审慎选型的状态。另外就是吐槽一下，就下面的问题 2，倡议官网要增强 Code Review 和混沌工程演练。

5.6 上线成果

  • 性能收益

为了确保上线稳定性，咱们通过灰度切流的形式逐渐放量。齐全切流后成绩显著，慢 SQL 简直全副隐没，如下图所示。

  • 老本收益

因为 MySQL 的分库分表集群由 10 个写实例、10 个读实例形成，迁徙至 TiDB 后的集群规模为 TiDB6、TiKV12。老本降落了 58%。所以再反复说一下选对了场景，TiDB 也能顺带节省成本。

  • 大促考验

我的项目上线后轻松应答了往年的双 11、双 12，大促中的零碎 RT 体现稳固。

6. 总结

最初特地阐明下，文章中波及一些产品的比照只是基于咱们过后的场景和需要进行的剖析，并不代表某个数据库产品的好坏。写这篇文章的目标是想把咱们 TiDB 落地教训做个阶段性总结，顺便也能给同行们做个大方向上的参考。咱们的这套方法论，实践上实用于任何一个须要再企业外部引入新型数据，并且推广的场景。本文波及的内容和方向比拟多，无奈每个模块都做深刻的探讨。前面咱们也会把大家感兴趣的模块独自拆分进去做几期深刻分享。

* 文 /xiaoyu

关注得物技术，每周一三五晚 18:30 更新技术干货

要是感觉文章对你有帮忙的话，欢送评论转发点赞～

正文完
运维
发表至： 运维
2022-12-20
 0
关于运维:百炼成钢-声网实时网络的自动运维丨Dev-for-Dev-专栏
关于运维:博睿她力量-这份专业值得信赖
关于运维:AOps性能火焰图适用于云原生的全栈持续性能监测工具
关于k8s:K8s-原生-Serverless-实践ASK-与-Knative