TRANSITION FAILOVER валится
Сообщений: 9
• Страница 1 из 1
TRANSITION FAILOVER валится
Здравствуйте, уважаемые!
Вот такая делема у меня.
Меж друмя серверами налажена репликация. Progress 11.5.1. ОС: SUSE Linux 11SP4.
Пытаюсь наладить REVERSE type of transition так, чтоб можно было легко transition failover с одного на другой и обратно.
Но все попытки команды DSRUTIL DB-NAME -C transition failover вне зависимости от конфигурации заканчивались Segmentation Fault на шаге "Synchronization in process"
Мой Линукс SUSE 11SP4 и PROGRESS 11.5.1
но я опробовал ровно тоже самое на последнем CentOS и RedHat, а также установил PROGRESS 11.7 на них. Результат абсолютно идеинтичен.
Вот скрипты и конфигурационные файлы. У меня всё в папке /dbdata/progress/
Архивирование AI необязательно, но я добавил. Для этого надо создать папку /dbdata/progress/ai
addai.st
sp_t.st
sp_s.repl.properties
sp_t.repl.properties
create.sh
Вот такая делема у меня.
Меж друмя серверами налажена репликация. Progress 11.5.1. ОС: SUSE Linux 11SP4.
Пытаюсь наладить REVERSE type of transition так, чтоб можно было легко transition failover с одного на другой и обратно.
Но все попытки команды DSRUTIL DB-NAME -C transition failover вне зависимости от конфигурации заканчивались Segmentation Fault на шаге "Synchronization in process"
- Код: Выделить всё
proenv>dsrutil sp_s -C transition failover
Transitioning database /dbdata/progress/sp_s
---------------------------------------------------------------
19:44:41 Opening database : Succeeded
19:44:41 Setting up transition : Succeeded
19:44:41 Shutting down database : Succeeded
19:44:57 Starting database in Cur Role : Succeeded
19:44:58 Synchronization in process : Segmentation fault
Мой Линукс SUSE 11SP4 и PROGRESS 11.5.1
но я опробовал ровно тоже самое на последнем CentOS и RedHat, а также установил PROGRESS 11.7 на них. Результат абсолютно идеинтичен.
Вот скрипты и конфигурационные файлы. У меня всё в папке /dbdata/progress/
Архивирование AI необязательно, но я добавил. Для этого надо создать папку /dbdata/progress/ai
addai.st
- Код: Выделить всё
a . f 2048
a . f 2048
a .
sp_t.st
- Код: Выделить всё
#
b /dbdata/progress/sp_t.b1
#
d "Schema Area":6,32;1 /dbdata/progress/sp_t.d1
#
d "Info Area":7,32;1 /dbdata/progress/sp_t_7.d1
#
d "Customer/Order Area":8,32;8 /dbdata/progress/sp_t_8.d1
#
d "Primary Index Area":9,1;8 /dbdata/progress/sp_t_9.d1
#
d "Customer Index Area":10,1;64 /dbdata/progress/sp_t_10.d1
#
d "Order Index Area":11,32;64 /dbdata/progress/sp_t_11.d1
#
a /dbdata/progress/sp_t.a1 f 2048
#
a /dbdata/progress/sp_t.a2 f 2048
#
a /dbdata/progress/sp_t.a3
sp_s.repl.properties
[server]
control-agents=agent1
database=sp_s
transition=manual
transition-timeout=1200
repl-Keep-Alive=120
defer-agent-startup=1440
agent-shutdown-action=recovery
[agent]
name=agent2
database=sp_s
listener-minport=2756
listener-maxport=2760
[control-agent.agent1]
name=agent1
database=sp_t
host=localhost
port=2755
connect-timeout=120
replication-method=async
critical=0
[transition]
replication-set=1
databass-role=reverse
restart-after-transition=1
auto-begin-ai=1
transition-to-agents=agent1
source-startup-arguments=-S 4501 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120 -DBService replserv
target-startup-arguments=-S 2755 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120 -DBService replagent
normal-startup-arguments=-S 4501 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120
sp_t.repl.properties
- Код: Выделить всё
[server]
agent-shutdown-action=recovery
control-agents=agent2
database=sp_s
defer-agent-startup=600
repl-keep-alive=120
transition=manual
transition-timeout=60
[agent]
name=agent1
database=sp_t
listener-minport=2756
listener-maxport=2760
[control-agent.agent2]
connect-timeout=60
critical=0
database=sp_s
host=localhost
name=agent2
port=2755
replication-method=async
[transition]
ai-structure-file=addai.st
auto-add-ai-areas=1
auto-begin-ai=1
backup-arguments=sp_res
backup-method=full-offline
database-role=reverse
incremental-backup-arguments=sp_res.inc
recovery-backup-arguments=!secondary.recovery.bak
responsibility=secondary
restart-after-transition=1
transition-to-agents=agent1
source-startup-arguments=-S 4501 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120 -DBService replserv
target-startup-arguments=-S 2755 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120 -DBService replagent
normal-startup-arguments=-S 4501 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120
create.sh
- Код: Выделить всё
proshut sp_s -by
proshut sp_t -by
echo y | prodel sp_s
echo y | prodel sp_t
rm *.lg
rm *.recovery
rm sp_res*
rm *.bak
rm ai/*
echo y | prodel sp_s
rm sp_s.repl.recovery
rm sp_s.st
echo y | prodb sp_s sports
prostrct add sp_s addai.st
rfutil sp_s -C mark backedup -G 0
rfutil sp_s -C aimage begin -G 0
proutil sp_s -C aiarchiver enable
proutil sp_s -C enablesitereplication source
probkup sp_s sp_res -REPLTargetCreation
echo y | prodel sp_t
rm sp_t.repl.recovery
prostrct create sp_t
prorest sp_t sp_res
proutil sp_t -C aimage begin
proutil sp_t -C aiarchiver enable
proutil sp_t -C enablesitereplication target
proserve sp_t -S 2755 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120 -DBService replagent
probiw sp_t;proaiw sp_t;prowdog sp_t;proapw sp_t
proserve sp_s -S 4501 -H localhost -aiarcdir /dbdata/progress/ai -aiarcinterval 120 -DBService replserv
probiw sp_s;proaiw sp_s;prowdog sp_s;proapw sp_s
sleep 10
echo a | rprepl sp_t -C monitor 2>/dev/null
- Arelav
- Администратор
-
- Сообщения: 1873
- Зарегистрирован: Пт мар 25, 2005 6:05 pm
- Откуда: Progress Technologies
Re: TRANSITION FAILOVER валится
>>Пытаюсь наладить REVERSE type of transition так, чтоб можно было легко transition failover с одного на другой и обратно
Не так уж это и легко, а в 11.5 вообще не возможно. Это раз.
Во вторых, не совсем понял, почему transition failover выполняется на sp_s, когда должен на sp_t. До transition failover должен быть еще просто transition, потом онлайн бэкап, восстановление из него source, запуск вторичной репликации, и только потом transition failover на secondary source (бывшей target) чтобы вернуться к первичной репликации.
Это что касается работы OE Replication до версии OpenEdge 11.7.
Для 11.7, да, при соответствующей настройке transition failover можно делать на primary source.
Во вложении архив с примером с ESAP#3 по репликации в 11.7, инструкция в файле instructions. У меня по ней всё работало успешно.
Попробуйте настроить как там описано.
Не так уж это и легко, а в 11.5 вообще не возможно. Это раз.
Во вторых, не совсем понял, почему transition failover выполняется на sp_s, когда должен на sp_t. До transition failover должен быть еще просто transition, потом онлайн бэкап, восстановление из него source, запуск вторичной репликации, и только потом transition failover на secondary source (бывшей target) чтобы вернуться к первичной репликации.
Это что касается работы OE Replication до версии OpenEdge 11.7.
Для 11.7, да, при соответствующей настройке transition failover можно делать на primary source.
Во вложении архив с примером с ESAP#3 по репликации в 11.7, инструкция в файле instructions. У меня по ней всё работало успешно.
Попробуйте настроить как там описано.
- Вложения
-
Replication_ESAP_Linux.tar
- Архив с примером с ESAP#3 по репликации в 11.7
- (24 КБ) Скачиваний: 45
Re: TRANSITION FAILOVER валится
Спасибо, Arelav!
Я сейчас попробую поработать с Вашими скриптами.
Запуская "TRANSITION FAILOVER" на source базе, я пытался следовать сценарию "planned switch of a target and source replica"
https://documentation.progress.com/outp ... n-set.html
Я сейчас попробую поработать с Вашими скриптами.
Запуская "TRANSITION FAILOVER" на source базе, я пытался следовать сценарию "planned switch of a target and source replica"
https://documentation.progress.com/outp ... n-set.html
Failover transition
Failover transition of a Replication Set is the planned switch of a target and source replica.
Failover transition is initiated by executing the following command on the source database:
dsrutil source-db -C transition failover
Re: TRANSITION FAILOVER валится
Arelav,
Спасибо ещё раз, причём ОГРОМЕННОЕ!
Ваши скрипты - именно то, что мне и нужно, ибо они делают ровно то, что нам требуется: запланированно сделать основным DR сервер, а потом без каких-либо rebase "переместиться" назад на основной PROD Server.
Когда я обнаружил, что Ваши работают, начал их упрощать, как и свои, чтобы выяснить минимальную работающую конфигурацию, ну а также причину моих сбоев.
Финально обнаружил свою "очепятку" databass-role=reverse (вконце s вместо e)
К сожалению, PROGRESS никак не изругался ни в одном из логов, что строка нераспознаваемая. Я это сейчас перепроверил.
Единственное, чем он до этого был недоволен из-за моей опечатки - отсутствие параметров для нормального запуска БД:
Вобщем сейчас всё работает в обе стороны, и кстати дополнительных бакапов не требуется, только самый первый для создания таргета.
Вот обновлённые скрипты для демонстрации процесса "туда-обратно"
Спасибо ещё раз, причём ОГРОМЕННОЕ!
Ваши скрипты - именно то, что мне и нужно, ибо они делают ровно то, что нам требуется: запланированно сделать основным DR сервер, а потом без каких-либо rebase "переместиться" назад на основной PROD Server.
Когда я обнаружил, что Ваши работают, начал их упрощать, как и свои, чтобы выяснить минимальную работающую конфигурацию, ну а также причину моих сбоев.
Финально обнаружил свою "очепятку" databass-role=reverse (вконце s вместо e)
К сожалению, PROGRESS никак не изругался ни в одном из логов, что строка нераспознаваемая. Я это сейчас перепроверил.
Единственное, чем он до этого был недоволен из-за моей опечатки - отсутствие параметров для нормального запуска БД:
db1.lg писал(а):RPLA : (12585) Property normal-startup-arguments must be specified if transition is configured to start the database after it is transitioned.
Вобщем сейчас всё работает в обе стороны, и кстати дополнительных бакапов не требуется, только самый первый для создания таргета.
Вот обновлённые скрипты для демонстрации процесса "туда-обратно"
- Код: Выделить всё
#clean.sh
proshut db1 -by;proshut db2 -by
echo y | prodel db1;echo y | prodel db2
rm *.recovery;rm *.lg;rm *.log
rm *.bak;rm *.sav;rm *.sav.inc
rm *.stdout;rm db?.st
- Код: Выделить всё
#db1.repl.properties
[server]
database=db1
control-agents=agent2
transition=manual
agent-shutdown-action=recovery
[agent]
name=agent1
database=db1
listener-minport=4505
listener-maxport=4510
[control-agent.agent2]
name=agent2
database=db2
host=localhost
port=4502
connect-timeout=60
replication-method=async
critical=0
[transition]
replication-set=1
database-role=reverse
transition-to-agents=agent2
auto-begin-ai=1
backup-method=mark
restart-after-transition=1
source-startup-arguments=-S 4501 -DBService replserv
target-startup-arguments=-S 4501 -DBService replagent
- Код: Выделить всё
#db2.repl.properties
[server]
database=db2
control-agents=agent1
transition=manual
agent-shutdown-action=recovery
[agent]
name=agent2
database=db2
listener-minport=4511
listener-maxport=4515
[control-agent.agent1]
name=agent1
database=db1
host=localhost
port=4501
connect-timeout=60
replication-method=async
critical=0
[transition]
replication-set=1
database-role=reverse
transition-to-agents=agent1
restart-after-transition=1
auto-begin-ai=1
backup-method=mark
source-startup-arguments=-S 4502 -DBService replserv
target-startup-arguments=-S 4502 -DBService replagent
- Код: Выделить всё
#/bin/bash
#create.sh
./clean.sh
prodb db1 sports
prostrct add db1 addai.st
rfutil db1 -C mark
rfutil db1 -C aimage begin
proutil db1 -C enablesitereplication source
probkup db1 db1.bak
prorest db2 db1.bak
prostrct add db2 addai.st
proutil db2 -C aimage begin
proutil db2 -C enablesitereplication target
_mprosrv db2 -S 4502 -DBService replagent
_mprosrv db1 -S 4501 -DBService replserv
echo "*****************************************"
echo "**** DBs created, Monitoring DB2 *****"
echo "*****************************************"
sleep 5
echo a | rprepl db2 -C monitor 2>/dev/null
echo "*****************************************"
echo "**** FAILING OVER from DB1 to DB2 *****"
echo "*****************************************"
sleep 5
dsrutil db1 -C transition failover
echo "*****************************************"
echo "**** Failed OVER, Monitoring DB1 *****"
echo "*****************************************"
sleep 5
echo a | rprepl db1 -C monitor 2>/dev/null
echo "*****************************************"
echo "**** FAILING BACK from DB2 to DB1 *****"
echo "*****************************************"
sleep 5
dsrutil db2 -C transition failover
echo "*****************************************"
echo "**** Failed BACK, Monitoring DB2 *****"
echo "*****************************************"
sleep 5
echo a | rprepl db2 -C monitor 2>/dev/null
Re: TRANSITION FAILOVER валится
Ещё один маленький вопрос:
listener-minport и listener-maxport (в файле DBNAME.repl.properties), может-ли их диапазон пересекаться диапазоном портов mindynamicport и maxdynamicport (файл conmgr.properties) ?
И сколько портов отводить под репликацию, зачем их там несколько?
listener-minport и listener-maxport (в файле DBNAME.repl.properties), может-ли их диапазон пересекаться диапазоном портов mindynamicport и maxdynamicport (файл conmgr.properties) ?
И сколько портов отводить под репликацию, зачем их там несколько?
- Arelav
- Администратор
-
- Сообщения: 1873
- Зарегистрирован: Пт мар 25, 2005 6:05 pm
- Откуда: Progress Technologies
Re: TRANSITION FAILOVER валится
mindynamicport и maxdynamicport в файле conmgr.properties соответствуют параметрам старта брокера базы данных -minport/-maxport, которые используются для серверов удалённых клиентов.
listener-minport и listener-maxport предназначены для выбора TCP-порта для установления подключения между агентом и серером репликации для работы через firewall. Интервал указывается на случай, если первый, второй, третий и т.д. порты окажутся заняты другими процессами ОС. Т.е. это что-то вроде гарантии, что обязательно найдётся хотя бы один свободный порт из заданного диапазона. Собственно, репликация использует только одно tcp/ip cоединение между серверов и агентом репликации, и можно указать "интервал" из одного порта. Диапазон из какого количества портов указывать - это на ваше усмотрение. Главное, чтобы хотя бы один порт из диапазона всегда был свободен.
Я бы не рекомендовал чтобы эти диапазоны пересекались, так как используются они для разных целей.
listener-minport и listener-maxport предназначены для выбора TCP-порта для установления подключения между агентом и серером репликации для работы через firewall. Интервал указывается на случай, если первый, второй, третий и т.д. порты окажутся заняты другими процессами ОС. Т.е. это что-то вроде гарантии, что обязательно найдётся хотя бы один свободный порт из заданного диапазона. Собственно, репликация использует только одно tcp/ip cоединение между серверов и агентом репликации, и можно указать "интервал" из одного порта. Диапазон из какого количества портов указывать - это на ваше усмотрение. Главное, чтобы хотя бы один порт из диапазона всегда был свободен.
Я бы не рекомендовал чтобы эти диапазоны пересекались, так как используются они для разных целей.
- Arelav
- Администратор
-
- Сообщения: 1873
- Зарегистрирован: Пт мар 25, 2005 6:05 pm
- Откуда: Progress Technologies
Re: TRANSITION FAILOVER валится
Vitaly писал(а):Arelav,
Спасибо ещё раз, причём ОГРОМЕННОЕ!
Ваши скрипты - именно то, что мне и нужно, ибо они делают ровно то, что нам требуется: запланированно сделать основным DR сервер, а потом без каких-либо rebase "переместиться" назад на основной PROD Server.
Рад, что это оказалось полезным.
Re: TRANSITION FAILOVER валится
Arelav,
Можно ещё один вопрос: когда два таргета 1 и 2 (source is 0), и transition происходит от 0 на 1, что Progress делает с таргетом 2?
Он его, 2го таргета заново восстанавливает из бэкапа?
При единственном таргете (на географически удалённом ДР-сервере) у меня всё работает отлично.
Скриптом Source and Target создаются, репликация стартует.
Затем я insert into customer(name) values ("MASTER")
После запускается transition failover.
Далее проверяется статус обеих баз и обратной репликации.
На удалённом ДР-сервере я insert into customer(name) values ("SLAVE")
Там-же запускается обратная transition failover.
В конце проверяются новые records, всё в порядке.
Когда-же я добавляю 2й таргет, а У меня после transition failover на 2й таргет репликация в состоянии "Connecting to Agent(s)" и жалуется
"RPLS 19: (10842) Connecting to Fathom Replication Agent secondtarget.
RPLS 19: (10387) The source database cannot be replicated to this target database."
Можно ещё один вопрос: когда два таргета 1 и 2 (source is 0), и transition происходит от 0 на 1, что Progress делает с таргетом 2?
Он его, 2го таргета заново восстанавливает из бэкапа?
При единственном таргете (на географически удалённом ДР-сервере) у меня всё работает отлично.
Скриптом Source and Target создаются, репликация стартует.
Затем я insert into customer(name) values ("MASTER")
После запускается transition failover.
Далее проверяется статус обеих баз и обратной репликации.
На удалённом ДР-сервере я insert into customer(name) values ("SLAVE")
Там-же запускается обратная transition failover.
В конце проверяются новые records, всё в порядке.
Когда-же я добавляю 2й таргет, а У меня после transition failover на 2й таргет репликация в состоянии "Connecting to Agent(s)" и жалуется
"RPLS 19: (10842) Connecting to Fathom Replication Agent secondtarget.
RPLS 19: (10387) The source database cannot be replicated to this target database."
- Arelav
- Администратор
-
- Сообщения: 1873
- Зарегистрирован: Пт мар 25, 2005 6:05 pm
- Откуда: Progress Technologies
Re: TRANSITION FAILOVER валится
Если версия OpenEdge меньше 11.7, то вторую target нужно пересоздавать.
Для 11.7 при настроенном replication set вторая target должна продолжить работать.
Существует два сценария для 11.7
*Recovery transition — If the source fails, the two targets transition together. After the transition completes, the primary target is transitioned to a source database, and the other is its target.
*Failover transition — If all three replicas are online, the source and two targets to transition together.
См. по ссылке:
https://documentation.progress.com/outp ... n-set.html
Для 11.7 при настроенном replication set вторая target должна продолжить работать.
Существует два сценария для 11.7
*Recovery transition — If the source fails, the two targets transition together. After the transition completes, the primary target is transitioned to a source database, and the other is its target.
*Failover transition — If all three replicas are online, the source and two targets to transition together.
См. по ссылке:
https://documentation.progress.com/outp ... n-set.html
Сообщений: 9
• Страница 1 из 1
Вернуться в PROGRESS - АДМИНИСТРИРОВАНИЕ БАЗ ДАННЫХ
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3