Shell脚本中一个奇怪的问题
这是学习笔记的第 2062 篇文章
今天下午调试了一个Shell脚本,简直是刷新了自己的认知,总体来说,这是一种难得的学习状态:当你精疲力竭找不到出口时,会去尝试各种可能,甚至是不可能的方法,而一旦找准了方向,找到了问题的症结,竟然发现是那些简单的可以笑掉大牙的小问题,不过问题解决之后那种收获还是很有意思的,无论如何,这个过程都值得自己总结,避免后续犯更lower的小错误。
脚本的内容是一个数据流转相关的需求,背景是一个分布式环境,数据是按照天为单位存储的,需要把这些数据转储做统计分析,源端为MySQL的分布式集群,目标端是Greenplum.
为了减少彼此的依赖,我们经过讨论是使用了csv文件的方式进行数据同步,目前的粒度为T+1,即今天统计的是昨天的数据,整个流程涉及几个环节:
1.源端MySQL导出csv文件
2.csv文件流转到ETL服务器
3.Greenplum端加载csv文件
4.完成统计分析
目前MySQL分布式集群是16个分片,4个物理节点,需要把这16个分片的数据导出。
从逻辑层面来看,是16个分片,从服务器维度来看,是4台服务器,而对于统计分析来说,是1个数据源,所以粒度可大可小,处理方式也是截然不同。
我们把导出和流转的过程再细化一下:
1)如果当前目录的CSV文件已存在,则生成错误记录,跳出导出过程
2)如果当前目录的CSV文件不存在,则导出CSV文件
3)查看导出日志,是否存在错误,如果存在则终止数据流转至ETL服务器
4)如果没有错误,则使用scp或者rsync的方式同步文件至ETL服务器
5)移动当前的导出文件至归档目录
结果碰到了魔性的一些场景,我手工执行脚本,整个流程很正常,但是在crontab中执行了一部分,也没有任何报错。
我把crontab里面的命令复制出来,手工执行,依然可以正常执行,但是在crontab中执行了一部分,没有任何报错。
所以这几个现象让我感到很郁闷,看起来是多么简单的一个需求,竟然这么纠结。
我试了几种方式来排查这个问题,首先第1,2步通过输出日志验证是没有问题的。
所以我们的焦点就集中在了第3点和第4点。
如果文件导出存在错误,就不做文件传输,在脚本中加了一些明细日志,可以很肯定的说,这个逻辑也没有问题。
那问题的重点就自然到了第4点,如果导出正常,则传输文件至ETL服务器。
这个脚本的部分内容类似下面的形式:
file_name_prefix=${tab_name}_${date_tag}_${id}
scp -P 20022 ${file_name_prefix}_xxxx.csv [email protected]:/data/grw_data
文件的格式类似于 test_data_20190805_10_xxxx.csv,需要通过scp把文件传输到ETL服务器。
在scp的部分我做了不下20次调试,最后肯定就是这个scp的命令部分存在问题,让我纠结的,还不知道是什么原因导致的,我们做了如下的排除工作。
排除了scp的用户的一些配置差异
排除了日志的输出格式的处理差异
排除了scp命令在循环中的语法差异
排除了scp命令的限制,改用rsync的方式问题依然存在
排除了crontab任务属主的潜在配置差异
。。。。
最后发现scp -P 20022 ${file_name_prefix}_xxxx.csv [email protected]:/data/grw_data这个命令里面的文件是没有路径的,也就意味着这是相对路径,我改为绝对路径之后整个问题就很顺畅了。
这个问题让我调试的有些心力憔悴,明白了缘由,一鼓作气把脚本的其他逻辑都补充好了。
至此我对scp命令不会存在阴影了,也不会怀疑人生了,而反推这个过程,我依旧不能肯定自己能够快速定位到这个问题,所做的就是遵守一些基本的规范。