关于GTID的同步监控

关于GTID的同步监控

一、需求引入

　　周一临下班的时候，领导给了个任务我，源于周一的时候，生产数据库cpu居高不下，应用系统各种卡，客户投诉，最后搞到他要写故障报告 = =（想想大家都不容易）。

　　原因是报表分析、工单系统、监控大屏需要从生产库查数据进行分析，这些 sql 查询复杂，加上开发人员也不做优化，导致拖死了应用的正常使用。

　　再讲回需求：按1比1的关系，同步生产数据库到从库，把这些报表分析、工单系统剥离开来，查的话从从库里查，不要影响正常生产库使用。就我们公司的“优良传统”，成本是首要，所以领导首先是叫我把这个从库部署到线下，也就是我们公司局域网的虚拟机上。

　　可以百度下部署过程，我之前也简单写过【https://www.cnblogs.com/windysai/p/17068082.html】，虽然没啥深度可言。。。

 

二、测试过程

　　线上生产数据库是阿里云RDS，版本 mysql 5.7.37，我公司内网有个自建版的 5.7.20 的mysql，部署同步的时候直接用RDS的公网地址了，效果很差（有十来个表对不上数据，即使我选择中午人少的时候全量同步，重新做同步），然后快下班的时候汇报测试情况给我们领导，领导建议我mysql小版本号可能也会有影响，叫我换成一样的试试。

　　当天晚上（也就是周一晚上），凭直觉我觉得，直接部署在阿里云局域网（跟生产RDS能内网互通）测试效果会好很多，于是晚上11点多，等人少时部署上去了。为了好交代，第二天也就是周二通过，小版本号升级mysql的方式，重新做公司局域网的GTID同步，效果也是差；至于前一晚部署在阿里局域网上的从库，就好很多。分别相差十几个表和2个表。公司局域网内的从库，相对主库而言，这十几个表的数据量有多也有少的情况；而线上局域网的从库表数据量只有少的情况，就截止到现在而言，有一个表少17或18条，另一个表相差20条。

　　对比用的是这个脚本，首先查出主库（生产库）中所有表，然后比对从库中的表数量

select concat(
'select "',
TABLE_name,
'", count(*) from ',
TABLE_SCHEMA,
'.',
TABLE_name,
' union all'
) from information_schema.tables
where TABLE_SCHEMA='生产库名字';

　　查出来的结果去掉最后的“union all”，然后分别在主库和从库运行，就能得出所有表数据量，再用diff去比较两者差异。

 

三、监控脚本

　　今天主要做的是监控主从脚本，比较拙劣，包括：

（1）比较从库接收到主库的事务编号，跟从库执行的事务编号是否相等

（2）从库主从复制的线程是否正常

（3）主从同步情况：

　　（3.1）主从完全同步

　　（3.2）主从已同步，但是从端binlog还没追上主端的binlog

　　（3.3）主从已同步，主从端的binlog一致，但relaylog还不一致

　　（3.4）主从不同步，人工排查，监控提醒

　（因为明天一早约了医生，所以直接贴脚本。。。）

 

1、监控事务编号

#!/bin/bash

#######################################################
# $Version:     v1.0
# $Description：判断GTID复制中从库有没有与主库同步 show slave stautus\G中： 
#                当 Retrieved_Gtid_Set = Executed_Gtid_Set 表示从库已经和主库完成同步 
#
# Retrieved_Gtid_Set：从库已经接收到主库的事务编号
# Executed_Gtid_Set： 已经执行的事务编号


#######################################################

mysql -u 从库账号 -p'从库账号密码' -e "show slave status\G;" > slave_status

# 1、找到Auto_Position的行号
AutoPosNum=`grep -n "Auto_Position" slave_status |awk '{print $1}' |tr -d ":"`

# 2、Auto_Position的上一行即是 Executed_Gtid_Set 那行
Exec_numLine=$(($AutoPosNum-1))

# 3、比对值是否相等：Retrieved_Gtid_Set ，Executed_Gtid_Set
Exec_num=`sed -n "$Exec_numLine"p slave_status |awk -F":" '{print $2}'|awk -F "-" '{ print $2}'` 

Ret_num=`grep 'Retrieved_Gtid_Set' slave_status | awk -F":" '{print $3}'|awk -F "-" '{print $2}'`

#判断这俩个数值是否相同，相等输出yes，否则报警
if [ $Exec_num -eq $Ret_num ]
then
    echo "yes"
else
    ## 10秒后再运行一次上面那堆命令，比较$Exec_num 和$Ret_num，因为可能会有某些瞬间是不相等的
    sleep 10
    。。。
    如果还是不等就报警
fi
     

 

2、这个没什么好写的，核心命令就是

进去从库运行：
show slave status\G;

找到两个线程，比较是否都是 Yes
IO_env=`echo $STATUS | grep IO | awk '{print $2}'`
SQL_env=`echo $STATUS | grep SQL | awk '{print $2}'`

 

3、监控主从binlog同步情况

#!/bin/bash

######################################
# 监控当前主从同步的情况
######################################

### 1、从库： 
SLAVE_BINLOG1=`mysql -u '从库账号' -p'从库账号密码' -h '从库连接ip' -e "show slave status\G;" | awk '$1=="Master_Log_File:" {print $2}'`

SLAVE_BINLOG2=`mysql -u '从库账号' -p'从库账号密码' -e "show slave status\G;" | awk '$1=="Relay_Master_Log_File:" {print $2}'


### 2、主库：
## 获得Master端，当前的binlog文件以及binlog路径
MASTER_BINLOG=`mysql -u '主库账号' -p'主库账号密码' -h '主库连接ip'  -e "show master status;"
 | grep -v '^+' | tail -1 | awk '{print $1}'`

### 3、同步情况
##### 3.1 主从端已经同步到相同的binlog
if [[ "${SLAVE_BINLOG1}" = "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]];then
    CURR_BINLOG="${MASTER_BINLOG}"
    echo "主从端已经同步到相同的binlog。。。"

##### 3.2 主从端已经同步，但从端的binlog还没有追赶到主端最新的binlog
elif [[ "${SLAVE_BINLOG1}" != "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]]; then
    CURR_BINLOG="${SLAVE_BINLOG2}"
    echo "主从端已经同步，但从端的binlog还没有追赶到主端最新的 binlog。。。"

##### 3.3 主从端已经同步，主从端的binlog一致，但relaylog还不一致
elif [[ "${SLAVE_BINLOG1}" != "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]]; then
    CURR_BINLOG="${SLAVE_BINLOG2}"
    echo "主从端已经同步，主从端的binlog一致，但 relaylog 还不一致"
else
    echo "未知错误 Has noknown error at：`date +%F" "%H-%M-%S`，需要人工检查" 
    发钉钉告警。。。
    exit 1
fi