挖坑，踩坑，填坑

2019 年 10 月 11 日
筆記

又到了周五的胡扯時間，今天來扯一扯坑。

最近，有一個感覺，就是一直在填坑，我想不止我一個人，不少奮戰在一線的「勇士」，都在填坑。一般來說坑分兩種，自己挖的，和別人挖的。挖坑也是有水平的，有的坑你根本就無從下手，除非你有「多年的道行」，否則你可能做的不是填坑，而是把坑弄的更大。

除了有多年「挖坑」，「踩坑」，「填坑」，的道行，你大約還的總結出來一套，如何來補坑的辦法。

1 望，遇到一個坑，首先你需要判斷的是他到底是不是一個坑，首先要望，你先不要有任何的動作，先要觀察，因為不了解具體情況和成因的情況下，你做的任何事情，都肯能變得更糟。

2 聞問，在看完之後，你還的要問，你觀察的在細緻入微，也哪怕有遺漏，所以如何問，並且聞，問出你關心的，聽出弦外之音，找到坑的中心點。

3 切，一般到這個步驟就開始要出事了，要不你填坑，要不你背鍋。一般來說我是要找一個和生產無關的環境，來排除故障，這當然是最好的，很多時候可氣的是，沒有環境要硬來，所以這時候你是「大化小」，還是「連根拔」。就要看你的運氣了，一般來說我的習慣是「大化小」。

廢話了這麼多，下面來舉個例子，最近在做多源複製的事情，而作為源頭的MYSQL 數據庫，是五花八門，（前些日子有一篇文章已經說了一部分了），這次的故障更是奇怪，命名已經添加了 GTID的參數，數據庫也沒有任何報錯，但在多源複製備份數據庫的過程中，發現這個庫和別的不同，雖然GTID 已經打開了，但備份後，根本沒有GTID的信息。最終導致這個庫的多源複製中，操作失敗。

本着找到問題根源的精神，我詢問了一下，這個庫應該是很早的一個庫，能和這個庫在這個公司的運維人員並且參與這個庫的建立的，估計是找不到了。並且這個庫已經運行了一段時間了，除了有過一些「小病小災」，也沒有出過其他問題。所以上面說的「聞問「，已經是無計可施了，查看數據庫的錯誤日誌裏面也沒有可以一眼辨明是非的信息，那就的突破點，首先既然是添加了GTID的參數，那至少在BINLOG 裏面是可以看到GTID的信息的，至少我的驗證一下，所以先需要 mysqlbinlog 一下，到底BINLOG 中到底有什麼問題？