关于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、监控事务编号 1 #!/bin/bash
2
3 #######################################################
4 # $Version: v1.0
5 # $Description：判断GTID复制中从库有没有与主库同步 show slave stautus\G中：
6 # 当 Retrieved_Gtid_Set = Executed_Gtid_Set 表示从库已经和主库完成同步
7 #
8 # Retrieved_Gtid_Set：从库已经接收到主库的事务编号
9 # Executed_Gtid_Set： 已经执行的事务编号
10
11
12 #######################################################
13
14 mysql -u 从库账号 -p'从库账号密码' -e "show slave status\G;" > slave_status
15
16 # 1、找到Auto_Position的行号
17 AutoPosNum=`grep -n "Auto_Position" slave_status |awk '{print $1}' |tr -d ":"`
18
19 # 2、Auto_Position的上一行即是 Executed_Gtid_Set 那行
20 Exec_numLine=$(($AutoPosNum-1))
21
22 # 3、比对值是否相等：Retrieved_Gtid_Set ，Executed_Gtid_Set
23 Exec_num=`sed -n "$Exec_numLine"p slave_status |awk -F":" '{print $2}'|awk -F "-" '{ print $2}'`
24
25 Ret_num=`grep 'Retrieved_Gtid_Set' slave_status | awk -F":" '{print $3}'|awk -F "-" '{print $2}'`
26
27 #判断这俩个数值是否相同，相等输出yes，否则报警
28 if [ $Exec_num -eq $Ret_num ]
29 then
30 echo "yes"
31 else
32 ## 10秒后再运行一次上面那堆命令，比较$Exec_num 和$Ret_num，因为可能会有某些瞬间是不相等的
33 sleep 10
34 。。。
35 如果还是不等就报警
36 fi
37
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同步情况
1 #!/bin/bash
2
3 ######################################
4 # 监控当前主从同步的情况
5 ######################################
6
7 ### 1、从库：
8 SLAVE_BINLOG1=`mysql -u '从库账号' -p'从库账号密码' -h '从库连接ip' -e "show slave status\G;" | awk '$1=="Master_Log_File:" {print $2}'`
9
10 SLAVE_BINLOG2=`mysql -u '从库账号' -p'从库账号密码' -e "show slave status\G;" | awk '$1=="Relay_Master_Log_File:" {print $2}'
11
12
13 ### 2、主库：
14 ## 获得Master端，当前的binlog文件以及binlog路径
15 MASTER_BINLOG=`mysql -u '主库账号' -p'主库账号密码' -h '主库连接ip' -e "show master status;"
16 | grep -v '^+' | tail -1 | awk '{print $1}'`
17
18 ### 3、同步情况
19 ##### 3.1 主从端已经同步到相同的binlog
20 if [[ "${SLAVE_BINLOG1}" = "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]];then
21 CURR_BINLOG="${MASTER_BINLOG}"
22 echo "主从端已经同步到相同的binlog。。。"
23
24 ##### 3.2 主从端已经同步，但从端的binlog还没有追赶到主端最新的binlog
25 elif [[ "${SLAVE_BINLOG1}" != "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]]; then
26 CURR_BINLOG="${SLAVE_BINLOG2}"
27 echo "主从端已经同步，但从端的binlog还没有追赶到主端最新的 binlog。。。"
28
29 ##### 3.3 主从端已经同步，主从端的binlog一致，但relaylog还不一致
30 elif [[ "${SLAVE_BINLOG1}" != "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]]; then
31 CURR_BINLOG="${SLAVE_BINLOG2}"
32 echo "主从端已经同步，主从端的binlog一致，但 relaylog 还不一致"
33 else
34 echo "未知错误 Has noknown error at：`date +%F" "%H-%M-%S`，需要人工检查"
35 发钉钉告警。。。
36 exit 1
37 fi
标签：主库,binlog,同步,SLAVE,监控,从库,主从,GTID From： https://www.cnblogs.com/windysai/p/17228441.html