/tmp/mysql.sock无故丢失的故障分析

环境：Oracle goldengate通过读取/tmp/mysql.sock来同步数据。
故障：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