视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
检查MySQL数据库的主从延时
2020-11-09 08:18:26 责编:小采
文档


欢迎进入Linux社区论坛,与200万技术人员互动交流 >>进入 日常工作中,对于MySQL主从复制检查,一方面我们要保证复制的整体结构是否正常,另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内

欢迎进入Linux社区论坛,与200万技术人员互动交流 >>进入

  日常工作中,对于MySQL主从复制检查,一方面我们要保证复制的整体结构是否正常,另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内,对于后者则可以通过分别校验主从表中数据的md5码是否一致,来保证数据一致,可以使用Maatkit工具包中的mk-table- checksum工具去检查。

  方法1:

  通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断,是否有发生主从延时。其值有这么几种:

  NULL - 表示io_thread或是sql_thread有任何一个发生故障,也就是该线程的Running状态是No,而非Yes.

  0 - 该值为零,是我们极为渴望看到的情况,表示主从复制良好,可以认为lag不存在。

  正值 - 表示主从已经出现延时,数字越大表示从库落后主库越多。

  负值 - 几乎很少见,我只是听一些资深的DBA说见过,其实,这是一个BUG值,该参数是不支持负值的,也就是不应该出现。

  show slave status\G,该命令的输出结果非常丰厚,给我们的监控提供了很多有意义的参数,比如:Slave_IO_Running该参数可作为 io_thread的监控项,Yes表示io_thread的和主库连接正常并能实施复制工作,No则说明与主库通讯异常,多数情况是由主从间网络引起的问题;Slave_SQL_Running该参数代表sql_thread是否正常,具体就是语句是否执行通过,常会遇到主键重复或是某个表不存在。下面就说到今天的重点Seconds_Behind_Master,该值作为判断主从延时的指标,那么它又是怎么得到这个值的呢,同时,它为什么又受到很多人的质疑?

  Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和 io_thread复制好的event的timestamp(简写为ts)进行比较,而得到的这么一个差值。我们都知道的relay-log和主库的 bin-log里面的内容完全一样,在记录sql语句的同时会被记录上当时的ts,所以比较参考的值来自于binlog,其实主从没有必要与NTP进行同步,也就是说无需保证主从时钟的一致。

  你也会发现,其实比较真正是发生在io_thread与sql_thread之间,而io_thread才真正与主库有关联,于是,问题就出来了,当主库I/O负载很大或是网络阻塞,io_thread不能及时复制binlog(没有中断,也在复制),而 sql_thread一直都能跟上io_thread的脚本,这时Seconds_Behind_Master的值是0,也就是我们认为的无延时,但是,实际上不是,你懂得。这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因,但是这个值并不是总是不准,如果当io_thread与 master网络很好的情况下,那么该值也是很有价值的。

  之前,提到Seconds_Behind_Master这个参数会有负值出现,我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值,前者始终是大于后者的,唯一的肯能就是某个event的ts发生了错误,比之前的小了,那么当这种情况发生时,负值出现就成为可能。

  方法2:

  mk-heartbeat,Maatkit万能工具包中的一个工具,被认为可以准确判断复制延时的方法。

  mk-heartbeat的实现也是借助timestmp的比较实现的,它首先需要保证主从服务器必须要保持一致,通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表,里面至少有id与ts两个字段,id为server_id,ts就是当前的时间戳 now(),该结构也会被复制到从库上。

  表建好以后,会在主库上以后台进程的模式去执行一行更新操作的命令,定期去向表中的插入数据,这个周期默认为1 秒,同时从库也会在后台执行一个监控命令,与主库保持一致的周期去比较,复制过来记录的ts值与主库上的同一条ts值,差值为0表示无延时,差值越大表示延时的秒数越多。

  我们都知道复制是异步的ts不肯完全一致,所以该工具允许半秒的差距,在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复制,巧妙的借用timestamp来检查延时,非常好用!

  关于检查MySQL数据库的主从延时的两种方法就介绍到这里了,希望本次的介绍能够对您有所收获!

下载本文
显示全文
专题