共计 5796 个字符，预计需要花费 15 分钟才能阅读完成。
摘要
本文依据 2020 年 DTCC 数据库大会分享内容整顿而成。工商银行在 2014 年就开始推广应用 MySQL。时至今日，生产环境的 MySQL 节点数量曾经倒退到近万个；利用场景也从外围低等级利用，推广到外围高等级利用。此次与大家分享，为承接外围业务数据存储的重任，工商银行在 MySQL 利用治理方面的思路和计划
演讲者介绍：林镇熙，工商银行小兵一枚，2014 年开始接触 MySQL，将 MySQL 5.5、5.7 版本引入工行。负责 MySQL 架构设计，开发标准，以及相干技术培训工作。
工商银行在外围利用 MySQL 的治理，次要分为三个方面：目前面临的状况和挑战、为了解决这些问题的思路和具体的计划，最初是后续晋升的思路。
一、现状与挑战
1.1、现状
这是行内 MySQL 的部署节点数倒退状况，从 2019 年 6 月开始到当初，在短短的两年期间，MySQL 节点规模上涨得十分厉害，翻了几番。绿色局部是目前这些节点当中的外围利用节点数的状况。外围利用占的比例其实是比拟大的，有两个方面的因素：一方面是行内在数据库应用的策略上，对于新增的数据库节点，如果没有特地要求的话都会应用 MySQL 数据库；另一方面是与行业内业务倒退状况相干，行内对于高容量、高并发、弹性扩大的业务需要十分旺盛，这种状况下对于分布式架构的数据库要求越来越多，所以对于分布式内容的利用规模也会比拟宏大。行内将利用分为 ABCD 四个等级，最高等级为 A 类利用，外围利用就是指最高等级的 A 类利用。
1.2、面对的挑战
行内对高容量、高并发、弹性扩大的业务需要比拟多。目前根本实现了分布式体系的建设，满足业务的需要，MySQL 也是分布式数据库体系的一部分，除了数据库之外也实现了分布式服务、软负载、分布式事务、分布式音讯、批量、缓存、对象存储、文件存储，加上数据库等，共有九大运行撑持平台。通过这些平台的组合，造成了残缺的分布式解决方案，满足业务的要求。
对于运维方面的压力，当初 MySQL 节点数量十分宏大，对于生产运维来说，为了可能撑持这么大的体量，运维的压力十分大，包含监控告警、故障复原等。如果没有借助自动化、智能化的伎俩是很难满足运维的要求。这里咱们是与第三方公司一起单干研发 MySQL 的治理平台，具体的是爱可生公司。咱们也经验了很长的一段单干工夫，可能把这套货色打磨进去，根本笼罩了残缺的运维流程，特地是对故障的诊断和自动化的切换，成果也是十分好的。在这么多节点的大基数状况下，产生故障的总体概率会绝对较高，但都能够很好地应答，在故障时迅速切换，根本不会对业务造成影响。
当初这么大的体量，如果依照传统物理机的部署模式，资源节约会比拟大，特地是在 CPU 方面。因为 MySQL 失常应用的话，CPU 资源个别都会比拟低。这个问题行内看得比拟远，资源布局方面曾经实现了 90% 的容器化部署，目前大部分 MySQL 曾经运行在容器下面，成果也非常明显，使用率可能晋升 4-5 倍的水平。
本次我想重点介绍的内容是，当初外围利用接入到 MySQL，怎样才能保障生产运行的过程中，升高问题的数量和影响的水平？能够分为几个方面来讲：事先，咱们心愿可能在研发阶段尽快发现一些问题；事中，升高问题的影响；预先，心愿疾速定位到问题，迅速地予以解决。
二、治理思路与计划
这些就是对治理思路的总结。首先是根底标准的管理工作。对于咱们所须要做的工作，所有要求都是应该落在标准下面，心愿做到有理有据，对于前面问题的定位和责任的划分都会十分有帮忙。在此基础上，咱们进行三个方面的治理工作，包含事先、事中和预先。
2.1、标准起到的三个作用
首先标准可能制订操作的规范，例如建表的时候该怎么，每张表必须要有主键，建库建表甚至设计字段的时候不容许在 SQL 当中增加字符集和排序规定的属性，默认实例的属性就能够。
其次标准可做量化的管制，有时要求一条 SQL 扫描的数量与返回的数量都不能太多，执行工夫不能太长等等，从定性角度看问题都不大，但要落到实处，这样的要求是不够的，因而须要提供量化的指标。比方对慢 SQL，要求联机交易扫描的行数和后果集行数比不能超过 100：1。对于一个事务，更新的数量不能超过 10 万条。指标在开始设计时可能并不完满，但在应用的过程中一直钻研、欠缺，就可能定进去更细化的指标。对于开发或是运维，都要对这些程序的设计和运行有一个底线的意识，肯定不能越过这条线。
再是为了避开一些 Bug。一个例子是，大表的 Truncate 会导致数据库 hang 住，昨天农行的共事也有讲到，大家遇到的问题根本都是一样的。另外一个例子是 Replace into 的 Bug，会导致主备的元数据信息不统一，如果产生切换，新的主库插入数据的时候会呈现主键抵触，这个问题绝对比拟大。为防止此类问题，标准上会要求不容许应用。
2.2、具体标准内容有两个特点，供大家参考
标准应该是容易被了解的，所以在标准中特意针对每一个条款减少了一个解读的内容。尽管标准提出了一些要求，但在具体落实时还会有很多人并不知道为什么会有这样的要求。所以在文档当中减少了很多解释，能够让读者很清晰地晓得，除了不能这么做之外，还能晓得为什么不能这么做。
对于标准当中的内容，会尽量安顿落地，例如事先的治理方面，波及到表构造和代码的审核零碎，都是基于标准的内容安顿具体的落地。所以标准才会真正变成十分无效的工具，不会是一纸空文。
2.3、咱们三个次要工作，事先预防，事中应急，预先诊断
首先是事先预防工作
表构造的审核，是标准要求的落地实现，包含每个表必须建设主键，禁止独自设立字符排序规定，或者应用 TimeStamp 的数据类型等。行内目前的表构造审核零碎，除了进行审核之外还负责进行版本控制，次要有两种状况：对于新增表，建表的语句是由审核系统生成的，不须要人工来写代码，能够缩小很多不必要的谬误。这一点我也是深有体会。之前看到不少共事的表构造是从一个中央拷贝过去，有些属性不是很了解，特地是表的属性中存在存储引擎的属性、排序规定的属性，不晓得的话就本人带进来了，外面的要求可能都不是咱们想要的。当初咱们都是对立应用 InnoDB 引擎，要是不小心的话就会把 MyISAM 的表带入进来，所以隐患还是比拟大的。表构造变更，例如加一个字段或加一个索引，这也是由表构造审核系统生成，不须要人工实现。
代码审核方面，咱们在 MySQL 审核基本上都是基于 MyBatis 的开发方式，包含配置文件的扫描和实现，上面举的例子就是代码审核的要点。当初也是在继续地补充和欠缺。
健康检查方面，能够举个例子，是对于慢 SQL。这也是大部分公司在 MySQL 遇到最多的一类问题。咱们利用 MySQL 中的一张视图进行剖析，作为查看的一个根据。这张视图中记录了每一条 SQL 从 MySQL 开机到当初运行的计数器，比方截止到目前运行的次数，破费的工夫，扫描记录的条数。咱们利用这张表的计数器的特点，在两个工夫点采集雷同的表的数据，并且将两个工夫点的数据进行比拟，可失去这段时间内这些 SQL 运行的指标。对于雷同的语句在八点钟采集一次，在九点钟采集一次，之后两个数据相减就晓得 SQL 在八点钟到九点钟一共执行 100 次，执行工夫是 900 秒，扫描记录数是 9000 万。从这个数字来看，有些比拟敏感的共事，会发现单条记录的执行工夫应该是偏长的，并且单条记录扫描的记录数也显著偏多。那么这条 SQL 就有一个显著的效率问题，须要进行整改。大部分问题都是能够通过减少索引来解决。
事中应急
事中次要思考应急，并且是自动化应急。接触过生产的共事对应急应该是深有感触，要遇到一个问题之后开始剖析、定位问题，最初采取措施，两头这段时间可能是绝对不可控的，有时很快可能解决，但也有须要几十分钟甚至几个小时能力处理完毕，这时曾经对业务造成了十分大的影响。因而咱们更多的要思考，怎么实现这种自动化的应急伎俩。
对于监控查杀，咱们心愿可能通过监控实时地捕捉到性能上的问题，进行主动查杀的操作，也就是把对应的线程杀掉，防止问题的进一步扩充。方才屡次提到的慢 SQL，是咱们面临的最大敌人，次要包含两个方面的危害：很多时候，有大量的数据扫描，导致吃 CPU 资源。在大并发状况下，一条 SQL 能够吃掉一个 CPU，几十个 SQL 就可能把服务器的 CPU 吃光，问题的影响也是十分大。SQL 执行慢，并且有多个线程沉积的状况下，能够把 InnoDB 的线程池耗尽。在这种状况下，原来一些没有问题的 SQL，在执行的时候就会显著被拖慢，导致整个零碎交易全副受到影响。所以就不仅仅是慢 SQL 的交易，整个零碎的交易都会存在问题，影响很大。
咱们对此曾经实现联机交易的主动查杀性能，通过设置一个阈值，对于超过这个阈值的 SQL 主动杀掉。具体原理比较简单，通过相似 ProcessList 失去工夫点和线程 ID，而后去查杀。在这里有个特地要留神的中央，为了实现这些，咱们做了联机和批量用户拆散操作，针对不同用户进行差异性解决。次要是因为联机和批量的个性不一样，批量的 SQL 有时会要做大批量的解决，工夫是会比拟长，这是很失常的。联机基本上是短平快的操作，大部分都是毫秒级的，略微慢一点的可能是几秒钟，但十几秒、几十秒的话就是不失常了。所以是在用户拆散的前提下再进一步做慢 SQL 的查杀。
对于大事务，咱们的定义是在一个事务当中增删改的记录数超过肯定的阈值。目前定义的阈值是 10 万条记录，超过 10 万条就定义为一个大事务。具体危害性能够从这张图进行介绍。每笔交易都会经验一个记录 binlog 再从备库返回的过程，这是 MySQL 半同步最根本的操作。如果记录的内容比拟大，那么具体的量也随之十分大，不论是写入、传输还是落地方面工夫都会有显著差别。目前咱们感觉最大的问题在于，MySQL 主库写入 binlog 的解决都是单线程的，如果有一个交易写入，其它交易都是排队的状态。如果呈现大事务的话，其它交易就会被卡住。
在主库呈现梗塞的状况下，高可用的机制能够探测到主库长时间不可用，咱们就会去做主备的切换。然而在大事务的状况下，切还是不切是比拟大的问题。大事务的写入、传输和回放须要经验一个比拟漫长的阶段，如果马上用备库的话，数据就曾经不是最新的，也就是会丢掉一些数据；如果咱们期待回放，做完当前再切，可能工夫就不可承受了。所以这是一个两难的问题，咱们要尽量避免大事务。
为了做到严格的管制，咱们也对大事务实现了主动查杀，对于超过肯定的阈值主动执行和操作。
主动查杀也不是立刻可能施行，须要经验一直的小范畴的试点，先做监控报警，再做主动查杀，这样一步一步走下来。
有候咱们开玩笑，谈到删库跑路，例如遇到程序 Bug 有些数据会被误删，或者更新成其它咱们不须要的数据，这时候就须要进行数据恢复。惯例的方法是存量备份和增量 BinLog 进行追补。可追补的过程中是单线程的，基本上很难施行，因为存量备份都是每周一次，要是复原的数据是五六天之前，追补的数据范畴会十分大。咱们采纳两种计划：伪装成 Slave 进行回放，网上曾经有现成的案例；为了更快地进行复原，咱们借鉴了一些业界复原工具，次要包含两类，一类是 DML，比方 Delete 转化为 Insert，另一类是基于文件系统工具进行复原。
最初是预先诊断
最重要还是数据的采集可能残缺到位，对预先诊断才是有帮忙的。除了惯例的数据采集，针对 MySQL，还有些高密度和低密度的采集。高密度是针对后盾线程状况的采集，是为了解决一些霎时的性能稳定，有时只是一两分钟或者更短的十几秒、几十秒的稳定，通过高密度的采集可能作为预先剖析的根据。低密度是方才提到的慢 SQL 的性能数据，目前是十五分钟采集一次。SQL 的历史执行状况对问题剖析也非常有帮忙，也是十五分钟采集一次。
三、后续晋升思路
3.1、首先是问题的定位，有两方面
在问题产生之前，怎么在研发测试环境，甚至成长环境可能提前捕捉到；问题产生的时候怎么可能迅速地定位到问题，迅速采取一些措施解决。后面有提到检查和自动化的解决，但还是远远不够，还是有很多的晋升空间。
3.2、其次是问题的预判
依据一些性能数据，包含性能指标和 SQL 的执行状况、倒退曲线提前进行预判。比方有些表刚开始的数据量不是很大，即便有些 SQL 效率不高，执行的状况还是能够承受的。但随着数据量的增长，执行工夫和扫描数据量都在一直攀升，在达到一个临界值影响到具体业务之前，咱们心愿可能找到它，并且尽快修改过去。
3.3、最初是对于问题的自愈
当初心愿借助于智能自动化的伎俩，可能在呈现问题的时候主动地做修复，防止这些问题进一步扩充。例如，有些程序写得不够好，就会呈现全表扫描的状况，如果是在呈现问题后再去定位增加索引，时效性会比较慢。心愿咱们的程序可能主动发现这个问题，而后加上一个索引，能够让这个业务基本上不受到影响。
以上就是我的分享主题，可能讲得也不是很深，都是比拟浅的货色，心愿大家可能多多斧正。
嘉宾互动环节
嘉宾：工行的外围零碎是开源本人搭建的还是商用的产品？
林镇熙：咱们是用 MySQL 社区的开源版本，5.7，咱们是一主多从、两地三核心的架构。
嘉宾：你们是容器化部署还是物理机部署？
林镇熙：咱们 90% 以上都是容器化部署，就是应用 K8S 架构解决方案，存储是应用本地 SSD。
嘉宾：工行应用 MHA 架构吗？
林镇熙：咱们刚开始也有思考，剖析下来 MHA 有肯定的缺点，所以咱们是跟第三方公司一起单干研发一整套的运维平台，去实现故障的判断、定位和切换。
嘉宾：相当于工行本人研发了另外一套高可用零碎是吗？
林镇熙：是的。
嘉宾：工行还有 10% 的 MySQL 跑在物理机下面是吗？
林镇熙：是的。
嘉宾：工行容器化单机能够跑到多少实例数？
林镇熙：1 个主机是 4 个以上的容器，当初上线的是 4-8 个左右。
嘉宾：本地 SSD 还是共享存储？
林镇熙：本地 SSD。
对于爱可生
上海爱可生信息技术股份有限公司是国内开源数据库解决方案领导者、工业互联网高维数据利用创新者。爱可生为产业互联网翻新利用提供高性价比、疾速落地实现的多数据库治理平台、分布式数据库系统、数据库容器云平台、多地多核心跨云容灾等解决方案。
在工业互联网相干垂直行业，深入分析数据价值，构建数据中台和业务中台的根底软件 PaaS 平台，用数据技术驱动企业高质量增长。公司产品已被广泛应用于各行业，累计用户超过 400 家，其中包含工商银行、中国人寿、中国太保、国家电网、上汽团体、中国移动、华为等 30 多家世界 500 强企业。