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

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

Для выполнения нашего примера, нам сначала надо активировать в базе данных механизм 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 . 
a .
a .

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

$ 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 10000 
-pica 10000 
-bibufs 30 
-aibufs 30 
-aistall 
-aiarcdir ./ai 
-aiarcdircreate 
-aiarcinterval 300 
-bithold 75000 
-bistall 
-DBService replserv

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

$ proserve sports -pf sports.pf 
OpenEdge Release 11.x 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 10000 
-bibufs 50 
-pica 10000 
-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:

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

В следующей статья я расскажу как создать одновременно две базы Target и как добавить вторую Target к существующей конфигурации.