又到了周五的胡扯时间，今天来扯一扯坑。
最近，有一个感觉，就是一直在填坑，我想不止我一个人，不少奋战在一线的“勇士”，都在填坑。一般来说坑分两种，自己挖的，和别人挖的。挖坑也是有水平的，有的坑你根本就无从下手，除非你有“多年的道行”，否则你可能做的不是填坑，而是把坑弄的更大。
除了有多年“挖坑”，“踩坑”，“填坑”，的道行，你大约还的总结出来一套，如何来补坑的办法。
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 信息重要出现了，到此问题解决完毕。
其实整个流程走下来，并没有什么太难的问题，其实和我们日常中遇到的问题一样，问题都不难，但解决起来的手法问题和步骤就成了能否快速解决问题的所在。
好的今天就扯到这里。
