共计 2047 个字符，预计需要花费 6 分钟才能阅读完成。
本篇内容主要讲解“MySQL 主从同步加速的方案”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“MySQL 主从同步加速的方案”吧!
一、问题起源
MySQL 的主从同步一直有从库延迟的问题，背景资料网上很多，原因简单描述如下：
1、MySQL 从库上有一个 IO 线程负责从主库取 binlog 到写到本地。另外有一个 SQL 线程负责执行这些本地日志，实现命令重放；
2、正常网络状况下 IO 线程没有性能问题（这个待会会用到），问题是 SQL 线程只有一个，更新速度跟不上。所以经常会看到从库的 CPU idle 很高，但同步性能就是上不去。
二、方案雏形
单线程的 SQL 线程是造成这个问题的主要原因。比较直接的想法是把它改成多线程版本，这个据说官方版本开发中，其实我们也有一个这样的 patch，但是直接写大片代码在线上提供服务的 slave 机器上这种事儿，都会因为担心稳定性而很难推动（写 patch 的和运维的同学，你们懂的）。
所以打算用一个“第三方”工具中转，来实现多线程同步。基本结构如下：
说明：
1、这些 transefer 从 master 上各自同步一部分的数据，分别独立更新 slave。多进程还是多线程均可。
2、Transfer 与 master 之间异步更新日志，transfer 与 slve 之间同步更新数据
3、从这可以看出这个方案的缺点之一：更新能够被独立分开。比较直观的想法是，按照表分。
三、关于 transfer
作为这个关键的转发工具 transfer，需要提供如下功能：
1、能够指定同步 master 中的哪部分数据，并且能够方便地修改这个配置以应对 master 的加表需求；
2、支持 stop slave、start slave。支持快速切换到新主库的 change master 命令。
3、能够记录读取点，transfer 自己重启或 master 重启后能够按照记录点继续读后面的 binlog；
4、能够记录分发点，transfer 自己重启或 slave 重启后能够按照记录点继续同步给 slave
用起来就会发现还有好多要求。。。
四、方案实现
Transfer 的这么多功能，自己造轮子就累了。这里直接用 MySQL 来充当此角色。为了方便描述，下文还将之称为 transfer。Transfer 更新 slave 在功能上可以使用 federated 引擎，但由于其纠结的实现导致性能上达不到要求，因此在 MySQL 框架层中作了一点修改――读到同步日志后，直接发送给 slave。
方案简单描述如下：
1、Slave 机器上搭另外的若干个 MySQL(transfer)，将其设为 Master 的从库，且设置 replicate-do-table, 每个 transfer 承担一部分的表。
2、所有 Transfer 的更新目标都设置为 slave，其更新方式是读到日志后直接_real_query 执行到 slave 上。
从这可以看出这个方案的缺点之二：只能支持 statement 格式的同步方式。其实 row 也能支持，后面再说。
五、仍然延迟？
在 transfer 放弃 federated 引擎改用直接发送后，性能提升不少，从库同步性能增加一倍，但从本文第一个图的数据对比就知道，延迟还很大。
发现这个时候 slave 的机器 cpu 已经很忙了，idle 20% 一下――这个算是好消息，总比 idle 很高但性能上不去好。
实际上是因为每个 transfer，虽然设置只同步其中的部分表，但在实现上是 IO 线程把 master 上的所有命令都备份到本地，然后在 SQL 线程执行的时候再判断，若不符合 replicate-do-table，再放弃。
这样存在的问题，是 n 个 transfer，磁盘写了 n 倍，更严重的是导致 SQL 线程空转。
我们上文提到整个流程中 IO 线程是比较空闲的，因此修改 IO 线程逻辑，在写入磁盘前先判断，若不符合本 transfer 的 replicate-do-table 设置，不写盘，直接放弃。
六、效果
从库的 QPS 由于线程切换会有抖动，但总的执行时间与主库相同。从库的 cpu idle 下降，与主库几乎同时恢复到 100。
七、小结
描述完了，总结一下，方案的代价：
1、要求在 slave 机器上多配置 n 个 transfer（是否在从库上均可）
2、目前只能支持 statement 的 binlog 格式，实际上 row 可以支持，方案定了，开发计划中。
3、跨表更新的语句，会按照其更新的第一个表，分发到唯一一个 transfer，没有重复更新的问题，但有时序性问题。
方案的好处：
1、功能比较齐全。直接使用 MySQL，原有的管理功能基本都能用，主库从库重启 / 换库的代价比较小。
2、开发量小，只在 transfer 上修改两处，不包括配置读取部分，300 行以内
3、风险相对小。不直接修改 master 和 slve 上的代码，线上比较容易接收。
到此，相信大家对“MySQL 主从同步加速的方案”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
