Синхронизация:Механизм односторонней синхронизации — различия между версиями

Материал из wiki.standart-n.ru
Перейти к: навигация, поиск
(Отправка недостающих данных G$DATACONTROL:)
м (Алгоритм отправки данных по синхронизации:)
 
Строка 10: Строка 10:
 
  5. Клиент получает ответ от скриптов.  
 
  5. Клиент получает ответ от скриптов.  
 
     Из каждой таблицы КБ синхронизации выгружает все записи, находящиеся между максимальным packet ГБ и своим максимальным packet.  
 
     Из каждой таблицы КБ синхронизации выгружает все записи, находящиеся между максимальным packet ГБ и своим максимальным packet.  
     Например, для TBALE_1 максимальный packet=200. В таком  случая в выгрузку попадут все записи, где packet находится в диапазоне 100 - 200.
+
     Например, для TABLE_1 максимальный packet=200. В таком  случая в выгрузку попадут все записи, где packet находится в диапазоне 100 - 200.
 
  6. Клиент архивирует файл с выгруженными данными и отправляет его скриптам.
 
  6. Клиент архивирует файл с выгруженными данными и отправляет его скриптам.
 
  7. Скрипты принимают, анализируют пришедшие данные и загружают данные в ГБ.
 
  7. Скрипты принимают, анализируют пришедшие данные и загружают данные в ГБ.
  8. Переходим к п.1.  
+
  8. Переходим к п.1.
  
 
==Для односторонней синхронизации должны быть соблюдены пункты:==
 
==Для односторонней синхронизации должны быть соблюдены пункты:==

Текущая версия на 10:18, 20 января 2018

Используемые сокращения

ГБ - Глобальная база
КБ - Клиентская база

Алгоритм отправки данных по синхронизации:

1. Клиент отправляет запрос скриптам: «Какие таблицы нужно отправить серверу, и какая последняя запись уже загружена на сервере».
2. Скрипты принимают запрос.
3. Скрипты подключаются к ГБ и готовят ответ, например, TABLE_1 максимальное значение поля packet=100.
4. Скрипты отправляет ответ клиенту в заархивированном файле.
5. Клиент получает ответ от скриптов. 
   Из каждой таблицы КБ синхронизации выгружает все записи, находящиеся между максимальным packet ГБ и своим максимальным packet. 
   Например, для TABLE_1 максимальный packet=200. В таком  случая в выгрузку попадут все записи, где packet находится в диапазоне 100 - 200.
6. Клиент архивирует файл с выгруженными данными и отправляет его скриптам.
7. Скрипты принимают, анализируют пришедшие данные и загружают данные в ГБ.
8. Переходим к п.1.

Для односторонней синхронизации должны быть соблюдены пункты:

1. В каждой таблице синхронизации в КБ обязательно должно присутствовать поле packet.
2. В каждой таблице синхронизации в ГБ обязательно должно быть поле G$PROFILE_ID, GLOBAL_ID и первичный составной ключ ID,G$PROFILE_ID. 
   G$PROFILE_ID заполняется автоматически скриптами. GLOBAL_ID должен заполнятся   триггерами, при необходимости создать генератор.
3. В ГБ в таблице может не быть полей, которые мы указали в исключениях в G$PROFILES.
4. В ГБ в таблице могут быть поля, которых нет в КБ. Т.е. структура таблицы ГБ шире структуры таблицы КБ.

Возможные проблемы:

1. Если по каким то причинам данных в ГБ нет, а в КБ есть, то достаточно сделать update необходимых записей. 
   Например, update table_1 set packet=0 where insertdt>’01.03.2015’
2. Если подобные проблемы повторяются, желательно снять галочку «Игнорировать активные транзакции» в настройках Клиента.
3. Не уходит пакет с подготовленными данными. 
 a. Возможно, размер собранного пакета достаточно большой и скрипты не могут его себе загрузить. 
    В данном случае нужно поставить ограничение размера исходящего пакета для односторонней синхронизации. 
    Можно поставить, например, 2 мб. Имейте в виду, что данное ограничение действует на размер выгрузки каждой из таблиц в отдельности в несжатом виде. 
    Т.е. размер отправляемого пакета может иметь размеры более, чем указанные в  настройке.
 b. Проверить доступность URL из настроек в браузере. Таким образом мы можем определить доступны ли скрипты. Если они доступны, то выйдет сообщение “error no input data”
 c. Если URL не доступен нужно проверить включен ли wamp server. 
    Для этого нужно подключиться на компьютер, где лежат скрипты, и запустить wamp server. 
    Проверить автоматическое включение wamp после перезагрузки компьютера, если не настроено, нужно настроить.
 d. Если wamp server включен, но URL все равно не отвечает, значит нужно смотреть настройки PHP (php.ini) и Apache (httpd.conf). 
    Открываем файл настроек ищем «limit» и «max». Смотрим, что нигде нет ограничений или они не очень жесткие. Сохраняем и перезапускаем все сервисы wamp. 
 e. Если но URL все равно не отвечает, скорее всего, блокируют работу антивирусные программы или брандмауэр. 
4. Данные на сервер ушли, но не загрузились и логах клиента появились ошибки. 
   В таком случае, смотрим какой именно запрос у сервер не получилось выполнить. 
   Пытаемся его выполнить сами на ГБ, при необходимости меняем структуру таблиц.

Удаление данных Z$SYNCDELETED:

Для удаления данных в ГБ при удалении из КБ используется таблица Z$SYNDELETED. 
Данные в этой таблице заполняются триггерами на удаление для синхронизируемых таблиц. 
Данная таблица так же должна быть указана в списке синхронизируемых таблиц (G$PROFILES .DATA)

Отправка недостающих данных G$DATACONTROL:

В случае односторонней синхронизации существует механизм «до-отправки» недостающих данных. 
Эта функция полезна в случае пропуска загрузки пакетов на сервере. 
В ГБ в IBExperte в G$DATACONTROL добавляем строки с именем таблицы, кодом профиля и status=0. 
Остальные поля заполнятся автоматически или не нуждаются в заполнении. 
При следующей синхронизации DTClient сравнит таблицы на ГБ и КБ и до-отправить недостающие данные на сервере. 
Внимание!!! Если на сервере данные лишние, то они не удалятся.