TRANSITION FAILOVER валится

[Vitaly Профиль]

Здравствуйте, уважаемые!

Вот такая делема у меня.
Меж друмя серверами налажена репликация. 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

Для простоты эксперимента я использовал стандартные скрипты ПРОГРЕСС и на басе SPORTS создал две базы на одном сервере и наладил меж ними репликацию.
Мой Линукс 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 Профиль СайтICQ]

>>Пытаюсь наладить 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. У меня по ней всё работало успешно.
Попробуйте настроить как там описано.

[Vitaly Профиль]

Спасибо, Arelav!
Я сейчас попробую поработать с Вашими скриптами.

Запуская "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

[Vitaly Профиль]

Arelav,
Спасибо ещё раз, причём ОГРОМЕННОЕ!
Ваши скрипты - именно то, что мне и нужно, ибо они делают ровно то, что нам требуется: запланированно сделать основным DR сервер, а потом без каких-либо rebase "переместиться" назад на основной PROD Server.

Когда я обнаружил, что Ваши работают, начал их упрощать, как и свои, чтобы выяснить минимальную работающую конфигурацию, ну а также причину моих сбоев.
Финально обнаружил свою "очепятку" databass-role=reverse (вконце s вместо e)

К сожалению, PROGRESS никак не изругался ни в одном из логов, что строка нераспознаваемая. Я это сейчас перепроверил.
Единственное, чем он до этого был недоволен из-за моей опечатки - отсутствие параметров для нормального запуска БД:

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

ну и финально create.sh

Код: Выделить всё

#/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

[Vitaly Профиль]

Ещё один маленький вопрос:

listener-minport и listener-maxport (в файле DBNAME.repl.properties), может-ли их диапазон пересекаться диапазоном портов mindynamicport и maxdynamicport (файл conmgr.properties) ?

И сколько портов отводить под репликацию, зачем их там несколько?

[Arelav Профиль СайтICQ]

mindynamicport и maxdynamicport в файле conmgr.properties соответствуют параметрам старта брокера базы данных -minport/-maxport, которые используются для серверов удалённых клиентов.

listener-minport и listener-maxport предназначены для выбора TCP-порта для установления подключения между агентом и серером репликации для работы через firewall. Интервал указывается на случай, если первый, второй, третий и т.д. порты окажутся заняты другими процессами ОС. Т.е. это что-то вроде гарантии, что обязательно найдётся хотя бы один свободный порт из заданного диапазона. Собственно, репликация использует только одно tcp/ip cоединение между серверов и агентом репликации, и можно указать "интервал" из одного порта. Диапазон из какого количества портов указывать - это на ваше усмотрение. Главное, чтобы хотя бы один порт из диапазона всегда был свободен.

Я бы не рекомендовал чтобы эти диапазоны пересекались, так как используются они для разных целей.

[Arelav Профиль СайтICQ]

Arelav,
Спасибо ещё раз, причём ОГРОМЕННОЕ!
Ваши скрипты - именно то, что мне и нужно, ибо они делают ровно то, что нам требуется: запланированно сделать основным DR сервер, а потом без каких-либо rebase "переместиться" назад на основной PROD Server.

Рад, что это оказалось полезным.

[Vitaly Профиль]

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."

[Arelav Профиль СайтICQ]

Если версия 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