Репликация

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

Наша репликационная структура представляет собой звезду: есть центральная база данных (ЦДБ), главная и есть базы данных подразделений (БДП). БДП обмениваются информацией только с ЦДБ, с другими базами подразделений обмена на идет.

У каждого подразделения есть номер DEP_ID (от 1 до 99, не больше 2х знаков длиной). В таблицах, которые синхронизируются по репликации:

1. Первичный ключ генерируется особым образом, к инкрементальному номеру добавляется префикс подразделения вида 102, где 1- константа, 02-номер подразделения, выравненный до ширины 2 знака. Например, в таблицу SCLADS добавляется 3 склада, первый будет иметь ID=1021, второй – ID=1022, третий – ID=1023. В примере число после префикса 102 – это инкрементальное число в рамках текущего подразделения. Инкрементальные числа могут повторяться в разных подразделениях, префикс подразделения добавляется для только, чтобы ID был уникальным среди всех баз данных клиента.
2. Добавляются специальные триггеры, которые при любых изменениях данных в таблицах (после вставки данных, после изменения и после удаления) добавляют запись об этом изменении в лог репликации - таблицу MST_META_CHANGES. Например, для таблицы SCLADS есть триггеры SCLADS_AI (срабатывает после INSERT), SCLADS_AU (срабатывает после UPDATE) и SCLADS_AD (срабатывает после DELETE). При изменениях в таблицу MST_META_CHANGES добавляются данные:

TABLE_NAME=’SCLADS’
ID=SCLADS.ID
OPERATION=1(INSERT),2(UPDATE),3(DELETE)
DATE_CHANGE=дата изменения
TIME_CHANGE=время изменения

Репликация (ReplOut.exe) при отправке выбирает все записи из лога репликации, которые еще не были отправлены и формирует файлы репликации с данными из таблиц. Файлы репликации имеют структуру XML, записываются с расширением xmr и перед отправкой запаковываются в zip архив с расширением файла xmz. В имени файла записывается из какого подразделения идет выгрузка, в какое подразделение, текущая дата и порядковый номер файла за сегодня. Файлы складываются в соответствующие папки. Например:

Agbis\Repl\out1to10\repl1to10.2011.01.31_1.xmr
Agbis\Repl\out1to10\repl1to10.2011.01.31_1.xmz
Agbis\Repl\out1to10\repl1to10.2011.01.31_2.xmr
Agbis\Repl\out1to10\repl1to10.2011.01.31_2.xmz

Пример содержимого из файла xmr:

<?xml version="1.0" encoding="UTF-8"?><AgbisReplFile><props DEP_ID="1" REPL_ID="3679"></props>
<i SEQ_ID=”1231” T_NAME="SCLADS" ID="1021" NAME="1 Колумб" DEP_ID="0" DEP_SRC_ID="0" USE_IN_KASSA="1" LAST_DEP_ID="0" SCLAD_DEF_FIRM="15"></i>
<u SEQ_ID=”1232” T_NAME="SCLADS" ID="1022" NAME="2 Большая Грузинская" DEP_ID="0" DEP_SRC_ID="0" USE_IN_KASSA_IS_NULL="" LAST_DEP_ID="0" SCLAD_DEF_FIRM="15" SCLAD_PHONE="Ждем Вас с 10 до 22 часов"></u>
<u SEQ_ID=”1233” T_NAME="SCLADS" ID="1023" NAME="3 &quot;Пресня&quot;" DEP_ID="0" DEP_SRC_ID="0" USE_IN_KASSA="1" LAST_DEP_ID="0" SCLAD_DEF_FIRM="11" SCLAD_PHONE="Ждем Вас с 0 до 22 часов"></u>
<d SEQ_ID=”1234” T_NAME="SCLADS" ID="1024"></u>
</AgbisReplFile>

У файла есть заголовок (первая строка, оканчивающаяся на </props>), в котором записывается какое подразделение сформировало файл (DEP_ID=”1”) и порядковый номер файла (REPL_ID=”3679”). При приеме репликации ReplIn.exe проверяет порядковый номер файла и если он не больше предыдущего загруженного на единицу, то возникает ошибка. Файлы должны загружаться один за другим последовательно.

В каждой строке файла записывается:

1. что за изменение было с записью таблицы ( <i – это вставка, <u – это изменение, <d – это удаление),
2. порядковый номер изменения в таблице лога репликации MST_META_CHANGES (SEQ_ID=”1231”),
3. имя таблицы (T_NAME=”SCLADS”)
4. данные из этой таблицы с соответствующими именами полей (NAME=«1 Колумб», SCLAD_DEF_FIRM=”15”)
5. имена полей могут содержать суффикс «_IS_NULL» (например USE_IN_KASSA_IS_NULL=«»), это означает, что поле содержит NULL (в примере поле USE_IN_KASSA is null в таблице базы данных).

Информация об отправленных файлах записывается в таблицу MST_META_REPL_FILES, в ней фиксируется что за файл (FILE_NAME), для какого подразделения (DEP_ID), с каким номером файла (REPL_ID), с какой последней записью из лога репликации (SEQ_ID) и когда был создан (DATE_OUT, TIME_OUT). После отправки проставляется признак что файл отправлен (поле WAS_SENDED).

Файлы репликации отправляются на WebDAV или FTP сервер. FTP – это старая технология, сейчас преимущественно используется WebDAV, новый протокол меньше блокируется файрволами, потому что работает по стандартному порту веб браузеров.

Противоположное подразделение периодически проверяет наличие новых файлов на WebDAV, закачивает их к себе, проверяет корректность номера и пытается загрузить данные из файла репликации. После успешной загрузки запись о файле добавляется в таблицу MST_META_REPL_FILES, в ней фиксируется что за файл (FILE_NAME), от какого подразделения (DEP_ID), с каким номером файла (REPL_ID), с какой последней записью из лога репликации (SEQ_ID) и когда был загружен (DATE_IN, TIME_IN).

Весь процесс обмена файлами репликации происходит в фоновом режиме, незаметном работающему за компьютером пользователю. Обычно настраиваются специальные задачи в планировщике xStarter, которые периодически (раз в 20 минут) и при запуске компьютера сначала запускают ReplIn.exe для приема данных, потом ReplOut.exe для отправки данных.

Для анализа работы репликации в виду ее «незаметности» нужно использовать логи репликации. Файлы логов сохраняются в папке Agbis\Repl\Logs отдельно для ReplIn и ReplOut и имеют в своем названии дату. Файлы логов хранятся 10 дней, старые файлы автоматически удаляются исполняемыми файлами ReplIn.exe и ReplOut.exe.

ReplIn.exe «alias_name» /RUN /SHOW /NOWEBUPDATE /NOUPLMAN /ONLYSUPPORT

Где Alias_name - псевдоним БД, можно посмотреть в файле agbis.xml /RUN - запустить прием или отправку данных сразу после запуска /SHOW - отобразить прогресс приема или отправки данных /NOWEBUPDATE - не проверять при запуске на наличие обновления программы на сайте agbis.ru /NOUPLMAN - не проверять при запуске на наличие новой версии исполняемого .exe в UplMan. При загрузке новой версии с FTP или WebDAV этот ключ не анализируется и происходит попытка загрузить обновление. /SKIP_WAIT_FILES - не проверять файл wait_files.xml и соответственно не формировать пропущенные файлы. /ONLYSUPPORT - выполнять только операции обслуживания базы данных и запуск автообновления

Полезным будет знать о ключе /FILE #file_name# для ReplOut.exe, где #file_name# - имя файла в базе данных. Например, не выгрузился какой-либо файл при создании out файлов на сервер. Используя данный . Использование данного ключа возможно только для ручного запуска ReplOut.exe (Пример: C:\Agbis\Repl\ReplOut.exe /FILE C:\Agbis\Repl\Out6to1\REPL1TO6.2018.11.23_2.XMR)

/EXT_LOGS - ключ, при котором производится запись дополнительной информации в лог файл в ReplIn - по каким данным не были найдены строки, информация по имени таблицы, Foreign Key вида

02.04.2014 08:38:33:765: Add to waits while Insert Tbl=ADDON_ORDER_SERVICES, ID=1046222729 because message InsertQuery:
Violation of FOREIGN KEY constraint "".
Violation of FOREIGN KEY constraint "FK_ADDON_ORDER_SERVICES" on table "ADDON_ORDER_SERVICES".
Foreign key reference targe t does not exist.