写了一个复制服务器的监控脚本， 放在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 回复于：2007-12-17 12:36:21
不错！
建议加上对rep 和db server的日志分析，例如，如果是duplicate key,queue 等问题导致的suspend等问题，resume依然还是会报错的，针对几个常见的错误进行一些常规处理会更加完美！
unixer123 回复于：2007-12-17 13:22:12
斑竹， 有个疑问， 就比如说duplicate key这方面的问题， 如果主点的数据表有主键， 那么在主点的操作不会成功的，这个操作就应该不会传到备点啊
还有dbserver的分析也应该是ftp到主点或备点的服务器上取下来再分析吧
wufeiwf 回复于：2008-01-04 10:08:32
部分同意，很多时候如果queue设备本身没有问题，down的connection通常因为数据不一致（总会有人不小心动过备点的数据）或者主点备点的索引有点区别造成，往往在实际应用中直接resume是成功不了的，倒是建议可以先resume ... skip tran，这样connection能up的可能性更大一点，再写点脚本去分析exception里面的语句或者数据库errorlog
[ 本帖最后由 wufeiwf 于 2008-1-4 10:10 编辑 ]
liyongquan 回复于：2008-01-04 11:16:27
在未查清DOWN的原因前直接resume ... skip tran比较危险,易造成两边的数据不一致.
wufeiwf 回复于：2008-01-04 11:35:34
skip tran是不安全，但是实际运行中就有可能已经两边数据不一致而造成的down，不skip也不行，除非手工处理，而且一定是要检查errorlog，总之不是简单的一个resume就能自动处理的，还是有比较多的情况要考虑。这种问题不能出现次数太多，否则累死了，而且系统说明用得有问题，另外在业务繁忙每天数据量大的复制系统中，事务的单位一定要尽量小，否则巨大的事务下的partition会成为噩梦。
sky_walker1011 回复于：2008-01-09 17:44:39
sky_walker1011 @sina.com
nicsky 回复于：2008-05-05 15:53:46
谢谢楼主了
Eisen 回复于：2008-07-18 09:32:18
写的很好，但是不能不说这个脚本不安全。
首先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 回复于：2008-07-18 09:53:40
问下,复制稳定吗??还有价格如何?
就是因为稳定性,和价格原因.我们一直没采用这个办法
unixer123 回复于：2008-07-21 13:39:16
起码从我们这里使用来看， 还是比较稳定的，主要还得保障主点， 和备点的ASE不要出错误， 我遇到的所有关于复制服务器的问题都是由于是ASE的备点报错，导致复制服务的复制关系停掉。复制服务器的本身没啥问题。另外那种一次对主点的几万记录的修改， 通过复制服务器传递到备点是很非常非常慢， 备点的locks的数量一定要设的高些， 否则很容易由于备点锁数量不足， 导致复制关系down掉.
hobbylu 回复于：2008-07-21 14:29:07
复制稳定性不错，性能也非常好，建议选择。另外对于复制的监控，无需这么麻烦
unixer123 回复于：2008-07-21 14:56:17
请问， 有啥更好的监控方法吗？
hobbylu 回复于：2008-07-21 15:08:14
用rsm，rsm本身就对复制进行监控，结合sybase central可以对很多事件进行声音报警
Eisen 回复于：2008-07-29 15:13:52
rsm这东西却不如rep来的稳定，感觉还是自己用cmd模式敲admin healthy来的稳妥。
|
