惊!Rsync 文件同步竟遭遇失败?手把手教你排查,告别同步烦恼!

2024-11-08 14:11:38 Jinyu 273

问题

rsync客户端:抛错异常退出

发布失败截图如下:

图片

看报错信息应该是 rsync 同步文件失败,并非 salt 问题,为确认这点,我们登录 salt-master,手工执行 rsync 命令,确实无返回,排除 salt 及 salt-api 问题。
登录同步异常服务器,手工执行 rsync 同步命令,可以复现:








# rsync -avz --delete --exclude='.git' --exclude='.svn' rsync://<rsync_srv>:<rsync_port>/path/to/folder /tmp/rsync-testreceiving incremental file list...rsync: read error: Connection reset by peer (104)rsync error: error in rsync protocol data stream (code 12) at io.c(759) [receiver=3.0.6]rsync: connection unexpectedly closed (99 bytes received so far) [generator]rsync error: error in rsync protocol data stream (code 12) at io.c(600) [generator=3.0.6]

rsync客户端:进程僵死

周四反馈发布失败的同学情况又不一样了,发布并未抛明显异常,但是进度条卡住一直无返回,查询 salt-master 日志后,rsync 命令成功下发,但确实无结果返回,怀疑服务器执行 rsync 命令失败,进程僵死,手工上服务器执行了把,确实如此,只有当手工终止 rsync 命令后(ctrl+c),才抛异常信息:










# rsync -avzP --delete--exclude='.git' --exclude='.svn' rsync://<rsync_srv>:<rsync_port>/path/to/folder /tmp/rsync-testPassword: receiving incremental file list./<rsync-test-pkg>-SNAPSHOT.jar^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(551) [generator=3.0.9]
rsync error: received SIGUSR1 (code 19) at main.c(1298) [receiver=3.0.9]

执行第二,甚至第三次时,才成功:










# rsync -avzP --delete--exclude='.git' --exclude='.svn' rsync://<rsync_srv>:<rsync_port>/path/to/folder /tmp/rsync-testPassword: receiving incremental file list./<rsync-test-pkg>-SNAPSHOT.jar60606801 100% 16.13MB/s0:00:03 (xfer#1, to-check=0/3)
sent 21035 bytesreceived 43167123 bytes5758421.07 bytes/sectotal size is 60607326speedup is 1.40

网上搜了下,发现已经有人发现 rsync 类似问题了,引用其博客:

尽管您可能已经在rsyncd服务的后端进程中设置了--timeout选项(即在rsyncd.conf配置中),然而,在某些情况下(under the circumstances),这个选项可能根本不起作用,一些极不稳定的网络导致大量TCP超时连接,进而导致 rsync 进程失败,虽然断裂的 TCP 连线已经消失,但 rsync 应用进程却可能因为种种原因(如因等候I/O中断而处于不可中断状态),而遗留在系统之中,并最终变成为僵尸进程(zombie process)。

按照其手册页的解释,rsync 命令本身的 timeout 预设为0,也就是没有逾时设置,因此运行中的 rsync 进程将会永久地等待远端的反应。在rsyncd服务后端进程的 rsyncd.conf中设置timeout选项,同时在rsync客户端命令行中使用timeout选项,实践证明是可杜绝此问题的。

于是在服务器上添加 --timeout 参数,再次执行后确实能够异常退出了:

# rsync -avzP --timeout=60 --delete--exclude='.git' --exclude='.svn' rsync://<rsync_srv>:<rsync_port>/path/to/folder /tmp/rsync-testPassword: receiving incremental file list./<rsync-test-pkg>-SNAPSHOT.jar2011425333% 19.18MB/s0:00:02[receiver] io timeout after 60 seconds -- exitingrsync error: timeout in data send/receive (code 30) at io.c(140) [receiver=3.0.9]rsync: connection unexpectedly closed (115 bytes received so far) [generator]rsync error: error in rsync protocol data stream (code 12) at io.c(605) [generator=3.0.9]

rsync服务端:异常日志

怀疑过是不是rsync服务端问题,重启过服务端rsync服务,问题依然存在;换过rsync服务端,问题依然存在,由此可以排除服务端问题。
但无论客户端抛哪种问题,服务端均能捕捉到,并输出相应日志:







2018/10/26 14:40:30 [4228] name lookup failed for <rsync-client>: Name or service not known2018/10/26 14:40:30 [4228] connect from UNKNOWN (<rsync-client>)2018/10/26 14:40:30 [4228] rsync on path/to/folder from UNKNOWN (<rsync-client>)2018/10/26 14:40:30 [4228] building file list2018/10/26 14:40:35 [4228] rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Connection timed out (110)2018/10/26 14:40:35 [4228] rsync error: error in rsync protocol data stream (code 12) at io.c(1525) [sender=3.0.6]

rsync客户端:strace排查

通过 strace 来跟踪 rsync 进程执行时的系统调用和所接收的信号,但未发现系统级明显异常:

lstat("<rsync-test-pkg>-SNAPSHOT.jar", 0x7fff7d6e0000) = -1 ENOENT (No such file or directory)select(5, [4], [3], [3], {30, 0}) = 2 (in [4], out [3], left {29, 999998})select(5, [4], [], NULL, {30, 0}) = 1 (in [4], left {29, 999999})read(4, "34", 8184)= 4write(3, "2671103240", 26) = 26select(5, [4], [], NULL, {30, 0}./<rsync-test-pkg>-SNAPSHOT.jar) = 0 (Timeout)8.79MB/s0:00:02select(5, [4], [], NULL, {30, 0}) = 0 (Timeout)select(5, [4], [], NULL, {30, 0}[receiver] io timeout after 60 seconds -- exitingrsync error: timeout in data send/receive (code 30) at io.c(140) [receiver=3.0.9]) = 1 (in [4], left {28, 559609})--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=15649, si_status=30, si_utime=20, si_stime=5} ---wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 30}], WNOHANG, NULL) = 15649wait4(-1, 0x7fff7d6e11e4, WNOHANG, NULL) = -1 ECHILD (No child processes)rt_sigreturn()= 1read(4, "", 8184) = 0write(2, "rsync: connection unexpectedly c"..., 77rsync: connection unexpectedly closed (115 bytes received so far) [generator]) = 77write(2, "
", 1) = 1rt_sigaction(SIGUSR1, {SIG_IGN, [], SA_RESTORER, 0x7f1e73cca670}, NULL, 8) = 0rt_sigaction(SIGUSR2, {SIG_IGN, [], SA_RESTORER, 0x7f1e73cca670}, NULL, 8) = 0getpid()= 15648kill(15649, SIGUSR1)= -1 ESRCH (No such process)write(2, "rsync error: error in rsync prot"..., 89rsync error: error in rsync protocol data stream (code 12) at io.c(605) [generator=3.0.9]) = 89write(2, "
", 1) = 1exit_group(12)= ?+++ exited with 12 +++

问题根源:网络质量

由于发布系统与qa环境不在同一个机房,存在跨机房调用的情况,而两端间的链路是走的公网VPN线路,确实可能存在质量不稳定的情况。
在执行rsync命令异常的qa环境服务器上,抓到的包是这样的:

图片

而我们在与发布系统在同一机房网络环境下,抓到的包是这样的:

图片

很明显,跨机房网络传输数据包中充斥着丢包、乱序以及重传,从而导致传输失败;
而在稳定的网络环境下,tcp包有序进行,rsync传输毫无问题。

TCP协议

这边在相同的源服务器上部署了nginx,通过80端口,开放http协议,供相同的客户端进行下载,结果发现wget相同文件,没有任何问题,而且网速还挺快的:












# wget http://<sitename>/<rsync-test-pkg>-SNAPSHOT.jar--2018-10-26 10:57:45--http://<sitename>/<rsync-test-pkg>-SNAPSHOT.jarResolving <sitename> (<sitename>)... 10.20.51.127Connecting to <sitename> (<sitename>)|10.20.51.127|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 60606801 (58M) [application/java-archive]Saving to: ‘<rsync-test-pkg>-SNAPSHOT.jar’
100%[==================================================================================================================================================================>] 60,606,8019.81MB/s in 5.2s
2018-10-26 10:57:50 (11.1 MB/s) - ‘<rsync-test-pkg>-SNAPSHOT.jar’ saved [60606801/60606801]

但对其流量抓包,发现仍然有丢包的现象:

图片

这就说明了一个现象:
rsync 的网络传输协议特别依赖网络质量稳定性,推测当其tcp丢包、乱序或重传次数到达一定阈值时,便造成文件同步失败。

缓解

询问了网络的同事,没有办法快速解决,除非花钱买专线,但资源成本太高,为解决跨机房数据同步这个问题,小题大做了。
所以在目前网络环境下,无法从根源上有效解决该问题。
这边尝试过让异常用户重启下rsync客户端服务器,发现重启后能够同步成功,给到反馈发布失败的用户,也是给到该解决办法,即使用户很不理解为什么发布失败为什么需要他们重启服务器来解决,其实我也表示很无奈啊…

后记

当然,问题还是存在,rsync不行,这边就需要考虑通过其他方式来完成机房间文件存储同步了,这块需要后续调研下。


我要咨询