mysql主从延时

二,主从延时问题的原因分析及处理

2.1什么是主从延时？

主库发生了操作，从库很久才跟上来（超过10s）

2.2 主从延时怎么监控

得出：有或者没有延时的情况。等于0不代表没有延时。

评估主从延时更加精确的指标是，延时了多少日志量。

主库执行的日志量，从库执行的日志对比.

 show slave status\G 

粗略评估：

Seconds_Behind_Master: 0 #从库落后于主库的时间

准确评估：

日志量：主库的binlog位置点对比从relay执行的位置点。

2.3 如何计算延时的日志量

主库的位置点：show master status;

mysql-bin.000005 |      194 

从库的relay-log日志点: relay-log.info 

[root@later02/data/3306]# cat relay-log.info 

mysql-bin.000005

194

这里可以发现是对上了的。

2.4主从复制延时原因？

主库：

     外部： 网络，硬件配置，主库业务繁忙,从库太多

     主库业务繁忙：

        1.拆分业务：组件分离，垂直，水平（分表）。

         2.大事务的拆分，比如 1000w业务 拆分为20次执行。

     内部：

        1.二进制日志更新

            sync_binlog=1

      2.  5.7之前的版本，没有开GTID之前，主库可以并发事务，

       但是dump传输是串行。所以会导致，事务量，大事务时会出现比较严重的

          延时。

         解决方案：

          5.6+版本，手工开启gtid，事务在主从的全局范围内，就有了 

           唯一性标识。

           5.7+ 版本，无需手动开启，系统会自动生产GTID信息

           有了GTID之后，就可以实现并发传输binlog.

            但是，即使有这么多的优秀特性，我们依然需要尽可能减少大事务，

            以及锁的征用问题. 

怎么判断是主库传输不及时？

1.Seconds_Behind_Master  

2.主：show master status;

mysql> show master status\G

           File: mysql-bin.000005

           Position: 194

   从：[root@later02/data/3306]# cat master.info 

           mysql-bin.000005

           194

从库：

    外部：网络，从库配置低，参数设定

             解决：保持网络通畅，配置加强

    内部：

         IO线程：

             1.写relay-log --->IO性能（使用ssd）

         SQL线程：回放SQL

         1. 在非GTID模式下串行操作： 单线程回放。

            解决：开启GTID，串行改并行

                       5.6+ GTID： database级别l:基于库级别的线程并发

                        5.7+ GTID：logic_clock:逻辑时钟。保证了在同库级别下

                         的事务顺序，所以可以理解为基于事务级别的回放。

            但是，即使有这么多的优秀特性，我们依然需要尽可能减少大事务，

            以及锁的征用问题. 

优化数据库的根本就是优化人。

                   ----old guo