Thoughts on the Construction of Operation and maintenance platform-metadata Management (3)
Following the first article, the second article introduces some ideas about metadata and has recently made some improvements.
There are generally two ways to extract part of the metadata. Suppose that the data source has made a great effort and finally unified. We are now going to extract data from the source side through ssh.
One way is to send the corresponding query script directly through ssh, and then you can get a complete list and reprocess it.
Another way is to deploy an agent-like carrier directly on each server, where each server runs the script independently and returns it through ssh.
Of course, the following figure is a bit exaggerated, in fact, there are not so many data sources, just to illustrate this approach.
From a personal point of view, if I like to be lazy in a way similar to once and for all, I prefer the first way, sending a script through ssh and then returning the results of the server. This method does not require special configuration, and is relatively light and fast, of course, the premise of this scenario is that the content of the script is small and the number of calls is not frequent.
Assuming that the script to be called is seal.sql, try to call it in the following way. The sentence is so simple that I have a feeling of victory in my hands.
Cat seal.sql | ssh 10.12.xxxx 'mysql'
But oddly enough, there is no output.
Repeated attempts, repeatedly run the script on the database side, the content is not any problem.
So I don't think there will be some special characters in this way or the comment interference of the statement and so on.
Then, without getting any feedback, try to run it locally, in the form of a remote invocation script, which, oddly enough, still has no results.
Tried a lot of ways, it seems to be running, but there is no result output
# 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'
A sql statement is called to verify that there is still a result output.
# ssh 10.127.33.7 "mysql seal-e 'select user from mysql.user'"
Logging to file'/ home/mysql/query.log'
Xxxxuser
Sys_pm
Mysqlmon
..
So what's the problem?
After reviewing the script over and over again, the only thing that can be assumed is that one of the field values is in Chinese.
The sql statement is similar to select xxxxx join xxxxx where device.server_responser in ('Yang Jianrong')
According to this situation, let's see if it is the influence of Chinese.
You can use this method to simply validate, passing in the variable LANG
Cat seal.sql | ssh 10.127.33.7 'export LANG=en_US.utf-8;mysql-vv'
Or the original script, add the option of-vv, and the output in this way is:
Empty set
Bye
It seems that the statement ran, but no results were found because of the incompatibility of the character set.
One reason for this problem is that because the field values in the sql statement are in Chinese, you can try to replace them with other code values.
The other is the need to consider the character set, which is, of course, clear. The client side of this problem is GBK and the database side is UTF8, so you still need to consider this difference. Finally, you should run it by sending a script and use the following ways to improve it.
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
