MySQL源码改造之并行复制改进MySQL源码优化的探寻之路任赟婷携程旅行网背景MySQL主从复制的单线程工作机制,常常是制约复制性能的最大瓶颈。-DB的多线程并行复制,但在单库复制压力场景下仍然无能为力。困境首先遭遇到复制瓶颈的是zabbix后台数据库。监控数据越来越多,slave早在master到达负载上限之前成为了性能瓶颈。复制频繁出现延迟问题,当slave有查询压力更加明显。新增slave节点的耗时也越来越长,整个部署周期超过5天。需求为了缓解复制压力,我们根据监控对象的不同拆分了多组zabbix系统。但是,复制的性能上限仍然严格限制了每组zabbix系统能承担的容量上限。能不能有一种拆分粒度更细化的并行复制,来提高slave上的写入速度?探索在寻求解决方案的道路上,首先考虑尽可能使用已有的成熟方案。于是在我们面前有两个选择:MySQL主从同步加速transfer(bytaobao)MariaDB10(引入了新的并行复制功能)探索(续)关于Transfer:。最新的发布形式是可执行的mysqld文件。要求主库的binlog格式必须是row(我们的标准配置是mixed,row模式的replace语句可能出现自增长问题)createtabletest(aint(11)defaultnull,idint(11)notnullauto_increment,bint(11)defaultnull,primarykey(id),uniquekeyd(d));insertintotestvalues(5,27,4);replaceintotest(a,id,b)values(6,35,4);commit;showcreatetable时:主库:auto_increment=36备库:auto_increment=28探索(续)关于MariaDB10:从长远来说这是最佳解决方案,通用且能保证从机事务一致性完全忠实于主机(bygoogle)。问题在于,首个GA版刚发布不久,在正式引入线上环境之前,还有更多事情要做。方向既然没有马上能用的现成方案,何不尝试下自己造?于是,我们决定以并行复制的需求为契机,作为我们进行MySQL自定制改造的起点,逐步踏入MySQL源码研究和优化的领域。,依赖原生参数slave_parallel_workers设置复制的工作线程数。先进行最基本的尝试,调整MySQL的复制SQL进程,改造Log_event类get_slave_worker事件处理线程的获取方式。获取后将事件拆分,在多个slave工作线程中,轮流选择,执行事件。1、在函数Log_event::get_slave_worker中建立将分配worker的工作交给新的分配函数2、构造自己的分配函数
mysql源码改造之并行复制改进 来自淘豆网m.daumloan.com转载请标明出处.
