TiDB Operator

数据库存储了公司的数据，是公司的最重要资产之一。正确性和稳定性是数据库最重要的特性。测试团队之于 TiDB 是一个“破坏之王”的角色，团队的使命是炼成更高、更快、更强的 “无敌风火轮” 技能。在这篇文章里，我们介绍 PingCAP 测试团队（QA Team）是怎么工作的。 我们在做什么？ 我们测试团队是 TiDB 的“破坏者”，用各种手段尽早发现系统的 bug 是我们的工作。TiDB 有丰富的产品线，在这些产品线中，我们面对着不同的挑战。 首先，TiDB 内核稳定是整个系统稳定的基础和重中之重。TiDB 新版本的内核仍然处于高速发展的阶段。因此，测试要尽早发现新特性的正确性和稳定性问题，包括但不限于： 对 TiFlash 列存引擎，测试要构造破坏一致性保证的情况； 在 3.0 中，TiDB 增加了悲观事务，并支持了 RC 隔离级别。在 4.0 中，TiDB 支持了大事务，优化了 GC 的性能。这些特性的重要性不言而喻，必须进行严苛的、长时间的性能测试和稳定性测试； 挑战不断优化的 SQL 优化器和执行引擎，确保功能增强后的系统正确性和性能。例如 Index Merge、SQL Hint 和 SQL Plan Management 等特性； 验证调度稳定性的特性，例如 4.0 中的新热点调度器，构建不同的接近真实场景的负载，找出在这些负载下的系统不稳定的情况； TiKV

TiDB 从诞生之时就带着云原生的标签，并且底层存储引擎 TiKV 也在 2019 年成为了 CNCF （云原生计算基金会）的孵化项目。 我们很早就认识到，云提供的基础设施可编程、按量付费等区别于传统数据中心的核心特质，正是释放 TiDB 弹性伸缩潜力的最佳载体。 而在另一方面，由于有状态应用天生的复杂性和数据资产不可估量的重要性，云原生革命的上半场仍聚焦在运维流程更易标准化、故障也相对可容忍的无状态应用上。随着 Kubernetes 与 Docker Swarm 的容器编排之战尘埃落定，无状态应用编排问题在几年内迅速得到解决后，如何在云上构建坚实可靠的数据层作为新的问题浮出了水面。相信很多有识之士早已看到了这些问题，准备“寻机而动”。不过，有那么一群人已经脚踏实地付诸行动了。 是的，有那么一群人，在他们眼中，TiDB 与云是天生互相吸引、互相需要的，用“佳偶天成”来形容二者的关系并不为过 。这群人就是 PingCAP 的 Cloud 团队，一群义无反顾的云原生信仰者、一群“上能修 DB、下能改容器”的技术 Nerds、一群 TiDB 和云的忠实 “CP 粉”。我们就是这群人，而这篇文章就是希望能打动屏幕面前的你，加入我们 —— “不负韶华，共谱云与 TiDB 的和谐乐章”。好了，务虚到此结束，下面我们来点实在的。 TiDB Operator TiDB Operator 是

某厂面试归来，发现自己落伍了！>>> TiDB 挑战赛第二季之 易用性挑战赛 已经开始一周了，由于有参加过上一季 性能挑战赛 的老玩家强势加入，这一季挑战赛的竞争格外激烈，短短一周的时间，已有 3 支队伍获得了上千积分！ 完整积分排行榜可以登陆 活动官网 查看。 战况简介： BABAIsWatchingYou Team 通过 改进 Rust-Prometheus 中 Thread Local Metrics 的易用性 获得 2530 分。 niedhui Team 通过 为 TiDB-Dashboard 增加 TLS 支持 获得 1680 分。 hawking&chacha Team 通过 为 RocksDB WAL 写延迟增加监控 获得了 1300 分。 .* Team 通过 使用单独的日志文件存储 TiKV 慢查询日志 获得了 950 分。 羡慕不如行动！我们也在这里简单分享一些捞分技巧，希望能够帮助大家快速上手，追上这些排名靠前的参赛选手们。 捞分技巧 1：用户投票结果中排名前三的需求有高额加分！ 为鼓励大家选择用户呼声更高的任务，本次挑战赛中用户投票排名前三的需求对应的任务，会在原有积分的基础上分别额外增加 10000、8000、6000 分。比如这个排名第三的需求： record access statistics of databases, tables and