curHsTableLock=`grep 'Hs_table_lock' ${curFile} | awk '{print $2}'`
preHsTableLock=`grep 'Hs_table_lock' ${preFile} | awk '{print $2}'`
if [ -n "${curHsTableLock}" ]
then
hsQPS=`echo "scale=0;(${curHsTableLock} - ${preHsTableLock}) / ${intervalTime}" | bc`
else
hsQPS=0
fi
27、主从同步和状态
#主从信息
#是否为从服务器
slave_running=`grep 'Slave_running' ${curFile} | awk '{print $2}'`
if [ "${slave_running}A" = "ONA" ]
then
slaveRunning=1
slaveStatus=`${MYSQL} -e'show slave status\G'`
echo "${slaveStatus}" > ${slaveFile}
slaveIoRunning=`grep 'Slave_IO_Running' ${slaveFile} | awk -F ':' '{print $2}'`
slaveSqlRunning=`grep 'Slave_SQL_Running' ${slaveFile} | awk -F ':' '{print $2}'`
if [ "${slaveIoRunning}A" == "NoA" -o "${slaveSqlRunning}A" == "NoA" ]
then
slaveRunning=3
fi
secondsBehindMaster=`grep 'Seconds_Behind_Master' ${slaveFile} | awk -F ':' '{print $2}'`
if [ "${secondsBehindMaster}A" = "NULLA" ]
then
secondsBehindMaster=8888 # 表示主从不同步
fi
#是从库时 获取主库ip
master=`grep 'Master_Host' ${slaveFile} | awk -F ':' '{print $2}'`
masterPort=`grep 'Master_Port' ${slaveFile} | awk -F ':' '{print $2}'`
else
master=""
masterPort=""
slaveRunning=0
secondsBehindMaster=10000 # 不用检测
fi
注: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发生了错误,比之前的小了,那么当这种情况发生时,负值出现就成为可能。
28、检测采集Agent心跳情况