MYSQL主从同步延迟大的原因及解决建议
2014-08-10 20:34:23 
阿炯
在开始本文前，需要了解主从同步原理，具体可以参考这里。主从同步延迟原因
要说延时原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作。
主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率也比较高；但下一步问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用而产生更多的阻塞。
由于Slave_SQL_Running也是单线程的，所以一个DDL阻塞了，需要执行数十分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。master可以并发，Slave_SQL_Running线程却不可以，它只能等一个操作完成后才能继续。
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，另外还可能与slave的大型的查询语句产生了锁争用等待。
可行的改进方法
1、修改架构及应用
尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者直接关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的磁盘设备作为slave。
1)、sync_binlog=1|0
This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction.
默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。
如果使用InnoDB表，MySQL服务器处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时事务被InnoDB回滚，但仍然存在binlog中。
2)、innodb_flush_log_at_trx_commit
如果觉得Innodb比MyISAM慢n倍，那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。
设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。
设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统不可用时才可能丢数据。
2、使用Transfer方案
MySQL-Transefer（下称Transfer）是一个基于MySQL+patch后得到的主从同步工具。
其主要目的是为了解决原生版本的主从同步里，从库是单线程apply主库的binlog，导致的延迟。
1)、Transfer可以注册成多个Master的从库
2)、Transfer接收多个Master传入的binlog后将更新执行到Slave上
3)、Transfer本地没有数据
如果你没有多主的需求，那结构就是Master -> Transfer -> Slave。由于Transfer是在MySQL基础上打的patch，因此支持几乎所有MySQL的监控命令，你原来加在Slave上的监控，可以直接改到Transfer上。
3、使用mysql 5.6
mysql从5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，而新版是以不同的库可以使用不同的复制线程，一个库一个处理线程，这样其它库的操作就不会影响到本库的同步处理了。