MySQL源码改造之并行复制改进

　　接下来为大家介绍下今天下午第二位做主题演讲的嘉宾，携程MySQL数据库团队高级经理任赟婷，2007年毕业于上海交通大学信息安全学院后加入携程数据库团队。建立MySQL数据库团队，现在带领团队负责携程的MySQL和Mongo数据库的管理，包括MySQL的架构审核、SQL审核、自动化运维工具的开发维护等工作。

▲携程MySQL数据库团队高级经理 任赟婷

　　今天带来了《MySQL源码改造之并行复制改进》的主题分享，演讲内容主要包括：

　　一、实现方式：对MySQL的复制SQL进程进行调整，改造Log_event类中的get_slave_worker事件处理线程的获取方式。针对指定表的insert/delete/update事件，从事件组(以事务开始事件和事务提交事件为头尾的一组事件)中独立出来。在多个slave工作线程中，进行轮流选择，进行指定表事件的执行。

　　二、功能及特点：1、基于MySQL5.6的DB级并行复制实现，无需在主从架构中引入其他组件;2、可配置的应用范围，对指定表进行并行同步;3、动态开关，可随时打开或关闭表级别并行复制;4、高写入负载zabbix后台mysql,复制性能提升50%.

　　背景：MySQL主从复制的单线程工作机制，常常是制约复制性能的最大瓶颈。MySQL 5.6开始支持Per-DB的多线程并行复制，但在单库复制压力场景下仍然无能为力。

　　困境：首先遭遇到复制瓶颈的是zabbix后台数据库;监控数据越来越多，slave早在master到达负载上限之前成为了性能瓶颈;复制频繁出现延迟问题，当slave有查询压力更加明显;新增slave节点的耗时也越来越长，整个部署周期超过5天。

　　需求：为了缓解复制压力，我们根据监控对象的不同拆分了多组zabbix系统。但是，复制的性能上限仍然严格限制了每组zabbix系统能承担的容量上限。能不能有一种拆分粒度更细化的并行复制，来提高slave上的写入速度?

　　探索：在寻求解决方案的道路上，首先考虑尽可能使用已有的成熟方案。于是在我们面前有两个选择：1,MySQL主从同步加速transfer (by taobao);2,MariaDB 10(引入了新的并行复制功能)。

　　关于Transfer:1,暂没有对应官方5.6.12版本的patch.2,最新的发布形式是可执行的mysqld文件。3,要求主库的binlog格式必须是row(我们的标准配置是mixed,row模式的replace语句可能出现自增长问题)。

　　关于MariaDB 10:1,从长远来说这是非常好的解决方案，通用且能保证从机事务一致性完全忠实于主机(by google)。2,问题在于，首个GA版刚发布不久，在正式引入线上环境之前，还有更多事情要做。

　　方向：既然没有马上能用的现成方案，何不尝试下自己造?于是，我们决定以并行复制的需求为契机，作为我们进行MySQL自定制改造的起点，逐步踏入MySQL源码研究和优化的领域。

　　起步：基于MySQL 5.6的多线程复制实现，依赖原生参数slave_parallel_workers设置复制的工作线程数。先进行最基本的尝试，调整MySQL的复制SQL进程，改造Log_event类get_slave_worker事件处理线程的获取方式。获取后将事件拆分，在多个slave工作线程中，轮流选择，执行事件。

　　问题一：必然问题：由于操作并行后顺序被打乱，引起数据一致性校验问题，例如外键约束等。解决思路：针对类似zabbix的应用，具有两个明显特点，大量写入集中在几个特定的表;这些表的写入对顺序并不敏感。

　　解决一：增加参数变量slave-parallel-simple-tables用来配置需要进行事件拆分的表名。同时增加了变量slave-parallel-simple用来动态开关自定义的表级别并行复制。进一步改造get_slave_worker事件处理线程，针对指定表的DML事件进行拆分，并在多个slave工作线程中，轮流选择执行。不符合拆分规则的，仍然保持串行处理。

　　结论：根据测试结果来看，在服务器性能负载较高的情况下(例如内存交换频繁、刷磁盘动作频繁)，并行复制的提升更加明显，最高可达到80%的提升。在最接近现实情况的场景(增加了额外的数据查询压力)，并行复制的性能提升可以达到75%.

　　不足：自增长表的支持问题：对SET INSERT_ID的事件没有特殊处理，当做普通事件进行了拆分，导致主从数据的自增长值不一致。配置只能指定表名，多库存在同名表时无法区分。复制是MySQL的核心功能，当进行版本升级时(即使是小版本)，功能合并到新版本的成本很高。

　　收获：显式收获：已应用到各zabbix系统，提升了复制的容量上限。新增slave节点用于迁移或扩容时，大大缩短了部署时间。隐式收获：成功的第一步，获得了成长和经验，为后续的源码优化工作奠定了基础。例如，在这之后顺利而快速地完成了另一个源码改进版， slow log记录机制优化。增加了根据完整执行时间(包含锁等待)来进行慢查询判断的机制。并且已经成功在大范围生产业务环境稳定运行。

　　未来：短期计划：进一步进行功能性改进，解决现有问题。长期计划：复制功能改进插件化，便于不同版本或分支产品之间迁移。