随着互联网行业数据规模的大幅增长，基础软件越来越垂直化和碎片化，单一的数据库软件很难满足互联网多变且极端的需求。在这样的背景下，分布式关系型数据库在最近几年成为新的潮流，TiDB 作为分布式关系型数据库的代表，正在被越来越多的互联网企业应用。为此，PingCAP 推出 TiDB DBA 项目，致力于培养能独立运维和管理分布式数据库 TiDB 的优秀 DBA，从而满足各类企业对分布式技术专业人才的迫切需求。
2019 年 Q3 正式启动的 TiDB DBA 认证考试中，全球首批通过 PCTA 和 PCTP 认证的专业人士中不乏互联网行业的技术领先者。通过文字采访，来自美团点评的两位 PCTP 将分享他们的职场经验和考试心路历程。
个人经历介绍
黄潇: 毕业之后先是做了三年业务 RD，之后沉迷数据库，在网易和美团分别做了 5 年运维 DBA， 熟悉 MySQL & Oracle 数据库原理和运维。目前做 TiDB 的运维和自动化管理平台的开发，算是数据库行业的老兵一枚。
吕磊：曾在多家传统行业、互联网金融行业担任过高级 DBA，有多年的数据库运维经验。目前就职于美团点评数据库平台组，负责分布式数据库的运维和平台开发工作。
PingCAP：您是从什么时候开始接触 TiDB 的？
黄潇: 互联网企业广泛使用 MySQL 数据库，MySQL 从易用性、单机性能、开源社区都做的非常好，一直是最受开发者欢迎的数据库。我在线上业务的广泛使用中感受到以下一些常⻅的槽点和需求:
- 分库分表：MySQL 处理海量数据时需要业务方分库分表，而分库分表加重了业务逻辑 的复杂度；为了简化业务逻辑，各大互联网厂商开发了基于 Proxy 或者基于 Client 的数据库中间件来处理分库分表的逻辑。比如阿里早期的 Cobar、淘宝早期的 TDDL、360 的 Atlas、美团的 Zebra、京东的 ShardingSphere 等等。数据库中间件解决了业务逻辑的问题，但是提高了学习和运维管理成本。同时分库分表之后，数据库弹性扩缩容变得非常困难。
- 高可用依赖：MySQL 的高可用需要依赖外部组件来实现，业界比较通用的做法是依赖 于 MHA、Orchestrator 等来实现 MySQL 的高可用，外部组件自身的高可用也是一个 问题。此外数据库是一个有状态的要求强一致的高性能的服务，外部组件在解决 MySQL 集群高可用问题的同时，还需要 MySQL 自身解决数据一致性问题，否则在数据写花时非常难以修复。GitHub 2018 年的故障足足花了一天来修复写花的数据。
- 数据不一致风险：MySQL 5.5 版本之前是异步复制，主库的事务执行不会管备库的同步进度。当主库写入较高时，备库可能存在较大延迟，如果备库落后，主库不幸 Crash，那么就会导致数据丢失。于是 MySQL 在 5.5 中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到 relay log 中，而半同步复制在网络抖动场景下会退化为异步复制。为了较为彻底的解决数据同步问题，MySQL 5.7 和 8.0 开始引入基于 Paxos 协议的 MySQL Group Replication (MGR) ，实现了全同步复制。考虑到 MGR 的功能较新、对网络稳定性要求略高、对比异步复制 MGR 的性能损失较多等因素，目前业界还未大规模开始使用 MGR。
随着现代互联网的大规模增长，业务需求和痛点催生了新的架构体系，各大互联网巨头都在分布式数据库领域布局并出现了非常精彩的产品：Google 的 Spanner、AWS 的 Aurora 等等。作为一个热爱技术的 DBA，对于业界内⻛起云涌的分布式数据库市场, 我非常好奇这些产品如何解决之前遇到的痛点。可惜除了 Google Spanner 提供了经典的论文之外，Aurora 网上提供的技术细节不太多。幸运的是，数据库圈子不大，机缘巧合下，大约一年半之前，前同事房晓乐老师陪同⻓发飘飘的 CTO ⻩东旭来我司做了关于 TiDB 激情满满的分享，对我触动极大，自此入坑。
吕磊：我在 2018 年开始接触 TiDB，为了配合公司数据中台建设和订单改造项目引入的 TiDB。
PingCAP：使用 TiDB 以来，对 TiDB 有什么感受？
黄潇：截止目前我大概使用 TiDB 一年半不到两年时间，经历了从 2.0 到 3.0 版本迭代升级，感受最明显的是 TiDB 设计上采用了主流的存储和计算分离的架构，实现上采用使用 ETCD、 RocksDB 等开源社区已经成熟并且已经被广泛使用验证的组件，很大程度上避免了业务采坑也带来了活力。官方最近两年内基本保持着两周一个小版本和半年一个大版本的节奏，通过小步快跑策略快速迭代，性能得到了成倍的提升；TiDB 是云原生数据库，拥抱 K8S，未来发展前景非常有想象力。TiDB 的社区非常火热，定期的 Meetup 活动、AskTUG 的问答社区、业务分享都让人收获满满。希望未来 TiDB 能进一步加强系统稳定性，周边工具中上下游导入导出工具更加简单易用和稳定可靠。
吕磊：TiDB 是一个年轻、充满朝气的产品，虽然现在还不完美，但是 PingCAP 和社区一直在努力，TiDB 有稳定快速的迭代速度、积极融洽的开源社区和大量资深的用户支持，我相信 TiDB 在不久的将来一定会大放异彩。
PingCAP：觉得课程如何？
黄潇：PCTA 的课程相对容易些，PCTP 的课程整体难度偏高一些。PingCAP 大学的课程干货非常足，对于没有足够知识背景的同学理解起来比较辛苦，需要多次复习。我觉得课程之间的联系点在课程中可能说的不是特别透彻，需要自己多次揣摩、反复思量。
比如为什么 gc_life_time 设置过⻓会影响查询性能？一般首先想到的就是数据的 version 过多。那进一步追问一下：为什么数据的 version 过多会导致性能差？我们知道数据在 RocksDB 里是从新 → 旧的方式存储和扫描的。那大部分场景下，访问都只需要访问较新的数据就足够了，即使存在较多的老版本数据又有什么关系呢？再深入想一下，就会发现这个是和 RocksDB 提供的查询方式 Seek 和 Next 有关。查询时，RocksDB 首先是通过 Seek 方法定位到 keyB 的最新版本，之后通过 Next 方法逐个往下查找数据，直至找到满足 MVCC 的最新数据为止。我们知道，在有序数组上二分折半查询是一个常用且性能不错的算法，Seek 方法正是利用二分查找来定位 Key 的最新版本，所以不难理解如果整体数据的 version 多，也就意味着需要在一个更大的数组里查找，越大的数据集越影响 Seek 方法定位的性能。至此，这个问题基本追根究底完毕，理解起来就顺畅多了。
吕磊：课程非常棒，让我更深入的了解 TiDB 的设计和原理，弥补了很多知识漏洞，并且把过去零散片段的知识点融合在一起，理论水平提高了一个层次。
PingCAP：为什么想参加 TiDB DBA 的认证考试？备考过程是怎样的？
黄潇：参加认证考试算是对自己技术能力的一次检验吧，学习了那么多东⻄给自己一个认可。备考还是挺艰辛的，连续一个月周末都在家好好复习。
吕磊：参加 TiDB DBA 的认证考试主要是为了检验自己的能力，对自己的一个认可。备考过程很愉快，有官方微信群专人负责答疑解惑，气氛非常融洽。
PingCAP：通过考试拿到证书对您有什么意义？
黄潇：拿到证书，一方面是终于拿到自己努力的成果，非常开心；拿到证书也增加了我在求职时候的竞争力，PCTP 证书的含金量还是非常高的。后续我会继续低调的运维和有节奏的推广 TiDB，让 TiDB 作为一个产品有足够的时间沉淀、成熟并成为数据库领域的一颗参天大树。
吕磊：从个人角度，拿到证书是对自己的一个认可，证明自己是个合格的 TiDB DBA；从公司角度，拥有 PCTP 认证的 DBA 可以让业务迁移到 TiDB 更有信心。
PingCAP：对其他参加 TiDB DBA 认证考试的小伙伴们的寄语
黄潇：不求与人人相比，但求超越自己，加油！
吕磊：相信自己，坚持不懈，下一个 PCTP 认证专家就是你！