MySQL 主从原理、问题、解决方案和应用——丁奇

1. MySQL主从同步－－原理、问题、解决方案和应用 @淘宝丁奇 2009-8-22

2. 一．MySQL主从同步基本流程二．延迟的原因三．解决方案一四．解决方案二－－Transfer 五．应用场景和业务限制六．保障和退化七．在多主同步的应用八．不能解决的光速问题九．不能解决的更新延迟

3. MySQL主从同步基本流程 Master Slave

4. MySQL主从同步延迟原因什么是延迟－－2和6的时间间隔 1 为什么延迟 2、5的文件更新通知？不是 2 3的网络延迟？不是 4的写盘延迟？不是 3 5 6 4 等等。。。1和2之间那个箭头怎么不画出来－－我们不关心

5. MySQL主从同步延迟原因延迟原因主库更新多线程从库更新单线程都是箭头，你咋这么苗条呢？

6. MySQL主从同步解决方案解决方案：从库变成多线程更新反问一句：三秒钟变格格么。有那么好 MySQL为什么不支持？说胖就胖了啊。。。

7. MySQL主从同步解决方案直接多线程存在的问题：语句顺序无法保证－－insert和 update调换有什么问题？又瘦回去了，怂了。。。

8. MySQL主从同步解决方案咔～导演说咔了吗？其实我准备变身，左上角的兄弟，后面好像都没你的戏份了，能不能先洗洗睡去？

9. MySQL主从同步解决方案解决方案分析： 1、一定要多线程！为什么？ 2、多线程又会打乱顺序 3、总是有些没那么严格的，是吧？ 4、同一个表的更新必须按照顺序 5、不同表呢？ 6、先作个不同表之间并行的，线上一个库都有很多表过渡太久了吧，变身的那位呢？

10. MySQL主从同步解决方案 Slave 认不出来了，来个对比照

11. MySQL主从同步解决方案应该是解决了从此Master和Slave过着幸福的生活？太naï ve了。。。实际上，刚才那个是副导演导演回来了，说：咱这剧本不允许主角变身！未完待续

12. MySQL主从同步解决方案方案考虑：多线程是ok的但是不能修改线上的代码就是Master和Slave都不能动变回来了，导演管饭，听导演的

13. MySQL主从同步解决方案某路人。。。肿么这么眼熟

14. MySQL主从同步解决方案

15. MySQL主从同步解决方案以上为前传，介绍MySQL多线程同步工具(Transfer)的设计思路以下为文字解释版 1. MySQL的主从同步延迟，是指从库的更新性能低于主库的更新性能。 2. 相同的机器配置，出现性能差异的原因，是从库上单线程更新。

16. MySQL主从同步解决方案 3. 一种方案是将从库的单线程apply改成多线程，但需要修改slave 的代码。 4. 安全起见，以工具的形式提供多线程同步功能。 5. Transfer也是一个MySQL，DBA一般部署在slave同一个机器上

17. 一．MySQL主从同步基本流程二．延迟的原因三．解决方案一四．解决方案二－－Transfer 五．应用场景和业务限制六．保障和退化七．在多主同步的应用八．不能解决的光速问题九．不能解决的更新延迟

18. Transfer的应用场景和业务限制 1. 多表业务  Transfer的策略是在io_thread接收主库日志后，分成16份不同的 relay-log存放  再用16个sql_thread分别读取日志分发  确保同一个表的更新语句顺序与主库binlog相同 2. 对Master的限制  主库设置binlog为row模式 (不支持Statement的原因）  主库单个语句的binlog不能超过1G (原因说明）  尽量减少一个语句更新两个表

19. Transfer的应用场景和业务限制 3. 对Slave的限制  设置max_allowed_packet = 1G  需要一个root权限账号提供给Transfer 4. 对DDL语句的处理  0号线程的作用

20. Transfer的保障和退化 1. 保障  Transfer本身挂了数据不丢（持久化的数据队列）  Slave出错重启后，继续同步直接start slave  Master重启后自动重新同步  维护方便。 • stop slave; change master; slave_skip_errors • 直接接入现成监控系统 2. 退化  Statement模式下某些语句不支持。支持的语句性能也不提升  事务打散  从库上不再支持rollback (什么时候从库会收到rollback?)

21. 效果对比原始性能 Transfer方案性能

22. 一．MySQL主从同步基本流程二．延迟的原因三．解决方案一四．解决方案二－－Transfer 五．应用场景和业务限制六．保障和退化七．在多主同步的应用八．不能解决的光速问题九．不能解决的更新延迟

23. Transfer在多主同步的应用多主复制的需求来源  备份节约机器  数据聚集分析理想方案 MySQL不支持

24. Transfer在多主同步的应用现在方案  浪费硬盘空间  增加额外更新  更大的延迟

25. Transfer在多主同步的应用 Transfer方案

26. 一．MySQL主从同步基本流程二．延迟的原因三．解决方案一四．解决方案二－－Transfer 五．应用场景和业务限制六．保障和退化七．在多主同步的应用八．不能解决的光速问题九．不能解决的更新延迟

27. 无法解决的光速问题抽象回简单场景，在解决cpu利用问题后，从库更新性能与主库相同新问题：跨机房单个数据延迟杭州到青岛线路就是那么长 20ms

28. 无法解决的光速问题回到最开始的一个问题 1 什么是延迟 2 3 5 4 6

29. 无法解决的光速问题如果我们把延迟定义为 3到6的时间差呢？ 1 让用户多等20ms 换取数据一致性一起来讨论 2 3 5 4 6

30. 一．MySQL主从同步基本流程二．延迟的原因三．解决方案一四．解决方案二－－Transfer 五．应用场景和业务限制六．保障和退化七．在多主同步的应用八．不能解决的光速问题九．不能解决的更新延迟

31. 不能解决的更新延迟这回我们关注6本身, 要求完全没有延迟怎么作？一个耗时10ms的更新，至少延迟10ms 1 全同步？－－no 2 不要陷入锤子钉子的误区 3 5 4 放弃这方案，用双写 6

32. 谢谢