又到了周五的胡扯时间,今天来扯一扯坑。
最近,有一个感觉,就是一直在填坑,我想不止我一个人,不少奋战在一线的“勇士”,都在填坑。一般来说坑分两种,自己挖的,和别人挖的。挖坑也是有水平的,有的坑你根本就无从下手,除非你有“多年的道行”,否则你可能做的不是填坑,而是把坑弄的更大。
除了有多年“挖坑”,“踩坑”,“填坑”,的道行,你大约还的总结出来一套,如何来补坑的办法。
1 望, 遇到一个坑,首先你需要判断的是他到底是不是一个坑,首先要望,你先不要有任何的动作,先要观察,因为不了解具体情况和成因的情况下,你做的任何事情,都肯能变得更糟。
2 闻问,在看完之后,你还的要问,你观察的在细致入微,也哪怕有遗漏,所以如何问,并且闻,问出你关心的,听出弦外之音,找到坑的中心点。
3 切,一般到这个步骤就开始要出事了,要不你填坑,要不你背锅。一般来说我是要找一个和生产无关的环境,来排除故障,这当然是最好的,很多时候可气的是,没有环境要硬来,所以这时候你是 “大化小”, 还是“连根拔”。就要看你的运气了,一般来说我的习惯是 “大化小”。
废话了这么多,下面来举个例子,最近在做多源复制的事情,而作为源头的MYSQL 数据库,是五花八门,(前些日子有一篇文章已经说了一部分了),这次的故障更是奇怪,命名已经添加了 GTID的参数,数据库也没有任何报错,但在多源复制备份数据库的过程中,发现这个库和别的不同,虽然GTID 已经打开了,但备份后,根本没有GTID的信息。最终导致这个库的多源复制中,操作失败。
本着找到问题根源的精神,我询问了一下,这个库应该是很早的一个库,能和这个库在这个公司的运维人员并且参与这个库的建立的,估计是找不到了。并且这个库已经运行了一段时间了,除了有过一些“小病小灾”,也没有出过其他问题。所以上面说的 “闻问“,已经是无计可施了,查看数据库的错误日志里面也没有可以一眼辨明是非的信息, 那就的突破点,首先既然是添加了GTID的参数,那至少在BINLOG 里面是可以看到GTID的信息的,至少我的验证一下,所以先需要 mysqlbinlog 一下,到底BINLOG 中到底有什么问题?
敲了这个命令后,系统报出 unknow variable 'default-character-set=utf8'
在进入到系统内部看看当前的字符集是非是设置成 UTF8 ,果然不是,这个参数是错误的。
在MY.CNF 中注销掉这个参数,重启动服务器
再次运行MYSQLBINLOG 解开BINLOG 后发现有错误,看了刚踩完一个坑,又来一个坑,经过查询后,提示是MYSQLBINLOG 的版本不对
通过查询系统中存在三个MYSQLBINLOG ,经过逐一的测试,发现/mysql/bin/mysqlbinlog 这个才是真正可以使用的MYSQLBINLOG ,而默认键入的 mysqlbinlog 默认指向的位置是错误的。
同理看来备份的MYSQLDUMP的版本也估计有问题,直接找到和正常MYSQLBINLOG 目录一致的位置的MYSQLDUMP 进行备份
久违的GTID 信息重要出现了,到此问题解决完毕。
其实整个流程走下来,并没有什么太难的问题,其实和我们日常中遇到的问题一样,问题都不难,但解决起来的手法问题和步骤就成了能否快速解决问题的所在。
好的今天就扯到这里。
本文分享自 AustinDatabases 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!