Восстановление IBM Informix Enterprise Replication сервера после краха
Ключевые слова: (найти похожие документы)
From: Борис Державец <dba477@list.ru.>
Newsgroups: email
Date: Sun, 23 Jan 2005 20:29:37 +0500 (YEKT)
Subject: Восстановление IBM Informix Enterprise Replication сервера после краха
Online Disaster-Recovery процедура для IBM Informix Enterprise
Replication сервера 9.2 и выше, входящего в Update Anywhere Enterprise
Replication
server_xx - имя UNIX сервера для ER сервера g_xx ,соответственно
описанное в SQLHOSTS файле на каждом ER сервере.
Предположим ER сервер g_cp терпит крах (мы допускаем,что Informix Dynamic
Server на хосте server_cp остался в режиме online,иначе первый "delete"
не нужен).
Удалим ER сервер g_cp из системы:
informix@server_cp$ cdr delete server g_cp
informix@server_tp$ cdr delete server g_cp - connect server_tp
Первая команда удаляет ER сервер и глобального каталога
на локальном хосте, вторая удаляет его из всей системы.
Допустим server_cp восстановлен и готов к синхронизации.
Определим g_cp как ER сервер в системе:
informix@server_cp$ cdr def server -connect server_cp -I -S g_tp g_cp
-A $INFORMIXDIR/ats -R $INFORMIXDIR/ris
-A определяет Aborted Transaction Spooling Directory;
-R определяет Row Information Spooling Directory
Определим репликации на g_cp ,выполнив скрипт change_repl.ksh:
#!/usr/bin/ksh
for TABLE in `cat table_list`
do
cdr change replicate -a repl_${TABLE} sitesdata@server_cp:informix.${TABLE}
"select * from ${TABLE}"
if [ $? == 0 ] then
echo "repl _"${TABLE}" updated OK"
else
echo "repl_"${TABLE}" update failed"
exit 1
fi
done
Выполним "suspend" всех серверов в направлении g_cp.
informix@server_cp$ cdr suspend server g_cp g_tp g_ft g_sc
Стартуем репликации на g_cp ,выполнив скрипт start_repl.ksh:-
#!/usr/bin/ksh
for TABLE in `cat table_list`
do
cdr start replication repl_${TABLE} g_cp
if [ $? == 0 ] then
echo "repl_"${TABLE}" started OK"
else
echo "repl_"${TABLE}" start failed"
exit 1
fi
done
С этого момента транзакции помещаются в очереди, но не реплицируются
#!/usr/bin/ksh
# onpunload.ksh. Script invokes onpload utility to unload data on any
# running ER server
# Unload job named unload_${TABLE} has been already created in HPL
# environment and stored in onpload database for each TABLE value
# in table_list file.
# Autogenerate Load Components panel configured output file as
# /dataserver/unload/${TABLE}.dat, target database as "sitesdata" and table
# as ${TABLE}
########################################################################
for TABLE in `cat table_list`
do
onpload -p sites -j unload_$(TABLE) -fu
if [ $? == 0 ] then
echo "repl_"${TABLE}" unloaded OK"
else
echo "repl_"${TABLE}"unload failed"
exit 1
fi
done
Compress all unloaded ASCII files ,create tar ball and download to
/dataserver/load on server_cp. Untar ball and uncompress *.Z files in
/dataserver/load directory on server_cp.
#!/usr/bin/ksh
# onpload.ksh
# Script invokes onpload utility to load data on ER server supposed to be
# synchronized.
# Load job named load_${TABLE} has been already created with Deluxe
# without replication option in High Performance Loader Environment and
# stored in onpload database for each TABLE value in table_list file.
# Autogenerate Load Components panel configured input file as
# /dataserver/load/${TABLE}.dat,target database name "sitesdata" and table
# as ${TABLE}
########################################################################
for TABLE in `cat table_list`
do
onpload -p sites -j load_${TABLE} -fcl
if [ $? == 0 ] then
echo ${TABLE}" loaded OK"
else
echo ${TABLE}" load failed"
exit 1
fi
done
Стартуем репликации на всех ER серверах, отменив статус "suspended":
informix@server_tp$ cdr resume server g_cp g_tp g_ft g_sc
С этого момента система может войти в режим с чрезвычайно высокой
активностью транзакций на всех серверах , входящих в Update Anywhere
Enterprise Replication. Размеры "Send dbspace" и "Receive dbspace" дожны
быть достаточно велики,чтобы аккомодировать эту активность.
Общая длина журналов протоколирования транзакций тоже должна быть
достаточно велика, с учетом того,что LTXHWM > 2*LTHWM для ER
сервера.То есть транзакция должна быть откачена до достижения LTXHWM.
"DDR threads" могут по нескольку раз стартовать и заканчивать "catch up phase"
на любом из серверов системы. Это поведение следует рассматривать как
нормальное.
843 Прочтений • [Восстановление IBM Informix Enterprise Replication сервера после краха] [08.05.2012] [Комментариев: 0]