мета-данные страницы
Различия
Здесь показаны различия между двумя версиями данной страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
репликация [13.01.2020 11:02] Анисютин ↷ Операцией перемещения обновлены ссылки |
репликация [05.07.2020 05:50] |
||
---|---|---|---|
Строка 1: | Строка 1: | ||
- | ====== Репликация ====== | ||
- | **Репликация** – это процесс обмена данными между разными базами данных с целью синхронизации изменений в этих базах данных.\\ | ||
- | В настоящее время используется схема, при которой базы данных различных подразделений полностью идентичны по содержимому: и по данным и по структуре.\\ | ||
- | |||
- | ===== Обозначения ===== | ||
- | |||
- | **ЦДБ** - центральная база данных\\ | ||
- | **БДП** - базы данных подразделений\\ | ||
- | |||
- | ===== Модель репликации ===== | ||
- | |||
- | Репликационная структура представляет собой **звезду**:\\ | ||
- | - все БДП синхронизируются с ЦДБ,\\ | ||
- | - непосредственно между собой БДП данными не обмениваются.\\ | ||
- | |||
- | [[настройка_репликации|Настройка репликации]]\\ | ||
- | |||
- | <ifauth @programmers> | ||
- | [[develop:Реализация репликации]]\\ | ||
- | </ifauth> | ||
- | |||
- | [[:обновление_программ]]\\ | ||
- | <ifauth @user> | ||
- | [[internal:Автотестирование остановки репликации]]\\ | ||
- | [[internal:Обязательные поля для агента]]\\ | ||
- | </ifauth> | ||
- | |||
- | |||
- | Временно | ||
- | [[develop:Реализация системы репликации]]\\ | ||
- | |||
- | ====== Репликация ====== | ||
- | Репликация – это процесс обмена данными между разными базами данных с целью синхронизации изменений в этих базах данных. В настоящее время мы используем схему, при которой базы данных различных подразделений полностью идентичны по содержимому: и по данным и по структуре. | ||
- | |||
- | ===== Краткая схема работы репликации ===== | ||
- | |||
- | Наша репликационная структура представляет собой звезду: есть центральная база данных (ЦДБ), главная и есть базы данных подразделений (БДП). БДП обмениваются информацией только с ЦДБ, с другими базами подразделений обмена на идет. | ||
- | |||
- | У каждого подразделения есть номер DEP_ID (от 1 до 99, не больше 2х знаков длиной). В таблицах, которые синхронизируются по репликации: | ||
- | |||
- | - Первичный ключ генерируется особым образом, к инкрементальному номеру добавляется префикс подразделения вида 102, где 1- константа, 02-номер подразделения, выравненный до ширины 2 знака. Например, в таблицу SCLADS добавляется 3 склада, первый будет иметь ID=1021, второй – ID=1022, третий – ID=1023. В примере число после префикса 102 – это инкрементальное число в рамках текущего подразделения. Инкрементальные числа могут повторяться в разных подразделениях, префикс подразделения добавляется для только, чтобы ID был уникальным среди всех баз данных клиента. | ||
- | - Добавляются специальные триггеры, которые при любых изменениях данных в таблицах (после вставки данных, после изменения и после удаления) добавляют запись об этом изменении в лог репликации - таблицу 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: | ||
- | <code> | ||
- | <?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 "Пресня"" 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> | ||
- | </code> | ||
- | |||
- | У файла есть заголовок (первая строка, оканчивающаяся на </props>), в котором записывается какое подразделение сформировало файл (DEP_ID=”1”) и порядковый номер файла (REPL_ID=”3679”). При приеме репликации ReplIn.exe проверяет порядковый номер файла и если он не больше предыдущего загруженного на единицу, то возникает ошибка. Файлы должны загружаться один за другим последовательно. | ||
- | |||
- | В каждой строке файла записывается: | ||
- | - что за изменение было с записью таблицы ( <i – это вставка, <u – это изменение, <d – это удаление), | ||
- | - порядковый номер изменения в таблице лога репликации MST_META_CHANGES (SEQ_ID=”1231”), | ||
- | - имя таблицы (T_NAME=”SCLADS”) | ||
- | - данные из этой таблицы с соответствующими именами полей (NAME="1 Колумб", SCLAD_DEF_FIRM=”15”) | ||
- | - имена полей могут содержать суффикс "_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. | ||
- | |||
- | <ifauth @user> | ||
- | После окончания своей работы ReplIn.exe и ReplOut.exe отправляют отчеты о своей работе на наш сервер. Отчет о работе репликации доступен на вкладке ProjectsControl / Сервисы / Репликация. | ||
- | </ifauth> | ||
- | |||
- | ===== Параметры запуска командной строки ===== | ||
- | 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 вида | ||
- | <code> | ||
- | 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. | ||
- | </code> |