В стандартном варианте для создания 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 к существующей конфигурации.