運維平臺的建設思考-後設資料管理（三）

繼第一篇，第二篇介紹了關於後設資料的一些想法，最近做了一些改進。
對於一部分的後設資料抽取大體有下面的兩種方式。假設資料來源已經做了很大的努力，終於統一起來了。我們現在要透過ssh的方式從源端抽取出資料來。
一種方式就是直接透過ssh的方式傳送對應的查詢指令碼，然後可以得到一個完整的列表，二次加工即可。

另外一種方式是直接在每臺伺服器上都部署一個類似agent的載體，每個伺服器端都會獨立的執行這些指令碼內容，然後透過ssh的方式返回即可。
當然下面的圖有一些誇張，實際上沒有這麼多的資料來源，只是說明了這種方式。

從個人的角度而言，如果喜歡偷懶類似一勞永逸的方式，我還是喜歡第一種方式，透過ssh傳送指令碼，然後返回服務端的執行結果。這種方式不需要特別的配置，比較輕巧快捷，當然這種場景的前提是指令碼內容不大，呼叫次數不頻繁。
假設呼叫的指令碼為seal.sql，嘗試使用下面的方式來呼叫。語句這麼簡答，我都有一種勝利在握的感覺了。
cat seal.sql | ssh 10.12.xxxx  'mysql '
但是奇怪的是，沒有任何的輸出。
反覆嘗試，在資料庫端反覆執行了指令碼，內容都沒有任何的問題。
所以感覺是不是這種方式會有一些特殊字元的影響或者是語句的註釋干擾等等。
然後在得不到任何反饋的情況下，先嚐試使用本地的方式來執行，遠端呼叫指令碼的形式，這種方式奇怪的是也依舊沒有任何結果。
嘗試了很多種方式，看起來是執行了，但是沒有結果輸出
# ssh 10.127.33.7 ' cat  /home/dba/Monitor_Hardware/seal.sql|mysql  '
Logging to file '/home/mysql/query.log'
# ssh 10.127.33.7  'mysql < /home/dba/Monitor_Hardware/seal.sql'
Logging to file '/home/mysql/query.log'
# ssh 10.127.33.7  'mysql < /home/dba/Monitor_Hardware/seal.sql > /tmp/a.log'
# ssh 10.127.33.7  "mysql < /home/dba/Monitor_Hardware/seal.sql > /tmp/a.log"
# ssh 10.127.33.7  "/usr/bin/mysql < /home/dba/Monitor_Hardware/seal.sql > /tmp/a.log"
# ssh 10.127.33.7  "/usr/bin/mysql < /home/dba/Monitor_Hardware/seal.sql > /tmp/a.log" # ssh 10.127.33.7 "mysql seal 'select user from mysql.user'"
Logging to file '/home/mysql/query.log'
呼叫了一個sql語句來驗證，發現還是有結果輸出的。
# ssh 10.127.33.7 "mysql seal -e 'select user from mysql.user'"
Logging to file '/home/mysql/query.log'
xxxxuser
sys_pm
mysqlmon
..
那麼問題在哪裡呢？
在反覆檢視指令碼之後，唯一可以假定的就是裡面有一個欄位值是中文了。
sql語句類似  select xxxxx  join xxxxx  where  device.server_responser in ('楊建榮');
按照這種情況來看，還是來看看是不是中文的影響。
可以使用這種方式來簡單驗證，傳入變數LANG
cat seal.sql | ssh 10.127.33.7 'export LANG=en_US.utf-8;mysql -vv'
還是原來的指令碼，加入-vv的選項，這種方式的輸出結果為：
Empty set
Bye
看來就是語句執行了，但是因為字符集的不相容，導致沒有查詢到任何結果。
這個問題的一個原因就是因為sql語句中的欄位值為中文，可以嘗試透過其它的code值來代替。
另外一個就是需要考慮字符集的情況，當然明確了這點。這個問題客戶端為GBK，資料庫端為UTF8，所以還是需要考慮這種差異，最後還是使用傳送指令碼的方式來執行，使用下面的方式來改進即可。
cat seal.sql |iconv -f GBK -t UTF8 | ssh 10.127.33.7 'export LANG=en_US.utf-8;mysql ' |iconv -f UTF8 -t GBK