MySQL_transfer

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,MySQL,主从同步,原理、问题、解决方案和应用,淘宝丁奇,2009-8-22,讲师介绍,讲师简介：,丁奇：,08,年至,10,年在百度贴吧，作服务端开发，开始接触,MySQL,。之后由于业务需要开始看,MySQL,代码，囫囵吞枣不求甚解。,10,年得机会进入淘宝核心系统数据库组，主要是,MySQL,优化和提升可维护性。参与,IC,、,TC,读库调优；写了一些插件，打了几个,patch,到官方；实现,MySQL,主从同步工具、设计,MySQL,异构数据同步方案、,MySQL,中间层。一直游离在了解需求、设计方案、推广方案的三点一线上。,课程目标与目标学员页,目标学员：对存储引擎、系统优化有兴趣的同学。,课程目的,:,介绍主从同步的概念、原理、存在的问题和优化思路。,学员能够获得的收获：主从同步的基本配置步骤和注意事项、探讨追查和解决问题的思路,MySQL,主从同步基本概念和配置步骤,MySQL,主从同步基本流程,延迟的原因,解决方案一,解决方案二,Transfer,应用场景和业务限制,保障和退化,在多主同步的应用,不能解决的光速问题,不能解决的更新延迟,MySQL,主从同步基本概念和配置步骤,用于实例之间同步数据，可以级联,只需要更新主库,备库用于备份或查询分流,配置注意事项,主库必须开启,binlog,Master,和,slave,的,server-id,不能相同,同一个,Maser,的多个,slave,，,server-id,也不能相同,Binlog_format,最好相同。,在,log-slave-updates=1,时，不允许,Master,是,row,，,slave,是,statement,这种是不允许的。,MySQL,主从同步基本概念和配置步骤,(,续,),配置基本步骤,主库上,grant,权限,从库上,change master to;,Start slave,问题,MySQL,主从同步基本流程,Master,Slave,MySQL,主从同步延迟原因,1,2,3,4,5,6,什么是延迟,2,和,6,的时间间隔,为什么延迟,2,、,5,的文件更新通知？不是,3,的网络延迟？不是,4,的写盘延迟？不是,等等。,1,和,2,之间那个箭头怎么不画出来我们不关心,MySQL,主从同步延迟原因,都是箭头，你咋这么苗条呢？,延迟原因,主库更新多线程,从库更新单线程,MySQL,主从同步解决方案,说胖就胖了啊。,解决方案：,从库变成多线程更新,反问一句：,三秒钟变格格么。有那么好,MySQL,为什么不支持？,MySQL,主从同步解决方案,又瘦回去了，怂了。,直接多线程存在的问题：,语句顺序无法保证,insert,和,update,调换有什么问题？,MySQL,主从同步解决方案,导演说咔了吗？,其实我准备变身，,左上角的兄弟，,后面好像都没你的戏份了，,能不能先洗洗睡去？,咔,解决方案分析：,1,、一定要多线程！为什么？,2,、多线程又会打乱顺序,3,、总是有些没那么严格的，是吧？,4,、同一个表的更新必须按照顺序,5,、不同表呢？,6,、先作个不同表之间并行的，线上一个库都有很多表,MySQL,主从同步解决方案,过渡太久了吧，变身的那位呢？,MySQL,主从同步解决方案,Slave,认不出来了，来个对比照,应该是解决了,从此,Master,和,Slave,过着幸福的生活？,太,nave,了。,实际上，刚才那个是副导演,导演回来了，说：,MySQL,主从同步解决方案,咱这剧本不允许主角变身！,未完待续,MySQL,主从同步解决方案,变回来了，导演管饭，听导演的,方案考虑：,多线程是,ok,的,但是不能修改线上的代码,就是,Master,和,Slave,都不能动,MySQL,主从同步解决方案,某路人,。肿么这么眼熟,MySQL,主从同步解决方案,以上为前传，介绍,MySQL,多线程同步工具,(Transfer),的设计思路,以下为文字解释版,MySQL,主从同步解决方案,MySQL,的主从同步延迟，是指从库的更新性能低于主库的更新性能。,相同的机器配置，出现性能差异的原因，是从库上单线程更新。,MySQL,主从同步解决方案,一种方案是将从库的单线程,apply,改成多线程，但需要修改,slave,的代码。,安全起见，以工具的形式提供多线程同步功能。,Transfer,也是一个,MySQL,，,DBA,一般部署在,slave,同一个机器上，放到,/u01/mysql2,Transfer,设置为,Master,的从库，接收日志后更新,Slave,从,Slave,来看，,Transfer,是一个普通的,Client,。,MySQL,主从同步基本概念和配置步骤,MySQL,主从同步基本流程,延迟的原因,解决方案一,解决方案二,Transfer,应用场景和业务限制,保障和退化,在多主同步的应用,不能解决的光速问题,不能解决的更新延迟,Transfer,的应用场景和业务限制,多表业务,Transfer,的策略是在,io_thread,接收主库日志后，分成,16,份不同的,relay-log,存放,再用,16,个,sql_thread,分别读取日志分发,确保同一个表的更新语句顺序与主库,binlog,相同,对,Master,的限制,主库设置,binlog,为,row,模式,(,不支持,Statement,的原因）,主库单个语句的,binlog,不能超过,1G(,原因说明）,尽量减少一个语句更新两个表,Transfer,的应用场景和业务限制,对,Slave,的限制,设置,max_allowed_packet=1G,需要一个,root,权限账号提供给,Transfer,对,DDL,语句的处理,0,号线程的作用,Transfer,的保障和退化,保障,Transfer,本身挂了数据不丢（持久化的数据队列）,Slave,出错重启后，继续同步直接,start slave,Master,重启后自动重新同步,维护方便。,stop slave;change master;slave_skip_errors,直接接入现成监控系统,退化,Statement,模式下某些语句不支持。支持的语句性能也不提升,事务打散,从库上不再支持,rollback(,什么时候从库会收到,rollback?),Transfer,方案性能,原始性能,效果对比,MySQL,主从同步基本概念和配置步骤,MySQL,主从同步基本流程,延迟的原因,解决方案一,解决方案二,Transfer,应用场景和业务限制,保障和退化,在多主同步的应用,不能解决的光速问题,不能解决的更新延迟,Transfer,在多主同步的应用,多主复制的需求来源,备份节约机器,数据聚集分析,理想方案,MySQL,不支持,Transfer,在多主同步的应用,现在方案,浪费硬盘空间,增加额外更新,更大的延迟,Transfer,在多主同步的应用,Transfer,方案,MySQL,主从同步基本概念和配置步骤,MySQL,主从同步基本流程,延迟的原因,解决方案一,解决方案二,Transfer,应用场景和业务限制,保障和退化,在多主同步的应用,不能解决的光速问题,不能解决的更新延迟,无法解决的光速问题,抽象回简单场景，在解决,cpu,利用问题后，从库更新性能与主库相同,新问题：,跨机房单个数据延迟,杭州到青岛线路就是那么长,20ms,1,2,3,4,5,6,回到最开始的一个问题,什么是延迟,无法解决的光速问题,1,2,3,4,5,6,如果我们把延迟定义为,3,到,6,的时间差呢？,无法解决的光速问题,让用户多等,20ms,换取数据一致性,一起来讨论,MySQL,主从同步基本概念和配置步骤,MySQL,主从同步基本流程,延迟的原因,解决方案一,解决方案二,Transfer,应用场景和业务限制,保障和退化,在多主同步的应用,不能解决的光速问题,不能解决的更新延迟,1,2,3,4,5,6,一个耗时,10ms,的更新，至少延迟,10ms,不能解决的更新延迟,全同步？,no,这回我们关注,6,本身,要求完全没有延迟怎么作？,不要陷入锤子钉子的误区,放弃这方案，用双写,MySQL,官方版,5.6,的多线程同步介绍,&,启发,按,DB,分线程,为什么我们当时没这么作？,跨,DB,的则线程合并,为什么我们当时没这么作？,Transfer,与其实质区别是粒度不同,被按,DB,分提醒了,后续改进,课程回顾、总结页,如何配置主从同步,主从同步原理,主从同步性能问题现状,优化方向,安全的妥协方案,Transfer,的其他应用,谢谢,