故障：mysql.sock经常无故丢失，查看日志、history找不到任何被删除的迹象。
问题分析与解决：Google了一下，发现是tmpwatch自动删除机制导致的。处理思路如下
分析tmpwatch，发现有个tmpwatch的脚本
cat /etc/cron.daily/tmpwatch
flags=-umc
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
-X '/tmp/hsperfdata_*' 240 /tmp
/usr/sbin/tmpwatch "$flags" 720 /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
if [ -d "$d" ]; then
/usr/sbin/tmpwatch "$flags" -f 720 "$d"
fi
done
这个脚本会删除/tmp目录下240小时没有被访问的文件。
使用stat命令去查看/tmp目录下其他文件的atime,ctime,mtime
root># stat slow_tmp_3308.txt
File: `slow_tmp_3308.txt'
Size: 80537427 Blocks: 157472 IO Block: 4096 regular file
Device: 802h/2050d Inode: 4681258 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-08-19 10:11:54.000000000 +0800
Modify: 2014-08-19 09:59:22.000000000 +0800
Change: 2014-08-19 10:11:54.000000000 +0800
理论上来说，做一次cat、head等读取操作，这个atime就可以改变。但是实际操作后atime没有发生变化。
继续深挖，查看/etc/fstab文件，发现为了提高系统性能，/tmp目录加上了noatime属性。
总不能为了这一个文件，把系统的noatime属性去掉吧。
解决办法：
1.去掉/tmp目录的atime属性即可
2.使用脚本重建tmp目录下的mysql.sock
#!/bin/sh
#此脚本是用来重新生成tmp目录下的mysql.sock，防止tmpwatch清理tmp目录后导致goldengate中断
#Written By:Li Hui
#Date:2014-09-11
#先关闭goldengate同步
cd /data/mysql_ogg/
rlwrap ./ggsci
stop xxx *
EOF
#重建mysql.sock
rm /tmp/mysql.sock
ln -s /data/mysqldata/3308/mysql.sock /tmp/mysql.sock
#开启goldengate同步
rlwrap ./ggsci
start xxx
EOF
rlwrap ./ggsci
start xxx
EOF