本文将帮助您排除在大规模在线应用TiDB时会遇到的陷阱。集群标准化与未来展望。以下是使用TiDB时的一些经验，供大家参考。引入TiDB主要解决什么问题？TiDB的引入首先解决了分库分表的问题。在某些场景下，不方便分库分表，会让业务层的开发逻辑越来越复杂，不利于降本增效的方向。其次，它解决了海量数据存储的问题。单机容量存在瓶颈，会影响最终集群的效果。大型在线应用遇到的问题转转2018年开始调研TiDB，从1.0到3.0。目前集群数量30+/数据量200T+/数据节点/500+/日访问量1000亿+，主要承载用户、交易、IM、商务等服务。1.定位性能问题随着业务的扩大和集群数量的增加，维护成本也会相应增加。我们最先遇到的第一个问题，也是我们经常遇到的问题就是性能问题的定位。耗时的业务SQL响应一下子变多了。如何定位SQL的原因？在使用TiDB的时候，你会经常看到如下图。可以清楚的看到集群的响应延迟在某个时刻变慢了，业务也想知道为什么变慢了？这个时候，我们就要定位问题。通常我们需要打开TiDB监控平台查看一些指标：Query指标，事务指标等，看完之后我们会查看TiDB日志，监控过滤关键字，然后结合上下文了解发生了什么钛数据库。最后，查看TiKV日志。经过关键词分析，基本可以定位到问题所在。如果只维护一两个集群，是没有问题的。但是当集群增加到几十、上百组，节点也随之增加时，我们如何定位问题呢？2.集群管理接下来就是集群管理了。单个集群运维没有问题，但管理多个集群时可能会遇到集群部署、集群版本升级、配置不兼容等问题。简单说一下，比如在部署集群时，Systemd下PD会出问题，因为每台机器只支持一个PD，可以用supervisor解决，但是启动和停止的时候很容易出问题。版本升级的时候，前期会每两周升级一次，与正式版同步，但是后面跟不上，所以会选择一个版本停下来观望。版本升级时，我们遇到的问题是配置不一样，小版本也不一样。由于我们做了一些自定义配置，在这个版本中可能不会生效，导致升级过程中出现问题和错误。因为都是在线集群，所以每次成本都很高。总体来说，集群管理难度增加，每次版本升级的体验都不是很友好。3、日志规范不统一第三个问题：日志规范不统一。这个问题对于刚刚使用TiDB的用户来说可能感觉不是很深，但实际上1.0和2.0的日志是不一样的。比如慢日志的日志格式，2.1版本的关键字变化与2.0版本不兼容。这对我们的运维人员来说是非常昂贵的。慢日志格式从2.1.8完全改成了MySQL。高低版本不兼容。目前线上多版本并存，大大增加了日志处理的难度。4、慢SQL对集群整体稳定性的影响第四个问题：慢SQL对集群整体稳定性的影响。对于日常使用，线上复杂的统计SQL、大数据ETL需求、临时数据抽取需求都是正常的，但是直接线上操作可能会导致整个集群的响应延迟变慢，最终影响整个业务延迟的响应。5.优化器不能正确命中索引的概率很高。第五个问题：优化器不能正确命中索引的概率很高。这个问题在业务中经常遇到。我的SQL完全一样，一个是两秒，一个是几十毫秒，怎么解释？比如我们开启了统计信息的自动统计，表的统计信息比较好，两条相同的SQL，一条没有索引，一条走全扫描，执行计划不一样。为什么在统计信息比较好的情况下，指标命中概率不高？你可以先考虑一下。6、事务冲突会导致集群性能严重下降问题之六：事务冲突会导致集群性能严重下降。比如图中的问题SQL，在执行过程中存在并发更新的场景，当TiDBretry_limit=3时，会严重影响集群性能。可以看出，发生重试时，整体锁状态比较高，并且响应延迟相应增加。TiDB集群标准化刚刚梳理了六个有代表性的问题，相信大家也都想过了。转转通过TiDB的标准化解决集群部署、信息采集、监控告警、业务上线遇到的问题。1.集群部署标准化在集群部署标准化方面，至少部署三台TiDBServer，实现TiDB的高可用，提供稳定的数据访问。需要10G网卡和机械盘。其次，你需要3台PDServer，千兆网卡或者10G网卡，还有机械盘。最后，至少6个TiKVServer，单个TiKV的容量不要超过400GB，不过这个也要根据企业的使用情况而定，最好使用固态硬盘。部署管理建议：作为MySQL应用场景的补充，我们不建议接入容量特别小的TiDB。建议至少大于500GB，以免造成资源浪费；单个TiKV的容量不要超过400GB，可以有效缩短TiKV故障后的恢复时间；TiDB/TiKV千兆网卡在高并发下会成为容量瓶颈，请使用10千兆网卡；TiKV单机多实例，可以使用多个磁盘挂载，IO隔离，目前应用效果不错。2.信息收集其次是信息收集的标准化。一直在和官方聊日志能不能修复，从1.0一路追到3.0，也算是有经验的老用户了。对于刚接触TiDB的用户，建议使用2.1.8之后的版本，日志比较稳定，日志的ETL也比较容易。官方格式会在以后的版本中固定下来，这对社区来说是一件非常好的事情。目前对于专转，经过我们的规范，主要的问题是TiDB的查询慢。我们针对慢查询开发了相应的实时慢查询视图，方便业务RD观察集群慢查询信息。目前主要通过Flume收集日志，最终通过平台进行处理、展示和告警。3.监控报警以下是报警监控的标准化。TiDB原生的告警有很多种告警和监控。转转整理了一下，保证每个告警都能起到预警作用，有意义，但每个告警不一定需要人工干预。如果每天都在接告警，你会累，大家也就不看了，所以我们希望告警收敛。此外，对警报进行了简化和定制，使接收者更容易理解信息。业务RD根本看不懂TiDB原生的告警。他们只是想知道出了什么问题，所以我们处理它。最后是监控简化，通过扫描关键指标获取集群的瞬时状态，目前正在和TiDB同学一起做，希望能够兼容多个版本获取集群的瞬时值，从而快速了解集群问题及状态，大致定位故障方向。4.业务启动最后是业务启动的标准化。首先是SQL优化，表结构、索引、列表都进行了优化。DBA需要参与业务上线的全过程，包括创建表、SQLList、审核表结构和SQL。也就是每次我们要上线TiDB集群，都要跟业务商量，可能有问题。所有的SQL都必须使用ForceIndex来解决优化器大概率不能正确命中索引的问题。3.0GA包括SQL计划管理。虽然目前是一个实验性的功能，但你可以测试它。这是美团点评和TiDB联合开发的功能。然后我们对响应延时要求比较高，99.9%控制在100ms以下，上线前99%控制在10ms以下，可以解决一些常规的响应延时。下一步是TiDBExplain。DBA需要熟练掌握，告诉开发如何解读内容，才能上线。二是业务逻辑。现有业务场景下，当并发更新同一条记录时，会触发TiDB重试。在目前的事务模型（乐观锁）下性能不好。如何解决？我们使用自研的分布式锁ZZLock是在乐观锁的基础上加了一个分布式锁来模拟悲观锁，这样就不会出现业务响应延迟的问题，同时可以减少冲突时间到一个比较稳定的时间。第三个是数据提取，这是一个很常见的需求。我们使用binlog组件将tidb-server的变更数据写入PumpCluster，然后Drainer将数据应用到下游集群。通过接入下游集群，解决线上复杂的查询、抽取等对时效性要求不高的需求。TiDB的未来规划和展望对于TiDB的未来规划和展望，总体主题还是围绕着降本增效的主题。我们正在用PingCAP进行容器试点，接下来我们将在云上运行TiDB。Q&AQ1：现在最大的集群场景是什么？有多少个节点？接入QPS的峰值是多少？金额高达数百亿。总体来说，TiKV集群比较多，整体反响不错。SQL是基于主键查询的，业务做的很好。Q2：目前网络版分布情况如何？为什么不升级到2.1.8？A：目前有2.0、2.0.5、2.1.7、2.1.8，主流版本为2.1.8。2.1.8以下的版本还是比较稳定的。有升级计划但是业务没有需求，想跟业务一起升级。如果3.0的测试结果不错，我会考虑直接升级到3.0。Q3：一个集群是有多个DB还是只有一个DB？如何考虑隔离？A：一个集群只有一个DB。
