Курсовая работа: Механизмы репликаций в распределенных базах
6. Гибкая процедура разрешения конфликтов - репликация позволяет отслеживать конфликты (под конфликтом понимаем состояние, когда 2 или более подписчиков содержат транзакции по изменению одного и того же объекта) по основным типам объектов (справочники, документы), правильно их разрешать, легировать и нотифицировать.
Важность и необходимость процесса репликации лучше всего иллюстрируются примером. Представим себе крупную туристическую фирму, имеющую головной офис и несколько филиалов, расположенных в гостиницах. И в головном офисе, и в филиалах работает программа формирования и учета оказываемых услуг, причем и там, и там постоянно происходят обновления, которые должны быть доступны на всех рабочих местах, в реальном времени (выставленные счета, специальные предложения, изменения в цене и т. д.). Как в этом случае обновлять базы данных?
При решении проблемы простым путём менеджер в филиале составляет документ, отражающий изменения, посылает его службе поддержки работы базы, а там вносят изменения в базу на основе этого документа. Это не решение - это выход из положения, абсолютно не оправдывающий себя при большом объеме изменений. В перспективе же это создание трудностей для последующей героической борьбы с ними.
Почти идеальное с технической точки зрения решение: соединить головной офис и филиалы скоростными каналами связи и сделать базу данных единой для программы учета. Этот путь возможен только тогда, когда все филиалы имеют постоянный доступ в Интернет по локальной сети или выделенной линии. Что происходит в случае обрыва соединения? Очевидно, что бесперебойной работы в этом решении не добиться. Кроме того, есть психологический аспект, преодолеть который, скорее всего, не удастся: руководство компании будет очень испугано появлением принципиальной возможности зайти из Интернета в "святая святых" - базу данных программы учета. И вряд ли рассказы о межсетевых экранах и прочих средствах безопасности его успокоят.
Применение ПК "Репликация информационных баз" полностью выполняет требование "в реальном времени". Т.е. оператор филиала создаёт / изменяет объект репликации (справочник или документ) и все остальные операторы могут тут же увидеть эту информацию.
В случае обрыва связи информационная база работает в автономном режиме, и как только соединение будет восстановлено, - данные будут синхронизированы.
Данное решение не требует участия человека в процессе обмена (не надо выгружать/загружать файлы и т.д.) и не требует вносить изменения в конфигурацию.
Передаётся только та информация, которая необходима, таким образом, трафик обмена незначителен. Репликация также может решить проблему резервного копирования и проблему архивации (когда база разбивается на текущую и архив).
2.1 О репликации базы данных
Современные информационные системы предъявляют достаточно высокие требования к скорости отработки информации при условии одновременной работы большого количества клиентов. Кроме того, развиваясь, такие системы должны легко масштабироваться без ущерба для скоростных характеристик системы.
Один из способов удовлетворения этой потребности - создание распределенной базы данных БД, поддерживающей механизм асинхронной репликации данных. В этом случае вместо одной БД, с которой должны работать все клиенты информационной системы, создается несколько одинаковых серверов БД на разных машинах и/или узлах сети. Клиенты имеют доступ к некоторому распределяющему устройству (реализованному аппаратно или программным методом), которое при подключении нового клиента оценивает загрузку каждого сервера БД и направляет клиента к наименее загруженному серверу, с которым он (клиент) и будет работать до отсоединения.
Вопросы построения распределенной базы данных единой информационной системы возникают и при развитии компании, когда создаются удаленные филиалы, магазины и склады. Каждая удаленная информационная система с целью повышения устойчивости должна работать самостоятельно, периодически отправляя в Центральный офис консолидированную информацию. Для исключения человеческого фактора в вопросе периодической синхронизации информации базы данных должны быть включены в общую систему репликации.
Репликация данных между серверами баз данных может выполняться с помощью встроенных средств СУБД или может быть реализована в рамках бизнес - логики приложений. Репликация с помощью встроенных средств СУБД предполагает наличие надежных каналов связи. Пропускная способность этих каналов должна быть достаточно высокой, чтобы успевать передавать всю реплицируемую информацию в realtime-режиме. Процесс репликации в СУБД основан на понятиях "издатель", "подписчик", "статья". Настройка репликации сводится к установке отношений между издателем и подписчиком. Недостатком данной репликации является однонаправленность. Т.е. статья (фактически это таблица) может передаваться от издателя подписчику. При этом подписчик не может ее изменять.
Реализации процессов репликации на уровне бизнес-логики значительно усложняет жизнь разработчику, но позволяет значительно оптимизировать сам процесс передачи информации. Проблема репликации информации представляет собой довольно нетривиальную задачу с весьма неоднозначным решением. Приступая к решению задачи репликации данных, необходимо принимать во внимание, что придется столкнуться с конфликтами реплицируемых данных, которых для баз данных, работающих в единой сети прямого коннекта к серверу базы данных, не возникает в принципе. Особенно сложен переход от единой базы к распределенной, когда приходится подстраивать алгоритм репликации под уже существующую структуру работающей БД. При разработке новой информационной системы необходимо учитывать технологические нюансы будущей распределенной базы данных.
2.2 Механизмы репликации данных
Для поддержки целостности распределенной БД в СУБД ЛИНТЕР используется механизм асинхронного тиражирования (далее по тексту - репликации) транзакций.
Суть механизма асинхронного тиражирования состоит в том, что обработка данных выполняется локально, а распределенные данные копируются на тот сервер, где они должны использоваться. При таком методе поддержки логической целостности распределенной БД имеет место некоторая рассинхронизация состояния локальных БД во времени, т.е. изменение состояния одной локальной базы данных отстает от изменения другой локальной базы данных во времени.
Если один из серверов системы, требующих обновления тиражируемых данных, выходит из строя, то система продолжает работать с остальными, при этом обновление данных на сервере после его ремонта произойдет автоматически, т.е. ошибка на одном узле глобальной сети не повлияет на работу остальных узлов.
Механизм асинхронного тиражирования транзакций гарантирует доставку измененных данных на вторичные серверы непосредственно после завершения транзакции, если сервер доступен, или сразу после подключения сервера к сети. Такой подход предполагает хранение дублирующей информации в различных узлах сети и может обеспечить, по сравнению с другими подходами к репликации, снижение трафика, улучшение времени ответа системы, а также позволяет оптимизировать нагрузку на серверы.
Асинхронная репликация, в отличие от двухфазной синхронизации, не обеспечивает полной синхронности информации на всех серверах в любой момент времени. Синхронизация происходит через некоторый, обычно небольшой, интервал времени, величина которого определяется быстродействием соответствующего канала связи. Для большинства задач кратковременное наличие устаревших данных в удаленных узлах вполне допустимо.
Вместе с тем, асинхронная репликация транзакций принципиально обеспечивает целостность данных, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.
2.3 Назначение репликации данных
Многие современные информационные системы предъявляют достаточно высокие требования к скорости отработки поисковых запросов при условии одновременной работы большого количества клиентов. Кроме того, развиваясь, такие системы должны легко масштабироваться без ущерба для скоростных характеристик системы.
Один из способов удовлетворения этой потребности - создание распределенной базы данных (БД), поддерживающей механизм асинхронной репликации данных. В этом случае вместо одной БД, с которой должны работать все клиенты информационной системы, создается несколько одинаковых (по крайней мере, частично) серверов БД на разных машинах и/или узлах сети. Клиенты имеют доступ к некоторому распределяющему устройству (реализованному аппаратно или программным методом), которое при появлении нового клиента оценивает загрузку каждого сервера БД и направляет клиента к наименее загруженному, с которым он (клиент) и будет работать до отсоединения.
Сервера БД связаны между собой и все сделанные изменения пересылают друг другу (тиражируют) с тем, чтобы привести реплицируемые объекты (таблицы) в полное соответствие. Поскольку репликация асинхронная, то этот процесс происходит не сразу, а в течение некоторого времени, в ходе которого данные на разных серверах будут отличаться.
Такое построение позволяет значительно (в самом лучшем случае, прямо пропорционально количеству серверов БД) увеличить производительность системы и наращивать ее по мере роста нагрузки (увеличения количества клиентов или размеров БД) простым прибавлением серверов БД в информационную систему.
Для управления системой на логическом уровне используются правила репликации, которые создаются с помощью языка БД SQL и представляют собой описание того, какие объекты, куда и каким образом реплицировать.
2.4 Функциональные требования к серверу репликации
При разработке сервера репликации были определены основные требования, которым он должен удовлетворять: