Вопросы построения распределенной базы данных единой информационной системы возникают и при развитии компании, когда создаются удаленные филиалы, магазины и склады. Каждая удаленная информационная система с целью повышения устойчивости должна работать самостоятельно, периодически отправляя в Центральный офис консолидированную информацию. Для исключения человеческого фактора в вопросе периодической синхронизации информации базы данных должны быть включены в общую систему репликации.
Репликация данных между серверами баз данных может выполняться с помощью встроенных средств СУБД или может быть реализована в рамках бизнес - логики приложений. Репликация с помощью встроенных средств СУБД предполагает наличие надежных каналов связи. Пропускная способность этих каналов должна быть достаточно высокой, чтобы успевать передавать всю реплицируемую информацию в realtime-режиме. Процесс репликации в СУБД основан на понятиях "издатель", "подписчик", "статья". Настройка репликации сводится к установке отношений между издателем и подписчиком. Недостатком данной репликации является однонаправленность. Т.е. статья (фактически это таблица) может передаваться от издателя подписчику. При этом подписчик не может ее изменять.
Реализации процессов репликации на уровне бизнес-логики значительно усложняет жизнь разработчику, но позволяет значительно оптимизировать сам процесс передачи информации. Проблема репликации информации представляет собой довольно нетривиальную задачу с весьма неоднозначным решением. Приступая к решению задачи репликации данных, необходимо принимать во внимание, что придется столкнуться с конфликтами реплицируемых данных, которых для баз данных, работающих в единой сети прямого коннекта к серверу базы данных, не возникает в принципе. Особенно сложен переход от единой базы к распределенной, когда приходится подстраивать алгоритм репликации под уже существующую структуру работающей БД. При разработке новой информационной системы необходимо учитывать технологические нюансы будущей распределенной базы данных.
2.2 Механизмы репликации данных
Для поддержки целостности распределенной БД в СУБД ЛИНТЕР используется механизм асинхронного тиражирования (далее по тексту - репликации) транзакций.
Суть механизма асинхронного тиражирования состоит в том, что обработка данных выполняется локально, а распределенные данные копируются на тот сервер, где они должны использоваться. При таком методе поддержки логической целостности распределенной БД имеет место некоторая рассинхронизация состояния локальных БД во времени, т.е. изменение состояния одной локальной базы данных отстает от изменения другой локальной базы данных во времени.
Если один из серверов системы, требующих обновления тиражируемых данных, выходит из строя, то система продолжает работать с остальными, при этом обновление данных на сервере после его ремонта произойдет автоматически, т.е. ошибка на одном узле глобальной сети не повлияет на работу остальных узлов.
Механизм асинхронного тиражирования транзакций гарантирует доставку измененных данных на вторичные серверы непосредственно после завершения транзакции, если сервер доступен, или сразу после подключения сервера к сети. Такой подход предполагает хранение дублирующей информации в различных узлах сети и может обеспечить, по сравнению с другими подходами к репликации, снижение трафика, улучшение времени ответа системы, а также позволяет оптимизировать нагрузку на серверы.
Асинхронная репликация, в отличие от двухфазной синхронизации, не обеспечивает полной синхронности информации на всех серверах в любой момент времени. Синхронизация происходит через некоторый, обычно небольшой, интервал времени, величина которого определяется быстродействием соответствующего канала связи. Для большинства задач кратковременное наличие устаревших данных в удаленных узлах вполне допустимо.
Вместе с тем, асинхронная репликация транзакций принципиально обеспечивает целостность данных, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.
2.3 Назначение репликации данных
Многие современные информационные системы предъявляют достаточно высокие требования к скорости отработки поисковых запросов при условии одновременной работы большого количества клиентов. Кроме того, развиваясь, такие системы должны легко масштабироваться без ущерба для скоростных характеристик системы.
Один из способов удовлетворения этой потребности - создание распределенной базы данных (БД), поддерживающей механизм асинхронной репликации данных. В этом случае вместо одной БД, с которой должны работать все клиенты информационной системы, создается несколько одинаковых (по крайней мере, частично) серверов БД на разных машинах и/или узлах сети. Клиенты имеют доступ к некоторому распределяющему устройству (реализованному аппаратно или программным методом), которое при появлении нового клиента оценивает загрузку каждого сервера БД и направляет клиента к наименее загруженному, с которым он (клиент) и будет работать до отсоединения.
Сервера БД связаны между собой и все сделанные изменения пересылают друг другу (тиражируют) с тем, чтобы привести реплицируемые объекты (таблицы) в полное соответствие. Поскольку репликация асинхронная, то этот процесс происходит не сразу, а в течение некоторого времени, в ходе которого данные на разных серверах будут отличаться.
Такое построение позволяет значительно (в самом лучшем случае, прямо пропорционально количеству серверов БД) увеличить производительность системы и наращивать ее по мере роста нагрузки (увеличения количества клиентов или размеров БД) простым прибавлением серверов БД в информационную систему.
Для управления системой на логическом уровне используются правила репликации, которые создаются с помощью языка БД SQL и представляют собой описание того, какие объекты, куда и каким образом реплицировать.
2.4 Функциональные требования к серверу репликации
При разработке сервера репликации были определены основные требования, которым он должен удовлетворять:
· совмещение функции сервера публикации и сервера подписки;
· исключение нарушения структуры базы данных;
· использование в гетерогенной (смешанной) системе, т.е. система репликации может включать сервера баз данных как Oracle, так и MS SQL;
· многонаправленная репликация с гарантированной доставкой информации, т.е. сервер публикации должен рассылать информацию нескольким серверам подписки;
· сервер подписки может принимать информацию от нескольких серверов публикации;
· система репликации может представлять сложную паутину, в которой отдельные сервера репликации, совмещая функции сервера подписки и сервера публикации, выполняют функцию сервера пересылки информации;
· наглядный визуальный контроль функционирования сервера репликации как в режиме публикации, так и в режиме подписки;
· репликация информации таблиц, структура которых включает поля BLOB (binary large object) и поля, допускающие значение NULL;
· кодирование реплицируемой информации.
Сервер репликации удовлетворяет не только этим требованиям, но и имеет еще ряд дополнительных функций, которые позволяют наглядно контролировать процесс репликации, устанавливать и контролировать параметры канала соединения с удаленными серверами, выполнять экспортно/импортные операции для доставки информации на жестких носителях и загрузки ее в сервер подписки при отсутствии канала связи.
Сервер лицензии, входящий в комплектацию сервера репликации, обеспечивает дополнительную защиту реплицируемой информации. Система репликации замкнутая, и сервер лицензии не позволяет серверу подписки подключиться к серверу публикации другой информационной системы, а также отказывает в доступе серверам публикации других информационных систем.
В случае синхронной репликации, если данная реплика обновляется, все другие реплики того же фрагмента данных также должны быть обновлены в одной и той же репликации. Логически это означает, что существует лишь одна версия данных.
В большинстве продуктов синхронная репликация реализуется с помощью триггерных процедур (возможно, скрытых и управляемых системой). Но синхронная репликация имеет тот недостаток, что она создаёт дополнительную нагрузку при выполнении всех транзакций, в которых обновляются какие-либо реплики (кроме того, могут возникать проблемы, связанные с доступностью данных).
В случае асинхронной репликации обновление одной реплики распространяется на другие спустя некоторое время, а не в той же транзакции. Таким образом, при асинхронной репликации вводится задержка, или время ожидания, в течение которого отдельные реплики могут быть фактически неидентичными (то есть определение реплика оказывается не совсем подходящим, поскольку мы не имеем дело с точными и своевременно созданными копиями).
В большинстве продуктов асинхронная репликация реализуется посредством чтения журнала транзакций или постоянной очереди тех обновлений, которые подлежат распространению. Преимущество асинхронной репликации состоит в том, что дополнительные издержки репликации не связаны с транзакциями обновлений, которые могут иметь важное значение для функционирования всего предприятия и предъявлять высокие требования к производительности.
2.7 Основные принципы, правила построения и функционирования РБД
РБД состоит из набора узлов, связанных коммуникационной сетью, основной задачей которой является передача данных без ошибок и искажения. Коммуникационная сеть является ядром информационной сети, обеспечивающим передачу и некоторые виды обработки данных.