運維平臺的建設思考-元數據管理（三）

繼第一篇，第二篇介紹了關于元數據的一些想法，最近做了一些改進。
對于一部分的元數據抽取大體有下面的兩種方式。假設數據源已經做了很大的努力，終于統一起來了。我們現在要通過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