Описание приложения «SyncManager»

 

Алгоритм работы приложения:

 

1. Administrative tool

 

Запускается вначале. Пользователь выставляет все необходимые настройки соединения с базами, данные которых необходимо синхронизировать:

 

· Host

· Port

· Username

· Password

· Database

· Table

 

Настройки записываются в файл. На их основе автоматически формируются строки соединения, скрипты для создания триггеров. При помощи триггеров информация будет заноситься в логи транзакций таким образом, что в логе будет храниться уже сформированная команда для выполнения в той БД, в которой изменения еще не было. Так как базы разнородные, характеристики у них тоже разные. Соединение же устанавливается для всех по одной схеме, идентично создаются и триггеры, но с теми отличиями, которые определяются при выборе базы данных, участвующей в синхронизации.

Отсюда происходит непосредственно запуск и остановка сервиса. Если по какой-то причине необходимо изменить настройки сервиса, то его можно остановить, изменить конфигурацию и запустить вновь. Также приложение позволяет осуществить синхронизация «по требовонию».

 

 

2. Synchronizing Service

 

Сервис регулярно (через довольно малые промежутки времени) обращается к логам транзакций синхронизируемых баз. Если в них зарегистрированы новые изменения, то сервис запускает выполнение команды из лога. При этом происходит проверка, не выполнялась ли уже данная команда, и, только исключив возможность дублирования данных, команда выполняется. Команды хранятся в логах в неком общем виде, и в зависимости от синхронизируемых баз данных, преобразуются в соответствии с диалектом SQL, приемлемым для конкретной БД.

 

 

Трудности, с которыми пришлось столкнуться в ходе работы:

 

1) Отслеживание добавления/изменения/удаления данных в каждой копии данных. Если добавление/удаление можно достаточно надежно синхронизировать, то при модификации имеющихся данных возникает проблема "первородности" изменений, т.е. принятие решения о том, которое из изменений какого поля является наиболее объективным.

 

Есть такой вариант обработки конфликтов: в логе транзакций фиксировать время изменения данных и считать более поздние изменения приоритетными. При попытке удаления несуществующей записи будет выдаваться сообщение о ее отсутствии, транзакция – откатываться.

 

2) Объективная модификация каких-либо счетчиков, например, счетчиков отгружаемой продукции. Поясняю - если в обеих копиях данных был организован декремент счетчика продукции на 1, при неизменности других полей записи, то в синхронизированной записи должен быть произведен окончательный декремент уже на 2.

 

3) Проблема возрастания сложности синхронизации между тремя и более копиями данных.

 

4) Необходимо исключать дублирование данных по логам.

 

5) Разные базы данных поддерживают разные диалекты языка SQL, что требует индивидуального подхода при формировании скриптов триггеров и запросов к синхронизируемым базам данных. Также это препятствует расширению системы на дополнительные виды баз данных, но, в силу относительной универсальности приложения, не исключает такой возможности.

 

Практическая реализация приложения «SyncManager»

 

Administrative Tool

Приложение выполнено на основе технологии Windows Forms (Microsoft Visual Studio .Net 2005)

 

Приложение выполняет следующие действия:

· Считывает настройки соединения, названия синхронизируемых таблиц

· Заносит конфигурационные данные в файл в формате XML

· Определяет структуру таблиц

· Определяет первичный ключ

· Создает таблицу, в которой будут фиксироваться все изменения

· Создает триггеры на действия над данными

· Запускает/останавливает сервис синхронизации

· Запускает единовременную синхронизацию

 

Настройка конфигурации

 

 

Для установления соединения к разным базам требуется разная информация. При первом запуске форма имеет общий вид. В зависимости от типа БД, пользователь получает возможность указать необходимые характеристики соединения.

 

 

· По нажатию кнопки «ОК» происходят следующие действия (для каждой базы данных):

o Сериализация внесенных в форму данных

o Считывание данных (тип базы данных, имя таблицы и характеристики соединения) из файла настроек

o Формирование строк соединения

o Генерация триггеров к данной таблице

o Создание таблиц изменений (логов транзакций)

· По нажатию кнопки «Start service» происходит запускается сервиса синхронизации

 

Рассмотрим подробнее процесс создания триггеров. Три́ггер (англ. trigger) — это хранимая процедура особого типа, исполнение которой обусловлено наступлением определенного события. В данном случае при помощи специальных методов триггеры создаются на события внесения изменений в таблицы. Они имеют общий вид:

 

BEGIN

INSERT INTO _changes (cmd)

VALUES (CONCAT('INSERT INTO table (id, field1, field2, field3)

VALUES (', QUOTE(new.id), ', ', QUOTE(new.field1), ', ', QUOTE(new.field2), ', ', QUOTE(new.field3),')'));

END

 

_changes – лог транзакций базы. Имеет следующую структуру:

 

Change_id	command
1	‘INSERT INTO table VALUES (val1, val2, val3)’
2	‘DELETE FROM table WHERE id = val1’
3	‘UPDATE table SET field1 = val1 WHERE id = val2’

 

В поле command записывается та команда, которая выполнилась в одной базе и должна выполниться в другой для синхронизации данных.

Сервис будет регулярно обращаться к этой таблице и при наличии новых записей, выполнять команду из поля command.

 

· По нажатию кнопки «Stop service» происходят следующие действия (для каждой базы данных).

o Закрывается соединение с базой данных

o Останавливается сервис синхронизации

 

Synchronizing Service

 

Приложение выполнено на основе технологии Windows Service (Microsoft Visual Studio .Net 2005)

 

Это основной элемент приложения.

 

· Получает все настройки файла

· Регулярно обращается к базам данных, анализирует логи транзакций

· Выполняет команды новых изменений в тех таблицах, где изменений еще не было

· Заносит информацию обо всех действиях в лог сервиса