мета-данные страницы
  •  

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
репликация [14.01.2020 06:31]
Анисютин
репликация [05.07.2020 05:50]
Строка 1: Строка 1:
-====== Репликация ====== 
  
-**Репликация** – это процесс обмена данными между разными базами данных с целью синхронизации изменений в этих базах данных.\\ ​ 
-В настоящее время используется схема, при которой базы данных различных подразделений полностью идентичны по содержимому:​ и по данным и по структуре.\\ ​ 
- 
-===== Обозначения ===== 
- 
-**ЦДБ** - центральная база данных\\ ​ 
-**БДП** - базы данных подразделений\\ ​ 
- 
-===== Модель репликации ===== 
-  
-Репликационная структура представляет собой **звезду**:​\\  ​ 
-  - все БДП синхронизируются с ЦДБ,\\ 
-  - непосредственно между собой БДП данными не обмениваются.\\ ​ 
- 
-[[:​настройка_репликации|Настройка репликации]]\\ ​ 
-<ifauth @programmers> ​ 
-[[develop:​Реализация репликации]]\\ 
-</​ifauth> ​ 
- 
-[[:​обновление_программ]]\\ ​ 
-<ifauth @user> ​ 
-[[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 &​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>​ 
-</​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>​