一種直觀記錄表結構變動歷史的方法

1. Story

在沒有造成本身的數據庫管理平臺之前，數據庫實例一多（包括生產和測試環境），許多表要執行DDL會變得異常繁雜。

說個本身的經歷，須要改現網的一個索引來看優化的效果，由於存在風險，不會一次全改，先只改1個庫，而後逐步放開。先後驗證效果可能花上一兩週的時間，除非實現完整的記錄了當時的ddl語句和對應的庫，不然根本難以記得。這就徹底依賴於我的的習慣及能力。

又好比現網出了個問題，開發追查到一個時間點，想確認那個時候有沒有對庫表進行過更改操做，若是沒有記錄表結構變動的歷史，也就難以提供須要的信息。

記錄差別，很早就思考過能不能用git來作。終於花了一天時間來實現，並驗證、修改達到預期的效果，還算滿意。

github項目地址在文後。

2. Concept

思路很簡單，就是利用 mydumper 導出表時會把各表（結構）單獨導成一個文件的特性，天天低峯期導出全部對象元數據：表、視圖、存儲過程、事件、觸發器。須要過濾掉 AUTO_INCREMENT 值。

結構內容存放在一個git倉庫下，經過shell腳本提交到 gitlab。全部DDL更改由原來依賴於DBA的主動記錄，變成被動採集。

測試環境和生產環境表結構總會有些差別，爲了兼顧同時收集兩個環境的數據，設置了 environment 選項，根據當前所在運行的機器，自動判斷採集哪些實例信息。

3. Usage

首先你須要可以存放表結構信息的git倉庫，如gitlab，並且建議設置爲私有。
<!-- more -->

1. 安裝 git 和 mydumper

2. 0.9.1 版本須要編譯安裝，能夠參考這裏 file-mydumper-install-ubuntu14-04-sh。固然 yum 或 apt-get 安裝其餘版本也是同樣的。

腳本會嘗試自動獲取 mydumper 命令的路徑。
注意配置git權限的時候，最好不容許其它用戶手動提交修改倉庫內容。

1. 配置db實例地址
   settings.ini示例：

[environment]
production=puppetmaster
test=puppettestmaster

[production]
production_auth=your_defaultuser:yourpassword

db_name1=192.168.1.100:3306
db_name2=192.168.1.101:3306
db_name3=name3.dbhost.com:3306
db_name4=192.168.1.100:3306:myuser:mypassword

[test]
test_auth=user1:password1

db_name1=10.0.100.1:3306
db_name2=10.0.100.1:3307
db_name3=10.0.100.2:3306

db_name4=10.0.100.3:3306:myuser1:mypassword1

• 上面的配置採集 production和test兩個環境的表結構，識別兩個環境是根據 hostname 來決定的。這樣作的好吃就是這個腳本在兩個環境下運行不須要作任何修改。

• [production]節的名字就是 [environment]節指定的名字 production=xx

• dbname1=就是配置各個db，地址+端口的形式。用戶名和密碼能夠繼續用 : 跟上

• production_auth=表示 production 環境下，如 dbname1沒有配置用戶名時，默認採用這個用戶名和密碼。這樣設計主要是簡化配置。
  該數據庫用戶須要 select,show view,event,trigger,procedure 權限。

settings_parser.py 用於解析上面的配置文件，輸出collect_tableMeta.sh易處理的格式。

1. 天天運行
   可以使用 python settings_parser.py 測試解析配置是否正常。

在配置文件裏兩個環境下（通常網絡不互通）分別加上定時任務：

# Puppet Name: collect_DBschema
5 5 * * * /opt/DBschema/collect_tableMeta.sh >> /tmp/collect_DBschema.log 2>&1

1. 展現效果
   

A 是新增，M 是修改，D 是刪除，一目瞭然。點開能夠先後對比。

4. More

思路和實現都不難，主要是意識，和如何快速找到解決當前需求的辦法。一切都是爲了效率 :)

目前所能想到更多的：

1. 有內容push到git倉庫後，使用 web hook 發出郵件。

2. 根據A,B兩個表的結構，快速獲得A修改爲B的樣子的DDL。

3. event 權限問題。event權限沒有所謂的讀和修改之分，阿里雲RDS就把它從 只讀 帳號裏拿除了，致使收集不到事件定義。因此它的高權限帳號管理模式仍是頗有做用的。

4. 密碼明文。
   最近公司邀請了一個安全公司給作培訓，數據庫安全裏面，密碼明文配置在文件裏面是普遍存在的，難搞。

GitHub地址：https://github.com/seanlook/D...

---

原文連接地址：http://seanlook.com/2016/11/2...