《MySQL源码改造之并行复制改进-任赟婷.pdf》由会员分享，可在线阅读，更多相关《MySQL源码改造之并行复制改进-任赟婷.pdf（27页珍藏版）》请在三一文库上搜索。
1、MySQL源码改造之并行复制改进源码改造之并行复制改进 MySQL源码优化的探寻之路 任赟婷任赟婷 携程旅行网携程旅行网 背景 MySQL主从复制的单线程工作机制，常常是制约复制性能 的最大瓶颈。 MySQL 5.6开始支持Per-DB的多线程并行复制，但在单库 复制压力场景下仍然无能为力。 困境 首先遭遇到复制瓶颈的是zabbix后台数据库。 监控数据越来越多，slave早在master到达负载上限之前成为了 性能瓶颈。 复制频繁出现延迟问题，当slave有查询压力更加明显。 新增slave节点的耗时也越来越长，整个部署周期超过5天。 需求 为了缓解复制压力，我们根据监控对象的不同拆分了多
2、组 zabbix系统。但是，复制的性能上限仍然严格限制了每组 zabbix系统能承担的容量上限。 能不能有一种拆分粒度更细化的并行复制，来提高slave上 的写入速度？ 探索 在寻求解决方案的道路上，首先考虑尽可能使用已有的成 熟方案。于是在我们面前有两个选择： 1. MySQL主从同步加速transfer （by taobao） 2. MariaDB 10（引入了新的并行复制功能） 探索（续） 关于Transfer： 1. 暂没有对应官方5.6.12版本的patch。 2. 最新的发布形式是可执行的mysqld文件。 3. 要求主库的binlog格式必须是row（我们的标准配置是 mixed
3、，row模式的replace语句可能出现自增长问题） create table test ( a int(11) default null, id int(11) not null auto_increment, b int(11) default null, primary key (id), unique key d (d) ); insert into test values(5,27,4); replace into test(a,id,b) values(6,35,4); commit; show create table时： 主库：auto_increment=36 备库：auto
4、_increment=28 探索（续） 关于MariaDB 10： 从长远来说这是最佳解决方案，通用且能保证从机事务一 致性完全忠实于主机（by google）。 问题在于，首个GA版刚发布不久，在正式引入线上环境之 前，还有更多事情要做。 方向 既然没有马上能用的现成方案，何不尝试下自己造？ 于是，我们决定以并行复制的需求为契机，作为我们进行 MySQL自定制改造的起点，逐步踏入MySQL源码研究和优 化的领域。 起步 基于MySQL 5.6的多线程复制实现，依赖原生参数 slave_parallel_workers设置复制的工作线程数。 先进行最基本的尝试，调整MySQL的复制SQL进程，
5、改造 Log_event类get_slave_worker事件处理线程的获取方式。 获取后将事件拆分，在多个slave工作线程中，轮流选择， 执行事件。 1、在函数Log_event:get_slave_worker中建立将分配worker的工作交给新的分配函数 2、构造自己的分配函数 复制分发事件 Worker 事件 Worker 事件 Worker 事件 Worker 执行 复制分发事件 Worker DB事件 Worker 执行 原复制分发处理方式 改进后的复制分发处理方式 问题1 必然问题：由于操作并行后顺序被打乱，引起数据一致性 校验问题，例如外键约束等。 解决思路：针对类似zabb
6、ix的应用，具有两个明显特点 1. 大量写入集中在几个特定的表； 2. 这些表的写入对顺序并不敏感。 解决1 增加参数变量slave-parallel-simple-tables用来配置需要进行 事件拆分的表名。同时增加了变量slave-parallel-simple用 来动态开关自定义的表级别并行复制。 进一步改造get_slave_worker事件处理线程，针对指定表的 DML事件进行拆分，并在多个slave工作线程中，轮流选择 执行。不符合拆分规则的，仍然保持串行处理。 复制分发事件 Worker 事件 Worker 事件 Worker 事件 Worker 执行 改进后的复制分发处理方式
7、 等待执行列表 DML 1 : of table A ; DML 2 : of table B ; DML 3 : of table C ; DML 4 : of table A ; DML 1; DML 2; DML 3; DML 4; 操作顺序被打乱会引起数据一致性问题 DML 1; DML 2; DML 3; DML 4; 改进后只对指定表进行事件拆分，其 他表保持原有顺序 问题2 在成功实现针对指定表进行事件拆分后，我们意外地发现 在slave运行不久后就会出现复制线程夯住的现象。并且无 法通过stop slave停止，整个实例出现挂死的情况。 经过调试排查，分析最可能的问题在于事件拆
8、分后事务被 破坏了。多语句事务被拆分后，可能出现事务开始和结束 的标识分别在两个工作线程中执行。 解决2 找到问题后解决方案也就随之确定，对于多语句的事务， 在拆分后必须进行补齐，把事务的开始和结束标志补充完 整。 事务开始时所需的信息记录 事务中事件的处理 事务结束时 复制分发事件 Worker 事件 Worker 事件 Worker 事件 Worker 执行 改进后的复制分发处理方式 等待执行列表 Begin DML 1 : of table A ; DML 2 : of table B ; DML 3 : of table C ; DML 4 : of table A ; Commit
9、事务完整性被破坏，运行不正常 Begin DML 1; DML 2; DML 3; DML 4; Commit 改进后，拆分前后的事务保持各自完 整性 Begin DML 1; Commit Begin DML 4; Commit Begin DML 2; DML 3; Commit 实现 在修正了以上两个大问题和其余一堆小问题后，初步的可 用成品终于诞生了。总共完成11个文件的修改，一千多行 的变化。 配置实例： slave_parallel_workers=5（并行工作线程数） slave_parallel_simple=1（是否开启自定义并行复制） slave_parallel_simp
10、le_tables= history;history_uint;trends;trends_uint （对这4张表的操作进行拆分） 线上zabbix运行超过3个月，功能性和稳定性都已经得到验 证。 VS 测试方法：在同一台服务器上分别开关并行复制，停用复 制SQL进程一段时间后开启，对比测试复制容量上限。 测试环境：16Core CPU + 64G内存 + PCIE SSD 磁盘，zabbix 数据库大小超过1T。 测试场景：在MySQL不同buffer size和redolog个数的配置组 合下对比。并在其中一个场景增加自定义查询增加压力。 结果 测试场景 1 16Gbuf+2log 2 1
11、6Gbuf+4log 3 32Gbuf+2log 4 32Gbuf+4log 5 32Gbuf+4log+query 原生版均值(kWPS) 40.92 41.84 70 76.7 51.47 改进版均值(kWPS) 74.38 75.56 92.71 113.55 90.09 均值提升比例% 81.77% 80.59% 32.44% 48.04% 75.03% 0.00 10.00 20.00 30.00 40.00 50.00 60.00 70.00 80.00 90.00 0 20 40 60 80 100 120 1 2 3 4 5 原生版均值(kWPS) 改进版均值(kWPS) 均值
12、提升比例% 结论 根据测试结果来看，在服务器性能负载较高的情况下（例 如内存交换频繁、刷磁盘动作频繁），并行复制的提升更 加明显，最高可达到80%的提升。 在最接近现实情况的场景5（增加了额外的数据查询压 力），并行复制的性能提升可以达到75%。 不足 自增长表的支持问题：对SET INSERT_ID的事件没有特殊处 理，当做普通事件进行了拆分，导致主从数据的自增长值 不一致。 配置只能指定表名，多库存在同名表时无法区分。 复制是MySQL的核心功能，当进行版本升级时（即使是小 版本），功能合并到新版本的成本很高。 收获 显式收获： 1. 已应用到各zabbix系统，提升了复制的容量上限。 2. 新增slave节点用于迁移或扩容时，大大缩短了部署时间。 隐式收获： 成功的第一步，获得了成长和经验，为后续的源码优化工作奠定了基础。 例如，在这之后顺利而快速地完成了另一个源码改进版， slow log记录机制优 化。增加了根据完整执行时间（包含锁等待）来进行慢查询判断的机制。并 且已经成功在大范围生产业务环境稳定运行。 未来 短期计划：进一步进行功能性改进，解决现有问题。 长期计划：复制功能改进插件化，便于不同版本或分支产 品之间迁移。