当前位置:Gxlcms > mysql > 一种MySQL主从同步加速方案_MySQL

一种MySQL主从同步加速方案_MySQL

时间:2021-07-01 10:21:17 帮助过:26人阅读

bitsCN.com

一、问题起源
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框架层中作了一点修改

人气教程排行