前幾天專門花了時間開始做中繼資料的稽核，其實這隻是一個初步的開始，也算是才開始走上正道。
運維平台中繼資料稽核小結
後續我又推出了幾個方面的改進，準備在中繼資料的粒度和深度上逐漸改善，把已有的中繼資料完善起來，能夠發現很多潛在的問題，然後再逐漸的改進，對于團隊内的同學來說，他們不需要花費很多的精力去收集資訊，這個事情讓任務去做，他們需要做的是确認和問題修正。
比如通用元資訊部分，對于MySQL執行個體來說，基本就是IP,端口，機房，資料庫角色（Master,Slave等），資料版本，應用資訊等，系統層的中繼資料，比如硬碟，記憶體，CPU應該是由專有的子產品來維護。
确切的說，上面的這些資訊隻是通用，很難滿足業務的實際需求，比如一個MySQL服務端配置，是否開啟GTID，版本，角色，socket檔案路徑，資料檔案路徑，buffer_pool大小，是否開啟binlog，server_id，VIP等這些資訊其實是我們需要明确了解的。
有了這些資訊，其實能夠讓我們對于執行個體的屬性有一個基本的了解。
整個資訊的收集看起來是一個很苦逼的過程，實際上我們可以讓它變得高大上一些，比如我們把資訊收集後使用前端頁面做彙總和資訊稽核，比如讓資料的收集實作自動化，批量完成，而不需要手工來觸發完成。
這些工作我們可以寫腳本來完成，資訊可以收集到，但是資訊的管理和統籌和單純的資訊收集就不是一個層級了。我們在這個地方需要做的是中繼資料的管理和稽核，提前發現更多的問題，來逐漸的完善，這樣一來中繼資料最起碼是可以參考和依賴的。
到了這個層級之後，其實我們能夠得到一個基本的執行個體屬性清單，但是顯然還是還是存在短闆，我們的MySQL執行個體基本上是主從複制的關系，有些執行個體可能是測試環境，或者是資料流轉的節點，是以可能沒有從庫也沒有備份。是以對于MySQL資訊的歸類我會這樣來分類和處理：
1.第一個次元是單點執行個體，單點執行個體是那些測試環境，資料流轉節點或者業務優先級不高的業務。這些業務允許資料丢失，甚至允許環境重建，有一個基本的備份即可，這類的業務我們首先剝離出來，後面處理的時候就可以可以繞過這些節點，比如對于這些節點來說，可能不需要備份，可能不需要每天備份，壓根不需要增量備份，binlog備份，按照這個規劃，做了這些資訊确認之後，後期要完成的備份恢複就有據可依，要不費了半天勁，最後發現業務優先級不高，做事情的成本效益就大打折扣。
2.第二個次元是資料庫角色，資料庫的角色其實不能嚴格意義上歸類為Master,Slave，其實可以有更多的類型，比如單點業務，我們可以歸類為SingleDB,如果是中繼節點（show master status或者show slave status持有雙重角色），我們可以歸類為RelayDB,如果是主庫或者是從庫即為Master,Slave,如果屬于MHA或者MGR的叢集環境等，其實這個角色可以更加清晰，對于這部分資訊我們需要做減法，即MHA或者MGR的環境，這類資訊可以歸類為叢集資訊，我們可以對其他的資訊按照SingleDB,RelayDB,Master,Slave這四個次元來統計即可。
要實作這個功能，就有一些技巧需要補充了。
我們在這裡需要兩個腳本：
1）通過IP和端口資訊得知執行個體的角色（Master,Slave,RelayDB,SingleDB等）
2）通過Slave和RelayDB的資訊來得到Master的資訊，亮點也就在此，通過這些資訊我們可以清晰的達到一個複制關系圖，甚至可以看到一些意想不到的問題。
比如下面的IP資訊，資料庫角色是中繼節點RelayDB（既是Master又是Slave）
我們根據IP的後兩段内容搜尋得到下面的一個基本清單。
這樣一個關系，如果自己來刻意維護，其實很容易就會迷茫，或者意識不到這種級聯關系的存在，但是我們對這些資料進行抽象，就很快能夠得到這樣的餓一個關系圖，原來是這樣的一個級聯關系。這樣一來124.16這個中繼節點的角色和上下遊的關系就很清晰了，那麼從這個角度來看，我們是否需要對124.76做資料的備份就很容易得出結論了。