本文由云+社区发表
作者介绍：简怀兵，腾讯云数据库高级工程师，负责腾讯云cdb内核及基础设施建设；先后供职于thomson reuters和yy等公司，ptimedb作者，曾获一项发明专利；从事mysql内核开发工作8年，具有丰富的优化经验；在分布式存储等领域有较丰富经验。
mysql数据库适用场景广泛，相较于oracle、db2性价比更高，web网站、日志系统、数据仓库等场景都有mysql用武之地，但是也存在对于事务性支持不太好（mysql 5.5版本开始默认引擎才是innodb事务型）、存在多个分支、读写效率瓶颈等问题。
所以如何用好mysql变得至关重要，一方面需要通过mysql优化找出系统读写瓶颈，提高数据库性能；另一方面需要合理涉及数据结构、调整参数，以提高用户操作响应；同时还有尽可能节省系统资源，以便系统可以提供更大负荷的服务。本文将为大家介绍腾讯云团队是如何对mysql进行内核级优化的思路和经验。
早期的cdb主要基于开源的oracle mysql分支，侧重于优化运维和运营的oss系统。在腾讯云，因为用户数的不断增加，对cdb for mysql提出越来越高的要求，腾讯云cdb团队针对用户的需求和业界发展的技术趋势，对cdb for mysql分支进行深度的定制优化。优化重点围绕内核性能、内核功能和外围oss系统三个维度展开，具体的做法如下：
由于腾讯云上的db基本都需要跨园区灾备的特性，因此cdb for mysql的优化主要针对主从db部署在跨园区网络拓扑的前提下，重点去解决真实部署环境下的性能难题。经过分析和调研，我们将优化的思路归纳为：“消除冗余i/o、缩短i/o路径和避免大锁竞争”。以下是内核性能的部分案例：
如上图所示，在原生mysql的复制架构中，master侧通过dump线程不断发送binlog事件给slave的i/o线程，slave的i/o线程在接受到binlog事件后，有两个主要的动作：
经过分析，我们的优化策略是：
如上图所示，经过优化：左图35.79%的锁竞争(futex)已经被完全消除；同压测压力下，56.15%的文件i/o开销被优化到19.16%，slave i/o线程被优化为预期的i/o密集型线程。
如上图所示，在原生mysql中多个事务提交线程trxn和多个dump线程之间会同时竞争binlog文件资源的保护锁，多个事务提交线程对binlog执行写入，多个dump线程从binlog文件读取数据并发送给slave。所有的线程之间是串行执行的！
优化方法
经过分析，我们的优化策略是：
效果
经过测试，优化后的内核，不仅提升了事务提交线程的性能，在dump线程较多的情况下，对主从复制性能有较大提升。
如上图所示，在原生mysql中主备库之间的数据发送和ack回应是简单的串行执行，在上一个事件ack回应到达之前，不允许继续发送下一个事件；这个行为在跨园区(rtt 2-3ms)的情况性能非常差，而且也不能很好地利用带宽优势。
经过分析，我们的优化策略是：
根据实际用例测试，优化后的tps提升为15%左右。
在腾讯云上，不时遇到用户app异常或者bug从而占满db的最大连接限制，这是cdb oss帐号无法登录以进行紧急的运维操作。针对这个现状，我们在mysql内核单独开辟了一个可配置的连接数配额，即便在上述场景下，运维帐号仍然可以连接到db进行紧急的运维操作。极大地降低了异常情况下db无政府状态的风险。该帐号仅有数据库运维管理权限，无法获取用户数据，也保证了用户数据的安全性。
针对一些应用对数据的一致性要求非常高，cdb在mysql原生半同步的基础上进行了深度优化，确保一个事务在主库上提交之前一定已经复制到至少一个备库上。确保主库宕机时数据的一致性。
除了以上提到的mysql内核侧的部分优化，我们也在外围oss平台进行了多处优化。例如使用异步mysql ping协议实现大量实例的监控、通过分布式技术来加固原有系统的ha/服务发现和自动扩容等功能、在数据安全/故障切换和快速恢复方面也进行了多处优化。
此文已由作者授权腾讯云+社区发布
如对本文有疑问， 点击进行留言回复！！
【MySQL牛客】10.获取所有非manager的员工emp_no
我要评论
网友评论