Математико-механический факультет (стр. 3 из 3)
Если данные должны быть синхронизированы немедленно после изменений, то такую репликацию будем называть репликация реального времени. Если же процесс репликации запускается по какому-либо событию во времени или по отмашке администратора БД, то такой вид репликации назовем отложенная репликация.
Репликация предоставляет следующие возможности:
· автоматизированное и надежное перемещение изменений данных из одной системы в другую (позволяет автоматически вносить изменения при появлении их в источнике);
· создание идентичных копий в двух системах (например, поддержка второй копии данных для их восстановления);
· копирование подмножества данных из одной системы во многие (например, с целью синхронизации информации в разных системах). Такой вид репликации называется распределением данных;
· копирование выбранных данных из многих источников в один (например, чтобы объединить информацию в информационное хранилище). Такой вид репликации называется консолидацией данных.
C учетом введенных определений необходимо установить, какой тип репликации наиболее соответствует поставленной задаче.
1. В таких системах, как «1С бухгалтерия», изменения могут происходить на разных копиях БД. Поэтому репликация требуется мульти-направленная.
2. Так как целью работы является контроль данных в системах-справочниках (в которых к данным постоянно происходят обращения), то необходимо проводить репликацию в реальном времени, не исключая, однако, возможности отложенной репликации.
3. Чтобы не перегружать сервера, выбираем асинхронную репликацию.
4. Предположительно, объем обрабатываемых данных может быть велик, и эти данные нужно обновлять постоянно. При таких условиях удобно использовать репликацию транзакций.
Сформируем модель приложения:
Так как базы будут разнородные, но с идентичными схемами, контролировать придется только изменения данных. Причем синхронизировать будем отдельные таблицы. Следовательно, приложение должно иметь инструмент-сервис, регулярно выполняющий синхронизацию, и инструмент для отложенной синхронизации, который должен включать возможности выставления настроек подключения (host, port, username, password, database, table) для каждой базы данных. В каждой синхронизируемой базе должен быть лог транзакций (таблица, в которой при помощи триггерных процедур фиксируются все изменения).
3. Описание приложения «SyncManager»
Алгоритм работы приложения:
1. Administrative tool
Запускается вначале. Пользователь выставляет все необходимые настройки соединения с базами, данные которых необходимо синхронизировать:
· Host
· Port
· Username
· Password
· Database
· Table
Настройки записываются в файл. На их основе автоматически формируются строки соединения, скрипты для создания триггеров. При помощи триггеров информация будет заноситься в логи транзакций таким образом, что в логе будет храниться уже сформированная команда для выполнения в той БД, в которой изменения еще не было. Так как базы разнородные, характеристики у них тоже разные. Соединение же устанавливается для всех по одной схеме, идентично создаются и триггеры, но с теми отличиями, которые определяются при выборе базы данных, участвующей в синхронизации.
Отсюда происходит непосредственно запуск и остановка сервиса. Если по какой-то причине необходимо изменить настройки сервиса, то его можно остановить, изменить конфигурацию и запустить вновь. Также приложение позволяет осуществить синхронизация «по требовонию».
2. Synchronizing Service
Сервис регулярно (через довольно малые промежутки времени) обращается к логам транзакций синхронизируемых баз. Если в них зарегистрированы новые изменения, то сервис запускает выполнение команды из лога. При этом происходит проверка, не выполнялась ли уже данная команда, и, только исключив возможность дублирования данных, команда выполняется. Команды хранятся в логах в неком общем виде, и в зависимости от синхронизируемых баз данных, преобразуются в соответствии с диалектом SQL, приемлемым для конкретной БД.
Трудности, с которыми пришлось столкнуться в ходе работы:
1) Отслеживание добавления/изменения/удаления данных в каждой копии данных. Если добавление/удаление можно достаточно надежно синхронизировать, то при модификации имеющихся данных возникает проблема "первородности" изменений, т.е. принятие решения о том, которое из изменений какого поля является наиболее объективным.
Есть такой вариант обработки конфликтов: в логе транзакций фиксировать время изменения данных и считать более поздние изменения приоритетными. При попытке удаления несуществующей записи будет выдаваться сообщение о ее отсутствии, транзакция – откатываться.
2) Объективная модификация каких-либо счетчиков, например, счетчиков отгружаемой продукции. Поясняю - если в обеих копиях данных был организован декремент счетчика продукции на 1, при неизменности других полей записи, то в синхронизированной записи должен быть произведен окончательный декремент уже на 2.
3) Проблема возрастания сложности синхронизации между тремя и более копиями данных.
4) Необходимо исключать дублирование данных по логам.
5) Разные базы данных поддерживают разные диалекты языка SQL, что требует индивидуального подхода при формировании скриптов триггеров и запросов к синхронизируемым базам данных. Также это препятствует расширению системы на дополнительные виды баз данных, но, в силу относительной универсальности приложения, не исключает такой возможности.
4. Практическая реализация приложения «SyncManager»
4.1 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 Останавливается сервис синхронизации
Приложение выполнено на основе технологии Windows Service (Microsoft Visual Studio .Net 2005)
Это основной элемент приложения.
· Получает все настройки файла
· Регулярно обращается к базам данных, анализирует логи транзакций
· Выполняет команды новых изменений в тех таблицах, где изменений еще не было
· Заносит информацию обо всех действиях в лог сервиса