写了一个复制服务器的监控脚本， 大家提提意见

unixer123

写了一个复制服务器的监控脚本， 放在crontab中， 首先监控repserver,rsm是否正常运行，如果down掉， 则重新启动进程
否则， 继续执行admin who_is_down语句， 将输出结果放到一个文件中， 逐行分析时候是否存在指定的复制关系， 有的话
则形成resume connection to "复制关系“的语句， 然后执行此语句。
#!/bin/ksh

HOME_DIR=/export/home/sybaserep
LD_LIBRARY_PATH=/export/home/sybaserep/OCS-12_5/lib:/export/home/sybaserep/OCS-12_5/lib3p:
export HOME_DIR LD_LIBRARY_PATH

PROCESS_LIST=$HOME_DIR/script/process_list
LOG=$HOME_DIR/script/log
TMPFILE=$HOME_DIR/script/tmpfile
REP_CONN_LIST=$HOME_DIR/script/rep_conn_lst

DOWN="NO"

while read LINE
do
    ps -ef | grep `echo $LINE | awk '{print $1}'` | grep -v grep
    if [ "$?" = 0 ]
    then
        DOWN = "YES"
        process_name=`echo $LINE | awk '{print $1}'`
        echo "$process_name failed at `date`" >> $LOG
        start_process=`echo $LINE | awk '{print $2" "$3}'`
        $start_process
        echo "$process_name restart at `date`" >> $LOG
        echo "--------------------------------" >> $LOG
        sleep 60
    fi
done < $PROCESS_LIST

if [ $DOWN = "YES" ]
then
    exit 1
fi

eval $HOME_DIR/OCS-12_5/bin/isql -Usa -Pxxxxxxxx -Sxxxxxxxx -i$HOME_DIR/script/getdown.sql > $TMPFILE

while read REP_CONN
do
    cat $TMPFILE | grep $REP_CONN
    echo "cat" >> $LOG
    if [ "$?" != 0 ]
    then
        sql="resume connection to $LINE"
        echo $sql > $TMP_DIR/script/resume.sql
        echo "go" >> $TMP_DIR/script/resume.sql
        eval $HOME_DIR/OCS-12_5/bin/isql -Usa -Pxxxxxxxx -Sxxxxxxxx -i$HOME_DIR/script/resume.sql >> $LOG
        sleep 30
    fi
done < $REP_CONN_LIST

date >> $LOG

chenfeng825

不错！
建议加上对rep 和db server的日志分析，例如，如果是duplicate key,queue 等问题导致的suspend等问题，resume依然还是会报错的，针对几个常见的错误进行一些常规处理会更加完美！

unixer123

斑竹， 有个疑问， 就比如说duplicate key这方面的问题， 如果主点的数据表有主键， 那么在主点的操作不会成功的，这个操作就应该不会传到备点啊

还有dbserver的分析也应该是ftp到主点或备点的服务器上取下来再分析吧

wufeiwf

部分同意，很多时候如果queue设备本身没有问题，down的connection通常因为数据不一致（总会有人不小心动过备点的数据）或者主点备点的索引有点区别造成，往往在实际应用中直接resume是成功不了的，倒是建议可以先resume ... skip tran，这样connection能up的可能性更大一点，再写点脚本去分析exception里面的语句或者数据库errorlog

[ 本帖最后由 wufeiwf 于 2008-1-4 10:10 编辑 ]

liyongquan

在未查清DOWN的原因前直接resume ... skip tran比较危险,易造成两边的数据不一致.

wufeiwf

skip tran是不安全，但是实际运行中就有可能已经两边数据不一致而造成的down，不skip也不行，除非手工处理，而且一定是要检查errorlog，总之不是简单的一个resume就能自动处理的，还是有比较多的情况要考虑。这种问题不能出现次数太多，否则累死了，而且系统说明用得有问题，另外在业务繁忙每天数据量大的复制系统中，事务的单位一定要尽量小，否则巨大的事务下的partition会成为噩梦。

sky_walker1011

sky_walker1011 @sina.com

nicsky

谢谢楼主了

Eisen

写的很好，但是不能不说这个脚本不安全。
首先suspect的可能性可不光connection一种，而就算只考虑connection fail的话，也不可能只会因为duplicated key造成的resume connection fail。因为也会出现大型tran，产生大量数据将queue塞满，或者lack of mutex，num of threads...都会造成connection thread down.而这个时候对应的解决方法是configure replication server '...'或resume distributor,甚至add partition...如果仅采用一种skip tran应对的话，会导致不可预知的数据丢失。

不过楼主的想法还是很有借鉴意义的，感谢楼主。

shawnlee

问下,复制稳定吗??还有价格如何?
就是因为稳定性,和价格原因.我们一直没采用这个办法