已归录

环境：
被监控服务器 server ------------------> 集中监控主机 monitor

需要在 server 主机上收集数据并加工，生成文本文件,然后传输到 monitor 主机上，以供其 mysql 的 load data 命令使用。

在server上生成的文件内容如下：

# cat data/host_memory_10.11.22.40.txt 
"2018-05-03 11:19:44","10.11.22.40","31","22","8","70.96"

将该文件通过 ftp 工具传输到 monitor 机上，脚本如下：

# cat ftp_upload.sh 
#!/bin/sh
/usr/bin/ftp -n<<!
open 10.128.111.114
user zabbix 123456
prompt
cd /tmp/dba_centralized_platform
lcd data
mput host_memory_10.11.22.40.txt
bye
!

在 monitor 主机上通过 MySQL 的 load data 命令导入数据：

MySQL> load data 
infile '/tmp/dba_centralized_platform/host_memory_10.11.22.40.txt' 
into table host_memory 
fields terminated by ',' enclosed by '"';

导入后的数据如下：

mysql> select * from host_memory;
+---------------------+-------------+----------+----------+----------+--------------+
| gather_date         | ip_addr     | mem_size | mem_used | mem_free | mem_used_pct |
+---------------------+-------------+----------+----------+----------+--------------+
| 2018-05-03 11:19:44 | 10.11.22.40 |       31 |       22 |        8 |         0.00 |
+---------------------+-------------+----------+----------+----------+--------------+

看到最后一列数据是0.00，而不是正确值“70.96"。

一开始以为是数据类型的问题，尝试过float类型，decimal(4,2），decimal(5,2)等均不行。

网上搜索“mysql导入小数为0”等帖子，无果。

后面突然想到，问题出现在最后一类，会不是换行符的问题（之前有过此经历），于是查看：

# cat -A /tmp/dba_centralized_platform/host_memory_10.11.22.40.txt 
"2018-05-03 11:19:44","10.11.22.40","31","22","8","70.96"^M$

果然！！！！

由server主机上的源文件是正常的：

# cat -A data/host_memory_10.11.22.40.txt 
"2018-05-03 11:19:44","10.11.22.40","31","22","8","70.96"$

可见是在ftp传输后发生了改变，由是修改ftp的传输算法：

#!/bin/sh
/usr/bin/ftp -n<<!
open 10.128.111.114
user zabbix 123456
prompt
cd /tmp/dba_centralized_platform
lcd data
**binary**
mput host_memory_10.11.22.40.txt
bye
!

重新上传后，问题得到解决。