MySQL主从原理问题解决方案和应用.docx

1、MySQL主从原理问题解决方案和应用一MySQL主从同步基本流程二延迟的原因三解决方案一四解决方案二 Transfer五应用场景和业务限制六保障和退化七在多主同步的应用八不能解决的光速问题九不能解决的更新延迟MySQL主从同步基本流程MasterSlaveMySQL主从同步延迟原因什么是延迟2和6的时间间隔为什么延迟2、5的文件更新通知？不是3的网络延迟？不是4的写盘延迟？不是等等。1和2之间那个箭头怎么不画出来我们不关心MySQL主从同步延迟原因延迟原因主库更新多线程从库更新单线程都是箭头，你咋这么苗条呢？MySQL主从同步解决方案解决方案：从库变成多线程更新反问一句：三秒钟变格格么。有那么

2、好MySQL为什么不支持？说胖就胖了啊。MySQL主从同步解决方案直接多线程存在的问题：语句顺序无法保证insert和update调换有什么问题？又瘦回去了，怂了。MySQL主从同步解决方案导演说咔了吗？其实我准备变身，左上角的兄弟，后面好像都没你的戏份了，能不能先洗洗睡去？MySQL主从同步解决方案解决方案分析：1、一定要多线程！为什么？2、多线程又会打乱顺序3、总是有些没那么严格的，是吧？4、同一个表的更新必须按照顺序5、不同表呢？6、先作个不同表之间并行的，线上一个库都有很多表过渡太久了吧，变身的那位呢？MySQL主从同步解决方案Slave认不出来了，来个对比照MySQL主从同步解决方案

3、应该是解决了从此Master和Slave过着幸福的生活？太nave了。实际上，刚才那个是副导演导演回来了，说：咱这剧本不允许主角变身！未完待续MySQL主从同步解决方案方案考虑：多线程是ok的但是不能修改线上的代码就是Master和Slave都不能动变回来了，导演管饭，听导演的MySQL主从同步解决方案某路人。肿么这么眼熟MySQL主从同步解决方案MySQL主从同步解决方案以上为前传，介绍MySQL多线程同步工具(Transfer)的设计思路以下为文字解释版1. MySQL的主从同步延迟，是指从库的更新性能低于主库的更新性能。2. 相同的机器配置，出现性能差异的原因，是从库上单线程更新。MyS

4、QL主从同步解决方案3. 一种方案是将从库的单线程apply改成多线程，但需要修改slave的代码。4. 安全起见，以工具的形式提供多线程同步功能。5. Transfer也是一个MySQL，DBA一般部署在slave同一个机器上，放到/u01/mysql26. Transfer设置为Master的从库，接收日志后更新Slave7. 从Slave来看，Transfer是一个普通的Client。一MySQL主从同步基本流程二延迟的原因三解决方案一四解决方案二 Transfer五应用场景和业务限制六保障和退化七在多主同步的应用八不能解决的光速问题九不能解决的更新延迟Transfer的应用场景和业务限

5、制1. 多表业务 Transfer的策略是在io_thread接收主库日志后，分成16份不同的relay-log存放 再用16个sql_thread分别读取日志分发 确保同一个表的更新语句顺序与主库binlog相同2. 对Master的限制 主库设置binlog为row模式 (不支持Statement的原因） 主库单个语句的binlog不能超过1G (原因说明） 尽量减少一个语句更新两个表Transfer的应用场景和业务限制3. 对Slave的限制 设置max_allowed_packet = 1G 需要一个root权限账号提供给Transfer4. 对DDL语句的处理 0号线程的作用Tran

6、sfer的保障和退化1. 保障 Transfer本身挂了数据不丢（持久化的数据队列） Slave出错重启后，继续同步直接start slave Master重启后自动重新同步 维护方便。stop slave; change master; slave_skip_errors直接接入现成监控系统2. 退化 Statement模式下某些语句不支持。支持的语句性能也不提升事务打散 从库上不再支持rollback (什么时候从库会收到rollback?)效果对比原始性能Transfer方案性能一MySQL主从同步基本流程二延迟的原因三解决方案一四解决方案二 Transfer五应用场景和业务限制六保障和

7、退化七在多主同步的应用八不能解决的光速问题九不能解决的更新延迟Transfer在多主同步的应用多主复制的需求来源 备份节约机器 数据聚集分析理想方案MySQL不支持Transfer在多主同步的应用现在方案 浪费硬盘空间增加额外更新 更大的延迟Transfer在多主同步的应用Transfer方案一MySQL主从同步基本流程二延迟的原因三解决方案一四解决方案二 Transfer五应用场景和业务限制六保障和退化七在多主同步的应用八不能解决的光速问题九不能解决的更新延迟无法解决的光速问题抽象回简单场景，在解决cpu利用问题后，从库更新性能与主库相同新问题：跨机房单个数据延迟杭州到青岛线路就是那么长 20ms无法解决的光速问题回到最开始的一个问题什么是延迟无法解决的光速问题如果我们把延迟定义为 3到6的时间差呢？让用户多等20ms 换取数据一致性一起来讨论一MySQL主从同步基本流程二延迟的原因三解决方案一四解决方案二 Transfer五应用场景和业务限制六保障和退化七在多主同步的应用八不能解决的光速问题九不能解决的更新延迟不能解决的更新延迟这回我们关注6本身, 要求完全没有延迟怎么作？个耗时10ms的更新，至少延迟10ms全同步？no不要陷入锤子钉子的误区放弃这方案，用双写