MySQL主从原理问题解决方案和应用.docx
《MySQL主从原理问题解决方案和应用.docx》由会员分享，可在线阅读，更多相关《MySQL主从原理问题解决方案和应用.docx（28页珍藏版）》请在冰点文库上搜索。
MySQL主从原理问题解决方案和应用
一．MySQL主从同步基本流程二．延迟的原因
三．解决方案一
四．解决方案二－－Transfer五．应用场景和业务限制
六．保障和退化
七．在多主同步的应用
八．不能解决的光速问题
九．不能解决的更新延迟
MySQL主从同步基本流程
Master
Slave
MySQL主从同步延迟原因
什么是延迟－－2和6的时间间隔
为什么延迟
2、5的文件更新通知？
不是3的网络延迟？
不是
4的写盘延迟？
不是
等等。
。
。
1和2之间那个箭头怎么不画出来－－我们不关心
MySQL主从同步延迟原因
延迟原因
主库更新多线程
从库更新单线程
都是箭头，你咋这么苗条呢？
MySQL主从同步解决方案
解决方案：
从库变成多线程更新
反问一句：
三秒钟变格格么。
有那么好MySQL为什么不支持？
说胖就胖了啊。
。
。
MySQL主从同步解决方案
直接多线程存在的问题：
语句顺序无法保证－－insert和update调换有什么问题？
又瘦回去了，怂了。
。
。
MySQL主从同步解决方案
导演说咔了吗？
其实我准备变身，
左上角的兄弟，
后面好像都没你的戏份了，
能不能先洗洗睡去？
MySQL主从同步解决方案
解决方案分析：
1、一定要多线程！
为什么？
2、多线程又会打乱顺序
3、总是有些没那么严格的，是吧？
4、同一个表的更新必须按照顺序
5、不同表呢？
6、先作个不同表之间并行的，线上一个库都有很多表
过渡太久了吧，变身的那位呢？
MySQL主从同步解决方案
Slave
认不出来了，来个对比照
MySQL主从同步解决方案
应该是解决了
从此Master和Slave过着幸福的生活？
太naïve了。
。
。
实际上，刚才那个是副导演
导演回来了，说：
咱这剧本不允许主角变身！
未完待续
MySQL主从同步解决方案
方案考虑：
多线程是ok的
但是不能修改线上的代码
就是Master和Slave都不能动
变回来了，导演管饭，听导演的
MySQL主从同步解决方案
某路人
。
。
。
肿么这么眼熟
MySQL主从同步解决方案
MySQL主从同步解决方案
以上为前传，介绍MySQL多线程同步工具（Transfer）的设计思路以下为文字解释版
1.MySQL的主从同步延迟，是指从库的更新性能低于主库的更新
性能。
2.相同的机器配置，出现性能差异的原因，是从库上单线程更新。
MySQL主从同步解决方案
3.一种方案是将从库的单线程apply改成多线程，但需要修改slave
的代码。
4.安全起见，以工具的形式提供多线程同步功能。
5.Transfer也是一个MySQL，DBA一般部署在slave同一个机器上，
放到/u01/mysql2
6.Transfer设置为Master的从库，接收日志后更新Slave
7.从Slave来看，Transfer是一个普通的Client。
一．MySQL主从同步基本流程二．延迟的原因
三．解决方案一
四．解决方案二－－Transfer五．应用场景和业务限制
六．保障和退化
七．在多主同步的应用
八．不能解决的光速问题
九．不能解决的更新延迟
Transfer的应用场景和业务限制
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权限账号提供给Transfer
4.对DDL语句的处理
Ø0号线程的作用
Transfer的保障和退化
1.保障
ØTransfer本身挂了数据不丢（持久化的数据队列）
ØSlave出错重启后，继续同步直接startslave
ØMaster重启后自动重新同步
Ø维护方便。
•stopslave;changemaster;slave_skip_errors
•直接接入现成监控系统
2.退化
ØStatement模式下某些语句不支持。
支持的语句性能也不提升Ø事务打散
Ø从库上不再支持rollback（什么时候从库会收到rollback?
）
效果对比
原始性能
Transfer方案性能
一．MySQL主从同步基本流程二．延迟的原因
三．解决方案一
四．解决方案二－－Transfer五．应用场景和业务限制
六．保障和退化
七．在多主同步的应用
八．不能解决的光速问题
九．不能解决的更新延迟
Transfer在多主同步的应用
多主复制的需求来源
Ø备份节约机器
Ø数据聚集分析
理想方案
MySQL不支持
Transfer在多主同步的应用
现在方案
Ø浪费硬盘空间Ø增加额外更新
Ø更大的延迟
Transfer在多主同步的应用
Transfer方案
一．MySQL主从同步基本流程二．延迟的原因
三．解决方案一
四．解决方案二－－Transfer五．应用场景和业务限制
六．保障和退化
七．在多主同步的应用
八．不能解决的光速问题
九．不能解决的更新延迟
无法解决的光速问题
抽象回简单场景，在解决cpu利用问
题后，从库更新性能与主库相同
新问题：
跨机房单个数据延迟
杭州到青岛线路就是那么长20ms
无法解决的光速问题
回到最开始的一个问题
什么是延迟
无法解决的光速问题
如果我们把延迟定义为3到6的时间差呢？
让用户多等20ms换取数据一致性
一起来讨论
一．MySQL主从同步基本流程二．延迟的原因
三．解决方案一
四．解决方案二－－Transfer五．应用场景和业务限制
六．保障和退化
七．在多主同步的应用
八．不能解决的光速问题
九．不能解决的更新延迟
不能解决的更新延迟
这回我们关注6本身,要求
完全没有延迟怎么作？
个耗时10ms的更
新，至少延迟10ms
全同步？
－－no
不要陷入锤子钉子的误区
放弃这方案，用双写
升级会员 