我正在使用scp来并行复制文件使用GNU并行与我的下面的shell脚本,它工作正常。
我不知道如何在我的下面的shell脚本中使用rsync
代替scp
。 我试图看看是否rsync
与scp
相比在传输速度方面是否会有更好的性能。
以下是我的问题描述 –
我正在将machineB
和machineC
的文件复制到machineA
因为我正在machineA
运行我的下面的shell脚本。
如果在machineB
没有这些文件,那么它应该在machineC
,所以我会先尝试复制machineB
的文件,如果它不在machineB
那么我会尝试复制machineC
的相同文件。
我使用GNU并行库并行复制文件,它工作正常。 目前我正在为PRIMARY和SECONDARY同时复制五个文件。
下面是我的shell脚本 –
#!/bin/bash export PRIMARY=/test01/primary export SECONDARY=/test02/secondary readonly FILERS_LOCATION=(machineB machineC) export FILERS_LOCATION_1=${FILERS_LOCATION[0]} export FILERS_LOCATION_2=${FILERS_LOCATION[1]} PRIMARY_PARTITION=(550 274 2 546 278) # this will have more file numbers SECONDARY_PARTITION=(1643 1103 1372 1096 1369 1568) # this will have more file numbers export dir3=/testing/snapshot/20140103 do_Copy() { el=$1 PRIMSEC=$2 scp david@$FILERS_LOCATION_1:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/. || scp david@$FILERS_LOCATION_2:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/. } export -f do_Copy parallel --retries 10 -j 5 do_Copy {} $PRIMARY ::: "${PRIMARY_PARTITION[@]}" & parallel --retries 10 -j 5 do_Copy {} $SECONDARY ::: "${SECONDARY_PARTITION[@]}" & wait echo "All files copied."
有没有什么办法用rsync
replace我上面的scp
命令,但是我仍然想同时为PRIMARY
和SECONDARY
同时复制5个文件?
rsync
旨在有效地同步两个层次的文件夹和文件。
虽然它可以用来传输单个文件,但是除非您已经在每个文件的末尾都有一个文件版本,而且它们之间的差异很小,否则它不会帮助您这么做。 在层次结构中的单个文件上并行运行rsync
多个实例会影响工具的目的。
虽然三合一是正确的,你的任务是I / O绑定而不是CPU绑定的,所以并行化任务在典型情况下无论是使用rsync
还是scp
都无济于事,有一种情况是并行化网络传输可以帮助:如果发件人正在限制请求。 在这种情况下,为每个不同的文件夹运行一个rsync
实例可能会有一些价值,但是这会使你的代码变得复杂,你不得不分析这两个解决方案,以发现你是否真正获得了任何好处。
简而言之:只需运行一个rsync
实例; 你从另一个方法中获得的任何性能提升都不太可能是值得的。
你没有真正给我们足够的信息来知道你是否在一个明智的道路上,但我怀疑你应该看看lsyncd甚至GlusterFS 。 这些与你所做的不同之处在于它们是连续同步工具,而不是定期运行,尽管我怀疑你可以定期运行lsyncd,如果这是你真正想要的。 我还没有尝试过lsyncd 2.x,但我看到他们已经添加了并行同步过程。 如果您的实际场景涉及的不仅仅是您所描述的三台机器,那么查看一些点对点文件共享协议甚至可能是有意义的。
在目前的方法中,除非您的文件非常大,否则大部分延迟可能与建立连接和验证连接的开销相关联。 为每个单独的文件单独做这件事情是很昂贵的,尤其是在基于ssh的协议上。 你最好把你的文件列表分成批次,然后把这些批次传给你的复制机制。 不管你使用rsync是不是很重要,但是如果你首先为rsync进程构造一个文件列表来处理,那么你可以用--files-from
选项把它传递给rsync。
你想弄清楚你的同步速度的限制因素是什么。 据推测,这是网络带宽,网络延迟,文件IO或CPU(校验或压缩,但可能只有当你有低端硬件)之一。
了解从一次同步运行到另一次同步运行的文件变化模式也很重要。 上一次运行有没有更多的文件? 现有的文件改变了吗? 这些变化是否使大量数据块保持不变(例如数据库文件),还是只能追加(例如日志文件)? 你能否安全地依靠元数据,如文件修改时间和大小来识别发生了什么变化,或者你需要校验整个内容?
您的文件内容是否可压缩? 例如,如果您正在复制纯文本,您可能希望在scp或rsync中使用压缩选项,但是如果您已经压缩了图像或视频文件,则再次压缩只会降低速度。 如果只有部分文件发生变化的文件,rsync是非常有用的。
您可以像使用scp
一样使用rsync
下载单个文件。 只要确保不要使用调用守护进程的rsync://
或hostname::path
格式。
它至少可以使两台远程主机同时工作。 另外,如果这些文件位于不同的物理磁盘上或恰好在缓存中,那么即使在单个主机上也可以对其进行并行处理。 这就是为什么我不同意另一种说法,一个单一的事例是必然的。
我想你可以替换
scp david@$FILERS_LOCATION_1:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/. || scp david@$FILERS_LOCATION_2:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/.
通过
rsync david@$FILERS_LOCATION_1:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/new_weekly_2014_"$el"_200003_5.data || rsync david@$FILERS_LOCATION_2:$dir3/new_weekly_2014_"$el"_200003_5.data $PRIMSEC/new_weekly_2014_"$el"_200003_5.data
(注意改变不仅是命令)
也许你可以得到额外的速度,因为rsync将使用delta =传输算法相比,scp会盲目复制。