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
不要陷入锤子钉子的误区
放弃这方案,用双写