MySQL运维实战 之 价值一个亿的GTID监控-阿里云开发者社区

开发者社区> 兰春> 正文

MySQL运维实战 之 价值一个亿的GTID监控

简介: 一、背景 现在的MySQL可谓是拿着望远镜也找不到对手,其中有一个非常大的特性就是GTID GTID的原理这篇文章不再展开,有兴趣的同学可以关注之前的GTID原理,GTID实战,GTID运维实战文章。
+关注继续查看

一、背景

GTID的原理这篇文章不再展开,有兴趣的同学可以关注之前的GTID原理,GTID实战,GTID运维实战文章。

如果每个实例的GTID相同,那么可以大概率说明数据的一致性。

所以,我们要保证slave的GTID一定是master的子集,因为基于复制原理,slave一般是延后master的。

于是,我们就实现了一个监控,如果slave不是master的子集,那么告警出来,截图如下:

image

上图列出的GTID就是有问题的,不是master的子集。

一开始,这么做主要是处于自己的洁癖,以及对规范的强要求和依赖。
后来有好多小朋友跟我说,这个监控没有任何意义:

1) slave切换下,就不一致了
2) 即便不是子集,在slave进行了操作,比如:flush 等操作,只要不影响数据一致性,也没关系的

balabala好多类似的理由。
当时,我也没有太好的利用说服,只能自己负责的业务默默遵从。

后来再仔细想想GTID的原理,结合实战,对这个监控有了新的认识

二、故障复现和原理剖析

  • 先简单说说结论:

如果candidate master的非子集GTID对应的binlog日志被purge了,那么MHA切换的时候,会导致从库IO线程失败。

报错如下:

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 
                'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1,
                but the master has purged binary logs containing GTIDs that the slave requires.'

image

  • 故障复现的步骤:
  1. candidate master: flush slow logs; --产生一些非子集的gtid event
  2. candidate master: purge binary logs to xx --将刚刚产生的非子集gtid所在的binlog给删除掉
  3. master : 模拟切换
  4. 报错产生
  • 原理剖析:

image

a) 当备选master晋升为new master时,其他的实例会获取cm_uuid:1这个gtid
b)如果cm_uuid:1 已经被purge了,那么就会报错 。

  • 回到开头,为什么说这个监控价值一个亿呢?
  1. 如果slave没有业务,其实问题不大。
  2. 如果slave 有业务呢,现在很多架构是读写分离的,如果不能及时修复主从关系,那么延迟的数据造成的损失就不能简简单单的钱来衡量了。

三、解决方案

  1. 方案其实很简单: 巡检出问题,修复问题,最终一定要保证slave是master的子集。
  2. 如果修复gtid呢:如果确定slave上的gtid不影响数据的一致性,那么可以手动reset gtid来修复即可。

四、Q&A

Q1: 通过在slave 设置 read_only 可以避免吧。
A1: 因为flush 命令,是可以绕过read only并产生binlog的。

Q2:假如从库start slave失败,我也可以手动修复吧。
A2:
如果只是切换一次,我相信你可以,如果切换5次,10次呢。
如果只是今天早slave操作了,你姑且可以记住。如果是半年前的操作呢?你怎么确定这个日志是可以skip的?

Q3:从库的binlog怎么会被purge呢?
A3:这个一般互联网公司的binlog日志,在线不会保留太长时间,保留1个月已经算是谢天谢地了。 即便不是人为的purge,也会通过expire_logs来删掉的。

这个原理非常简单,但是 越简单的事情 却 不容易做到。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Java Spring Boot 2.0性能监控实战与Actuator机制解析
Java Spring Boot 2.0 性能监控 实战与 Actuator 机制解析: 内容摘要:应用程序性能监控和日志采集管理是非常重要问题,Java Spring Boot网站、API等应用程序如何进行远程性能监控、日志采集,远程控制,本次课程一起深入学习Actuator新特性与API机制。
3752 0
mysql各种引擎对比、实战
1)存储引擎概述; (2)MySQL各大存储引擎; (3)InnoDB和MyIsam使用及其原理对比; (4)InnoDB和MyIsam引擎原理; (5)剩余引擎的使用DEMO(主要是Mrg_Myisam分表); 文章目录:(例子下载在最下方) (1)存储引擎概述 为什么要合理选...
1390 0
函数计算自动化运维实战2 -- 事件触发eip自动转移
函数计算 阿里云函数计算是一个事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询,性能监控,报警等功能。
1782 0
【Linux】MySQL 运维常用脚本
【Linux】MySQL 运维常用脚本目录 操作规范1、数据操作,必须谨慎,线上尤甚!!!2、线上数据操作,必须备份!备份需完整、可用,备份使用自己最容易操作回滚的方式。3、数据操作,能修改数据解决的决不删除4、不确定的操作不做,不确定的命令不敲5、如果出现问题,例如数据丢失、数据文件损坏,必须首先完整备份当前环境,保证后续操作不会造成更大的影响,以便留给能解决问题的人解决。
8518 0
+关注
兰春
数据库技术爱好者,专注于MySQL领域的运维与运营,擅长性能调优,系统瓶颈分析,热爱数据领域的一切
74
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载