当遇到从库延迟时，要怎么做？

首先输入 show slave status \G;看一下。

 

在生产环境中，主从复制常常会有复制延迟的现象，主要是master是并发的写，而slave是单线程的应用relay log，所以会出现复制延时，在MySQL 5.6版本中有了基于库的多线程复制。还有MariaDB的并行复制。但是我们使用MySQL 5.5的版本也比较多。如何判断复制是否延时呢？工具现在可以使用的有pt-heartbeat，但是如果我们自己明白怎么样判断复制是否延时的话，自己写简单的shell脚本或者python脚本也可以完成。

 

复制是否延时的判断标准如下：

              Master_Log_File: restoredb-bin.000013

          Read_Master_Log_Pos: 2421074

               Relay_Log_File: restoredb2-relay-bin.000010

                Relay_Log_Pos: 2419771

        Relay_Master_Log_File: restoredb-bin.000013

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

              Replicate_Do_DB: 

          Replicate_Ignore_DB: 

           Replicate_Do_Table: 

       Replicate_Ignore_Table: 

      Replicate_Wild_Do_Table: 

  Replicate_Wild_Ignore_Table: 

                   Last_Errno: 0

                   Last_Error: 

                 Skip_Counter: 0

          Exec_Master_Log_Pos: 2421074

              Relay_Log_Space: 2420428

不要通过Seconds_Behind_Master去判断，该值表示slave上SQL线程和IO线程之间的延迟

判断方法如下：

1、首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差异

2、如果Relay_Master_Log_File 和 Master_Log_File 有差异的话，那说明延迟很大

3、如果Relay_Master_Log_File 和 Master_Log_File 没有差异，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异，那么更加严谨的做法是同时在主库执行show master status和在从库上面执行show slave status 的输出进行比较。MHA就是这样保证数据一致性的。MMM都没有做到。这也算MHA比MMM更加优秀的地方。