主从延迟

主从复制原理
主从延迟原因
主从延迟解决办法
参考资料
主从复制原理
mysql主库对所有DDL和 DML产生binlog（binlog顺序写），从库的Slave_IO_Running线程到主库取日志，Slave_SQL_Running执行DDL和DML。



主从延迟原因
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了。具体来说，一个DDL卡主了，需要 执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有一个直觉上的疑问是：一个DDL需要执行10分钟，主库从库执行DDL需要相同的时间，为什么从库会延时呢？答案是master可以并发，Slave_SQL_Running线程却不可以。主从复制都是单线程的操作。

主从延迟解决办法
1、 多线程。

具体有两个阶段：

第一阶段：MySQL 5.6版本引入并发复制（schema级别），基于schema级别的并发复制核心思想：“不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致”。可见MySQL5.6版本的并发复制，一个schema分配一个类似SQL线程的功能。
第二阶段：实际生产中往往大多数或者全部的业务数据表都放在同一个schema下，在这种场景即使slave_parallel_workers>0设置也无法并发执行relay log中记录的主库提交数据。 高并发的情况下，由于slave无法并发执行同个schema下的业务数据表，依然会造成主备延迟的情况。MySQL 5.7 引入Enhanced Muti-threaded slaves,当slave配置slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’,可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。要实现以上功能，需要在master机器标记binary log中的提交的事务哪些是可以并发执行。
2、降低从库安全性，加快速度。

将从库的sync_binlog设置为0
将从库的innodb_flush_log_at_trx_commit设置为2
sync_binlog 配置说明：

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。

从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

innodb_flush_log_at_trx_commit 配置说明：

默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。


参考资料
https://yq.aliyun.com/articles/88925

http://www.cnblogs.com/cnmenglang/p/6393769.html

http://www.cnblogs.com/breg/p/3631921.html