快速定位解决myslq主从延迟问题

Mysql主从延迟

 

主从延迟的主要有两个方面：

1. 主数据库的写操作过快而从数据库的单线程操作跟不上导致
2. 从数据读取查询导致锁表，而不能执行同步主数据库的操作。

 

一：如果是主库原因

查看主从延迟的方法：

 

NULL，表示io_thread或是sql_thread有任何一个发生故障；
0，该值为零，表示主从复制良好；
正值，表示主从已经出现延时，数字越大表示从库延迟越严重

 

 

一般情况下都是主库原因

1. ）是主库执行DDL和DML语句过快而从库只是单线程处理导致数据延迟。

（mysql的主从是单线程的  mysql主可以同时执行DDL和DLM语句因为他可以并发线程，但是从slave只能单线程执行 如果DDL语句过长，他必须执行完这个操作才能执行下一个操作。）

主库执行DDL.DML语句是按照顺序执行的，而slave执行语句是随机的所以成本高很多。

1. 从库在执行操作时候可能造成lock的争夺，锁表。

 

解决办法：

1. 半同步复制
从MySQL5.5开始，MySQL已经支持半同步复制了，半同步复制介于异步复制和同步复制之间，主库在执行完事务后不立刻返回结果给客户端，需要等待至少一个从库接收到并写到relay log中才返回结果给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一个TCP/IP往返耗时的延迟。
2. 主库配置sync_binlog=1，innodb_flush_log_at_trx_commit=1
sync_binlog的默认值是0，MySQL不会将binlog同步到磁盘，其值表示每写多少binlog同步一次磁盘。
innodb_flush_log_at_trx_commit为1表示每一次事务提交或事务外的指令都需要把日志flush到磁盘。

最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。

innodb_flush_log_at_trx_commit = 0 ：每秒将日志缓冲区写入log file，并同时flush到磁盘。跟事务提交无关。在机器crash并重启后，会丢失一秒的事务日志数据（并不一定是1s，也许会有延迟，跟操作系统调度有关）。
innodb_flush_log_at_trx_commit = 1：每次事务提交将日志缓冲区写入log file，并同时flush到磁盘。（crash不会丢失事务日志）
innodb_flush_log_at_trx_commit = 2：每次事务提交将日志缓冲区写入log file，每秒flush一次到磁盘。（crash有可能丢失数据）

附加：
sync_binlog 配置说明：
sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“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只会在整个操作系统 挂了时才可能丢数据。


解决从库复制延迟的问题：
1. 优化网络
2. 升级Slave硬件配置
3. Slave调整参数，关闭binlog，修改innodb_flush_log_at_trx_commit参数值
4. 升级MySQL版本到5.7，使用并行复制

1)、架构方面
1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4.不同业务的mysql物理上放在不同机器，分散压力。
5.使用比主库更好的硬件设备作为slave总结，mysql压力小，延迟自然会变小。
2)、硬件方面
1.采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。
2.存储用ssd或者盘阵或者san，提升随机写的性能。
3.主从间保证处在同一个交换机下面，并且是万兆环境。
总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。
3)、mysql主从同步加速
1、sync_binlog在slave端设置为0
2、–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。
3、直接禁用slave端的binlog
4、slave端，如果使用的存储引擎是innodb，innodb_flush_log_at_trx_commit =2
4)、从文件系统本身属性角度优化

 

从库的原因： 

 

从库执行过长的查询语句 而导致锁表，在主库执行的操作恰巧也是从库那个被锁的表，导致了数据只能等待查询结束后才能继续对表进行操作。导致数据库延迟。

 

一般情况是查看慢查询日志找到 需要优化的语句发给后端处理。

Ps：如果是云数据库 可以通过监控