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

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

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

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

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

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

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

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

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

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

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

MySQL主从同步解决方案

以上为前传，介绍MySQL多线程同步工具(Transfer)的设计思路 以下为文字解释版 相同的机器配置，出现性能差异的原因，是从库上单线程更新。 说明：直接修改slave代码，风险比较大

MySQL主从同步解决方案 一种方案是将从库的单线程apply改成多线程，但需要修改slave的代码。 安全起见，以工具的形式提供多线程同步功能。 Transfer也是一个MySQL，DBA一般部署在slave同一个机器上，放到/u01/mysql2 Transfer设置为Master的从库，接收日志后更新Slave 从Slave来看，Transfer是一个普通的Client。

MySQL主从同步基本概念和配置步骤 MySQL主从同步基本流程 延迟的原因 解决方案一 解决方案二 －－Transfer 应用场景和业务限制 保障和退化 在多主同步的应用 不能解决的光速问题 不能解决的更新延迟

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

Transfer的应用场景和业务限制 对Slave的限制 对DDL语句的处理 设置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 5 6 4

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

MySQL主从同步基本概念和配置步骤 MySQL主从同步基本流程 延迟的原因 解决方案一 解决方案二 －－Transfer 应用场景和业务限制 保障和退化 在多主同步的应用 不能解决的光速问题 不能解决的更新延迟

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

MySQL官方版5.6的多线程同步介绍 & 启发 按DB分线程 为什么我们当时没这么作？ 跨DB的则线程合并 Transfer与其实质区别是粒度不同 被按DB分提醒了 – 后续改进

课程回顾 、总结页 如何配置主从同步 主从同步原理 主从同步性能问题现状 优化方向 安全的妥协方案 Transfer的其他应用

谢谢