Этот сайт посвящается администрированию баз данных OpenEdge Progress.
Не корысти ради, а познания для!

С уважением,
Валерий Башкатов
Сайт разработан при участии компании Progress Technologies, официального дистрибьютора Progress Software Corp. на территории стран СНГ и Латвии.

RSS RSS подписка на обновления сайта

Поиск по сайту

Лучшие материалы

Orphus System
На сайте функционирует система коррекции ошибок. Обнаружив неточность в тексте, выделите её и нажмите Ctrl+Enter



Результаты опроса: Нужны ли книги по Progress OpenEdge на русском языке? (опрос проводился с мая 2009 по ноябрь 2010)

Да, нужны. Потому что будет легче понять материал - 268
Нет, не нужны. Достаточно материалов на английском языке - 10
Не знаю, мне всё равно - 6

А знаете ли вы что..



OpenEdge Replication: создание TARGET-базы средствами операционной системы


В стандартном варианте для создания TARGET-баз данных используется резервная копия SOURCE-базы, созданная с помощью утилиты PROBKUP. И это правильно, надежно и удобно, но только до поры до времени, пока размер базы данных небольшой, скажем до 100Гб. Но что если размер базы данных несколько сотен гигабайт? Время на формирование резервной копии значительно увеличивается, а значит, увеличивается время, необходимое для восстановления TARGET-базы, если по каким-либо причинам, сознательно или нет, мы её «потеряли». Впрочем, и для первичной настройки репликации не хочется тратить драгоценное время на формирование резервной копии стандартными средствами OpenEdge. В этой статье я расскажу, как восстановить TARGET-базу не используя утилиту PROBKUP с минимальным временем простоя базы данных. Свой пример приведу с использованием обычной команды копирования в Linux – cp. Её вы всегда можете заменить на что-то другое, более эффективное, например, сформировав копию базы с помощью технологии снапшотов (SnapShot), что в разы быстрее. Главное, это порядок ваших действий при копировании базы данных средствами операционной системы.

Для выполнения нашего примера, нам сначала надо активировать в базе данных механизм OpenEdge Replication. Я не стал изощряться с настройками репликации и использовал минимально необходимый набор параметров для её работы. Для наших опытов, как обычно, используем базу данных sports из каталога $DLC. Итак, начнем.

Создадим каталог для базы данных:

$ mkdir replic
$ cd replic/
$ mkdir source
$ cd source/

Сделаем копию базы $DLC/sports в каталог source:

$ procopy $DLC/sports ./sports

Для работы OpenEdge Replication необходим механизм After-Imaging. Добавим в базу AI-экстенты, затем, в нашем случае, пометим базу как скопированную и включим After-Imaging. В завершении активируем механизм автоматической архивации AI-экстентов AI File Management.

Создаем st-файл с описанием AI-экстентов:

vi ai.st

Описываем AI-экстенты, для примера хватит пяти. Рекомендую использовать AI-экстенты переменного размера. Разницы в производительности между использованием переменных и фиксированных AI-экстентов фактически нет, за то с фиксированными экстентами проблем больше:

a .
a .
a .
a .
a .

Добавляем AI-экстенты:

$ prostrct add sports ai.st -validate #проверим правильность формата файла
The structure file format is valid. (12619)


$ prostrct add sports ai.st
Formatting extents:
size                area name   path name
16       After Image Area 1 /home/valeriy/replic/source/sports.a1 00:00:00
16       After Image Area 2 /home/valeriy/replic/source/sports.a2 00:00:00
16       After Image Area 3 /home/valeriy/replic/source/sports.a3 00:00:00
16       After Image Area 4 /home/valeriy/replic/source/sports.a4 00:00:00
16       After Image Area 5 /home/valeriy/replic/source/sports.a5 00:00:00

Помечаем базу как скопированную:

$ rfutil sports -C mark backedup

Включаем After-Imaging:

$ rfutil sports -C aimage begin
The BI file is being automatically truncated. (1526)

Теперь подготовим файл настроек репликации для Source-базы. Возьмем его шаблон из $DLC:

cp $DLC/properties/source.repl.properties ./

Переименуем полученный файл:

$ mv source.repl.properties sports.repl.properties

Отредактируем содержимое, чтобы настройки выглядели так:

[server]
control-agents=agent1
database=sports
transition=manual
transition-timeout=1200
defer-agent-startup=1400

[control-agent.agent1]
database=sports
host=localhost
port=4501
connect-timeout=120
replication-method=async
critical=0
[transition]
database-role=normal

Здесь мы только изменили имя нашей базы в параметре database секций [server] и [control-agent.agent1], а также добавили в секцию [server] параметр defer-agent-startup=1400. Параметр defer-agent-startup указывает серверу репликации на то, как долго он должен ждать появления коннекта к TARGET-базе в минутах.

Мы готовы к активации OpenEdge Replication:

$ proutil sports -C enablesitereplication source
Replication (source) is now enabled for database sports. (10351)

В завершении активируем AI File Management:

$ rfutil sports -C aiarchiver enable
Archiver has been enabled.

Создадим файл параметров для старта базы sports:

$ vi sports.pf

Его содержимое:

-S 4500
-B 10000
-L 20000
-spin 8000
-pica 512
-bibufs 30
-aibufs 45
-aistall
-aiarcdir ./ai
-aiarcdircreate
-aiarcinterval 300
-bithold 75000
-bistall
-DBService replserv

Я не буду акцентировать внимание на значениях этих параметров, о них можно почитать в документации к OpenEdge или в моих книгах.

Мы готовы к старту базы данных с включенным механизмом OpenEdge Replication:

$ proserve sports -pf sports.pf
OpenEdge Release 11.0 as of Tue Aug 23 19:00:21 EDT 2011
17:22:15 BROKER     The startup of this database requires 49Mb of shared memory.  Maximum segment size is 1024Mb.
17:22:15 BROKER  0: Multi-user session begin. (333)
17:22:15 BROKER  0: Connections to this database will not be allowed until all Database Services started have completed their startup and initialisation. (10545)
17:22:15 BROKER  0: Before Image Log Initialisation at block 0  offset 235. (15321)
17:22:15 BROKER  0: The After-image Extent Management daemon has created the directory /home/valeriy/replic/source/ai. (13217)
17:22:15 BROKER  0: Login by valeriy on /dev/pts/0. (452)
17:22:15 BROKER  0: The OpenEdge Replication Server is starting...
17:22:15 BROKER  0: Started for 4500 using TCP IPV4 address 0.0.0.0, pid 25734. (5644)

С этой минуты стартованный сервер репликации будет проверять возможность подключение к своей TARGET-базе. При этом наши пользователи могут полноценно работать с базой sports. Стоит ли говорить о том, что пока мы не создали TARGET-базу, заполненные AI-экстенты не будут освобождаться. Следите за ними, и пока они все не заполнились, либо добавьте новые AI-экстенты в online, либо увеличьте интервал переключения между AI-экстентами в AI File Management, либо AI File Management отключите на это время. В последних двух случаях главное, чтобы AI-экстенты базы были переменного размера. Следить за состоянием AI-экстентов можно командой:

$ rfutil sports -C aimage extent list

Итак, у нас есть стартованная базы данных с работающим механизмом OpenEdge Replication. Настало время приступить к созданию TARGET-базы средствами операционной системы. Особенность формирование резервной копии любой базы данных нестандартными средствами заключается в том, что во время формирования, пользователи могут внести изменения в базу данных, что приведет к рассогласованности и повреждению такой копии. Чтобы этого избежать необходимо на время копирования остановить транзакционную активность в копируемой базе. У нас есть два варианта, либо остановить SOURCE-базу, что подразумевает отключение всех пользователей и в большинстве случаев не представляется возможным, либо остановить транзакционную активность на стартованной базе командой PROQUIET. В последнем случае все пользователи останутся подключенными к базе, лишь их действия по изменению данных просто будут «заморожены», в то время как пользователи, которые формируют отчеты, не вносящие ни каких изменений в базу, будут продолжать работать. После восстановления транзакционной активности «замороженные» пользователи продолжат работать так, как ни в чем не бывало.

На стартованной базе останавливаем транзакционную активность:

$ proquiet sports enable -REPLTargetCreation

Обратите внимание на параметр <-REPLTargetCreation>, он обязателен для создания копии для TARGET-базы. Кроме того, этот параметр чувствителен к регистру, поэтому его написание должно быть точно таким, как в примере.

Начнём копирование, но перед этим создадим в каталоге replic каталог target, в который и будем копировать:

$ mkdir ../target

Внимание! В нашем примере мы имеем дело с простой структурой базы, в то время как файлы промышленной базы данных могут размещаться в разных каталогах файловой системы. Не забудьте скопировать все файлы, в этом вам поможет структурный файл базы, в котором прописаны пути ко всем файлам. Предварительно обновите структурный файл командой PROSTRCT LIST.

Копируем базу:

$ cp  ./sports* ../target/

Восстанавливаем транзакционную активность в исходной базе:

$ proquiet sports disable

База данных вернулась в рабочее состояние, и пользователи вновь работают с ней. Забудем на время о SOURCE-базе.

Переходим в каталог с копией:

$ cd ../target/

В первую очередь изменяем файл настроек репликации target/sports.repl.properties. Удаляем в нём все настройки и вносим новые:

[agent]
database=sports
listener-minport=4387
listener-maxport=4500
[transition]
database-role=normal

Удалим lock-файл, который остался от SOURCE-базы. В этом примере мы его захватили при копировании, но его можно сразу исключить на стадии копирования. Внимание!Будьте осторожны! Никогда не удаляйте lk-файл промышленной базы, находящейся в стартованном состоянии. Прежде чем его удалить в такой базе, убедитесь, что с базой никто не работает. В противном случае удаление lk-файла на работающей базе может привести к непоправимым последствиям. В нашем случае его можно удалить, так как это копия промышленной базы, с которой действительно ни один процесс не работает.

$ rm -f sports.lk

Изменим пути к файлам базы в структурном файле sports.st на новое расположение этих файлов, заменив каталог source на каталог target. После чего корректируем пути непосредственно в базе данных:

$ prostrct repair sports sports.st
Prostrct repair of database sports using structure file sports.st completed. (13485)

Изменяем роль базы данных с SOURCE на TARGET:

$ proutil sports -C enablesitereplication target
Replication (target) is now enabled for database sports. (10351)

Отключаем механизмы AI File Management и After-Imaging, унаследованные от SOURCE-базы:

$ rfutil sports -C aiarchiver disable
After-image Extent Management has been disabled for the database. (13292)
$ rfutil sports -C aimage end
After-image disabled. (846)

Изменяем файл параметров sports.pf. Теперь он должен содержать следующее:

-S 4501
-B 10000
-L 20000
-spin 1
-bibufs 50
-pica 4096
-DBService replagent

Проверяем, что сервер репликации на SOURCE-базе по-прежнему работает:

$ dsrutil ../source/sports -C monitor
OpenEdge Replication Monitor                  Page 1
Database:  /home/valeriy/replic/source/sports
S.  Replication server status

R.  Replication server remote agents
A.  Replication agent status
M.  Modify display defaults
Q.  Quit
Enter your selection:


Выбираем S (Replication server status):

OpenEdge Replication Monitor                  Page 1
Database:  /home/valeriy/replic/source/sports
Database is enabled as OpenEdge Replication:  Source
Server is:                                  Connecting to Agent(s)
Number of configured agents:                1
Defer Agent Startup :
Continue connection attempts until:     Thu Nov 24 17:50:17 2011
Deferred Agent startup will expire in : 22 Hr 55 Min 45 Sec
Next connection attempt in :            4 Min 58 Sec

Connection attempts performed :         4
Agent(s) currently connected :          0
Delay Interval (current / min / max):       5 / 5 / 500
Recovery information:
State:                                  No recovery being performed
Agents needing recovery:                0
Agents connected:                       0
Agents in synchronization:              0
Transition information:
Type:                                   Manual
RETURN - repeat, U - continue uninterrupted, Q - quit:

Во-первых, мы подключились - уже хорошо, значит, сервер репликации жив. Во-вторых, в строке «Next connection attempt in» видим, что у нас есть время до следующей попытки подключения. В прочем, не страшно, если в этом поле будет вместо времени значение «Now occurring». Главное, что сервер работает.

Стартуем TARGET-базу:

$ proserve sports -pf sports.pf
18:58:10 BROKER     The startup of this database requires 54Mb of shared memory.  Maximum segment size is 1024Mb.
18:58:10 BROKER  0: Multi-user session begin. (333)
18:58:10 BROKER  0: Connections to this database will not be allowed until all Database Services started have completed their startup and initialisation. (10545)
18:58:10 BROKER  0: Begin Physical Redo Phase at 0 . (5326)
18:58:10 BROKER  0: Physical Redo Phase Completed at blk 0 off 1198 upd 0. (7161)
18:58:10 BROKER  0: At end of Physical redo, transaction table size is 5445. (13547)
18:58:10 BROKER  0: Login by valeriy on /dev/pts/0. (452)
18:58:10 BROKER  0: The OpenEdge Replication Agent is starting...
18:58:10 BROKER  0: Started for 4501 using TCP IPV4 address 0.0.0.0, pid 26032. (5644)

Вновь подключаемся к мониторингу сервера репликации:

$ dsrutil ../source/sports -C monitor

Параллельно в отдельном окне подключаемся к мониторингу агента репликации на TARGET-базе, для этого:

$ dsrutil ../target/sports -C monitor
OpenEdge Replication Monitor                  Page 1
Database:  /home/valeriy/replic/target/sports
S.  Replication server status
R.  Replication server remote agents
A.  Replication agent status

M.  Modify display defaults
Q.  Quit


Выбираем A (Replication agent status):

OpenEdge Replication Monitor                  Page 1
Database:  /home/valeriy/replic/target/sports
Database is enabled as OpenEdge Replication:  Target
Agent:
Name:                                   agent1
ID:                                     1
Host name:                              127.0.0.1
State:  Normal Processing
Ready:                                  Yes
Critical:                               No
Method:                                 Asynchronous
Agent is waiting for:                       Nothing
Maximum bytes in TCP/IP message:            8504
Server/Agent connection time:               Wed Nov 23 19:00:44 2011
Delay Interval (current / min / max):       180 / 5 / 500
Transition information:
Type:                                   Manual
The last block received at:                 Wed Nov 23 19:00:45 2011
Activity information:
Blocks received:                        1
Blocks processed:                       1
RETURN - show remaining, U - continue uninterrupted:


Видим, что статус репликации получил значение «Normal Processing». В тоже время мониторинг сервера репликации должен в поле «Server is» показать значение «In Normal Processing».

OpenEdge Replication Monitor                  Page 1
Database:  /home/valeriy/replic/source/sports
Database is enabled as OpenEdge Replication:  Source
Server is:                                  In Normal Processing
Number of configured agents:                1
Delay Interval (current / min / max):       500 / 5 / 500
Recovery information:
State:                                  No recovery being performed
Agents needing recovery:                0
Agents connected:                       0
Agents in synchronization:              0
Transition information:
Type:                                   Manual
RETURN - repeat, U - continue uninterrupted, Q - quit:


Что и следовало доказать. Мы получили работающую репликацию.






Главная |  Статьи |  Книги |  Гостевая |  Ссылки |  От автора |  Download ProKb


������ ᠩ� pr Online ProKB Blogger Welcome to Russian Progress Users Group at Facebook Welcome to Russian Progress Users Group at LinkedIn
© 2009 - 2011 Все права на материалы, находящиеся на сайте www.openedge.ru, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.