1.这是很简单的一个 文件监控+触发同步脚本
监控一台服务器下的一个文件夹，发生改变则向另一个个文件夹进行同步。
具体的inotify命令 rsync命令 可以看linux分类下的介绍
#!/bin/sh
SRC=/var/www/channel/DST=/var/www/webroot/channel/
INWT=/usr/local/bin/inotifywait
RSYNC=/usr/bin/rsync
$INWT -mrq -e create,move,delete,modify $SRC | while read D E F;do
rsync -aHqzt $SRC $DST
done
2.下面是两台机器同步的脚本，rsync 使用daeom模式，
从45机器向70机器同步，70机器上设置rsync daeom模式，rsync具体配置可以参考 linux分类下 rsync文章
由于需要同步的源目录有三层，每个数字编号的文件夹下都有一千多图片
目录结构（如下）
supp/upload/1,2,3 ……9999/
supp/public/1,2,3 …… 9999/
如果将同步源目录直接设置为 supp，rsync 每次都是全量的同步 若有10个图片发生更改，
就触发10次rsync supp全量同步(一次rsync需要30分钟——简直就是噩梦)
这种在需要同步的源目录文件量很大的情况下，简直是不堪重负。不仅耗CPU还耗时，根本不可以做到实时同步
（这里要注意 rsync -R 的用法）
rsync -avz ./upload/1 user@ip::{supp/} 结果直接在supp目录下生成1 文件夹
rsync -avzR ./upload/1 user@ip::{supp/} 结果在supp目录下生成upload/1 文件夹
#!/bin/bash
# 需要同步的源路径
src=/var/www/yunshuerqi/webroot/supp/
# 目标服务器上 rsync --daemon 发布的名称
des=oldfile
# 目标服务器上 rsync 用户登录名
user=yunshu
# rsync验证的密码文件
rsync_passwd_file=/etc/rsyncd/rsyncd.secrets
# 目标服务器
ip1=10.xx.xx.70
#进入同步源的根目录
# 此方法中，由于rsync同步的特性，这里必须要先cd到源目录，inotify再监听 ./ 才能rsync同步后目录结构一致
cd ${src}
#开始监控目录，排除Admin这个目录（不监控）
/usr/local/bin/inotifywait -mrq --format '%Xe %w%f' --include='Admin' -e modify,create,delete,attrib,close_write,move ./ | while read file
do
# 把inotify输出切割 把事件类型部分赋值给INO_EVENT
# 把inotify输出切割 把文件路径部分赋值给INO_FILE
INO_EVENT=$(echo $file | awk '{print $1}')
INO_FILE=$(echo $file | awk '{print $2}')
echo "-------------------------------$(date)------------------------------------"
echo $file
#增加、修改、写入完成、移动进事件
#增、改放在同一个判断，因为他们都肯定是针对文件的操作，
#即使是新建目录，要同步的也只是一个空目录，不会影响速度。
# 判断事件类型
if [[ $INO_EVENT =~ 'CREATE' ]] || [[ $INO_EVENT =~ 'MODIFY' ]] || [[ $INO_EVENT =~ 'CLOSE_WRITE' ]] || [[ $INO_EVENT =~ 'MOVED_TO' ]]
then
echo 'CREATE or MODIFY or CLOSE_WRITE or MOVED_TO'
rsync -avzcR --password-file=${rsync_passwd_file} $(dirname ${INO_FILE}) ${user}@${ip1}::${des}
fi
# INO_FILE变量代表路径哦 -c校验文件内容
#仔细看 上面的rsync同步命令 源是用了$(dirname ${INO_FILE})变量
#即每次只针对性的同步发生改变的文件的目录(只同步目标文件的方法在生产环境的某些极端环境下会漏文件
#现在可以在不漏文件下也有不错的速度 做到平衡)
#然后用-R参数把源的目录结构递归到目标后面 保证目录结构一致性
#删除、移动出事件
if [[ $INO_EVENT =~ 'DELETE' ]] || [[ $INO_EVENT =~ 'MOVED_FROM' ]]
then
echo 'DELETE or MOVED_FROM'
rsync -avzcR --delete --password-file=${rsync_passwd_file} $(dirname ${INO_FILE}) ${user}@${ip1}::${des}
fi
#看rsync命令 如果直接同步已删除的路径${INO_FILE}会报no such or directory错误
#所以这里同步的源是被删文件或目录的上一级路径，并加上--delete来删除目标上有而源中没有的文件，
#这里不能做到指定文件删除，如果删除的路径越靠近根，则同步的目录越多，同步删除的操作就越花时间。
#修改属性事件 指 touch chgrp chmod chown等操作
if [[ $INO_EVENT =~ 'ATTRIB' ]]
then
echo 'ATTRIB'
if [ ! -d "$INO_FILE" ]
# 如果修改属性的是目录 则不同步，因为同步目录会发生递归扫描，
#等此目录下的文件发生同步时，rsync会顺带更新此目录。
then
rsync -avzcR --password-file=${rsync_passwd_file} $(dirname ${INO_FILE}) ${user}@${ip1}::${des}
fi
fi
done
版本2. 修改新建目录同步卡死问题
版本1的问题，后台跑总是自己停，时间一般都在早上，
原因：如果新增一个目录 /supp/upload/8888
则同步命令为
rsync -avzcR --password-file=${rsync_passwd_file} $(dirname ${INO_FILE}) ${user}@${ip1}::${des} 代码
rsync -avzcR --password-file=${rsync_passwd_file} ./upload yunshu@10.xx.xx.70::oldfile 命令
这条命令会把整个shell脚本卡主，同步也停止了
改进一下，如果新增8888文件夹，则不进行同步，等文件夹内有文件生成时再一起同步，
（增加了一个判断和提示，若为文件夹则不同步——红字为修改）
do
INO_EVENT=$(echo $file | awk '{print $1}')
INO_FILE=$(echo $file | awk '{print $2}')
echo "-------------------------------$(date)------------------------------------"
echo $file
if [[ $INO_EVENT =~ 'CREATE' ]] || [[ $INO_EVENT =~ 'MODIFY' ]] || [[ $INO_EVENT =~ 'CLOSE_WRITE' ]] || [[ $INO_EVENT =~ 'MOVED_TO' ]]
then
echo 'CREATE or MODIFY or CLOSE_WRITE or MOVED_TO-start rsync'
if [ ! -d "$INO_FILE" ];then
rsync -avzcR --password-file=${rsync_passwd_file} $(dirname ${INO_FILE}) ${user}@${ip1}::${des}
fi
fi
版本3. 优化同步效率
在版本1和2中，新增一个图片会产生好几个消息，如下
7个消息，也就是这个文件夹同步了七次！！！！
1-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
CREATE ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 5018.00 bytes/sec
total size is 4869177 speedup is 1940.68
2-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
MODIFY ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 5018.00 bytes/sec
total size is 4869177 speedup is 1940.68
3-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
MODIFY ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 5018.00 bytes/sec
total size is 4869177 speedup is 1940.68
4-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
MODIFY ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 5018.00 bytes/sec
total size is 4869177 speedup is 1940.68
5-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
MODIFY ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 5018.00 bytes/sec
total size is 4869177 speedup is 1940.68
6-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
MODIFY ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 5018.00 bytes/sec
total size is 4869177 speedup is 1940.68
7-------------------------------Mon Oct 30 02:02:08 CST 2017------------------------------------
CLOSE_WRITEXCLOSE ./upload/day_171029/1509247844658982.jpg
CREATE or MODIFY or CLOSE_WRITE or MOVED_TO
building file list ... done
sent 2493 bytes received 16 bytes 1672.67 bytes/sec
total size is 4869177 speedup is 1940.68
7156
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
