скачать рефераты
  RSS    

Меню

Быстрый поиск

скачать рефераты

скачать рефератыКурсовая работа: Механизмы репликаций в распределенных базах

Курсовая работа: Механизмы репликаций в распределенных базах

Департамент образования и науки Краснодарского края

Частное образовательное учреждение

среднего профессионального образования

«Колледж права, экономики и управления»-ЧОУ СПО «КПЭУ»

КУРСОВАЯ РАБОТА

по дисциплине: «Разработка и эксплуатация удаленных баз данных»

МЕХАНИЗМЫ РЕПЛИКАЦИЙ В РАСПРЕДЕЛЕННЫХ БАЗАХ

Краснодар 2010


СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ТЕРМИНОЛОГИЯ, КЛАССИФИКАЦИЯ,КОНФЛИКТЫ

2. ОСНОВНЫЕ ВЫГОДЫ ВНЕДРЕНИЯ МЕХАНИЗМА РЕПЛИКАЦИЙ

2.1 О репликации базы данных

2.2 Механизмы репликации данных

2.3 Назначение репликации данных

2.4 Функциональные требования к серверу репликации

2.5 Синхронная репликация

2.6 Асинхронная репликация

2.7 Основные принципы, правила построения и функционирования РБД

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ


ВВЕДЕНИЕ

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

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


1.  ТЕРМИНОЛОГИЯ, КЛАССИФИКАЦИЯ, КОНФЛИКТЫ

Репликация (синхронизация) - процесс приведения данных электронных таблиц двух БД в идентичное состояние

Репликацию можно классифицировать по разному.

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

2)  По времени проведения сеанса репликации. Если данные должны быть засинхронизированны немедленно после изменений, то такую репликацию будем называть репликация реального времени. Если же процесс репликации запускается, по какому-либо событию во времени или по отмашке администратора БД, то такой вид репликации назовем отложенная репликация.

3)  По способу передачи информации во время процесса репликации. Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двухпроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной или вероятностной.

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

Как видно из вышеприведенного списка, вариантов репликации существует довольно большое количество.


2. ОСНОВНЫЕ ВЫГОДЫ ВНЕДРЕНИЯ МЕХАНИЗМА РЕПЛИКАЦИЙ

1.  Надежность - процесс репликации значительно увеличивает надежность системы, предоставляя приложениям альтернативный доступ к данным. При потере соединения с одним из серверов, пользователь может продолжать работу с данными, используя другой.

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

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

4.  Уменьшение сетевой нагрузки - репликация может быть использована для распределения данных между различными региональными центрами. Приложения будут обращаться не к центральному серверу, а к региональному, тем самым уменьшая нагрузку на сеть.

5.  Работа всех подписчиков с общими ресурсами - репликация позволяет каждому из подписчиков работать с общими ресурсами, например регистр остатков или регистр бухгалтерии, причем для синхронизации потоков всех операций по каждому подписчику применяется контрольное перепроведение документа в эталонной БД, таким образом, на подписчике при проведении документа назначается статус "предварительно проведен", а на эталонной базе "проведен".

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

Важность и необходимость процесса репликации лучше всего иллюстрируются примером. Представим себе крупную туристическую фирму, имеющую головной офис и несколько филиалов, расположенных в гостиницах. И в головном офисе, и в филиалах работает программа формирования и учета оказываемых услуг, причем и там, и там постоянно происходят обновления, которые должны быть доступны на всех рабочих местах, в реальном времени (выставленные счета, специальные предложения, изменения в цене и т. д.). Как в этом случае обновлять базы данных?

При решении проблемы простым путём менеджер в филиале составляет документ, отражающий изменения, посылает его службе поддержки работы базы, а там вносят изменения в базу на основе этого документа. Это не решение - это выход из положения, абсолютно не оправдывающий себя при большом объеме изменений. В перспективе же это создание трудностей для последующей героической борьбы с ними.

Почти идеальное с технической точки зрения решение: соединить головной офис и филиалы скоростными каналами связи и сделать базу данных единой для программы учета. Этот путь возможен только тогда, когда все филиалы имеют постоянный доступ в Интернет по локальной сети или выделенной линии. Что происходит в случае обрыва соединения? Очевидно, что бесперебойной работы в этом решении не добиться. Кроме того, есть психологический аспект, преодолеть который, скорее всего, не удастся: руководство компании будет очень испугано появлением принципиальной возможности зайти из Интернета в "святая святых" - базу данных программы учета. И вряд ли рассказы о межсетевых экранах и прочих средствах безопасности его успокоят.

Применение ПК "Репликация информационных баз" полностью выполняет требование "в реальном времени". Т.е. оператор филиала создаёт / изменяет объект репликации (справочник или документ) и все остальные операторы могут тут же увидеть эту информацию.

В случае обрыва связи информационная база работает в автономном режиме, и как только соединение будет восстановлено, - данные будут синхронизированы.

Данное решение не требует участия человека в процессе обмена (не надо выгружать/загружать файлы и т.д.) и не требует вносить изменения в конфигурацию.

Передаётся только та информация, которая необходима, таким образом, трафик обмена незначителен. Репликация также может решить проблему резервного копирования и проблему архивации (когда база разбивается на текущую и архив).

2.1 О репликации базы данных

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

Один из способов удовлетворения этой потребности - создание распределенной базы данных БД, поддерживающей механизм асинхронной репликации данных. В этом случае вместо одной БД, с которой должны работать все клиенты информационной системы, создается несколько одинаковых серверов БД на разных машинах и/или узлах сети. Клиенты имеют доступ к некоторому распределяющему устройству (реализованному аппаратно или программным методом), которое при подключении нового клиента оценивает загрузку каждого сервера БД и направляет клиента к наименее загруженному серверу, с которым он (клиент) и будет работать до отсоединения.

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

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

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

2.2 Механизмы репликации данных

Для поддержки целостности распределенной БД в СУБД ЛИНТЕР используется механизм асинхронного тиражирования (далее по тексту - репликации) транзакций.

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

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

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

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

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

2.3 Назначение репликации данных

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

Один из способов удовлетворения этой потребности - создание распределенной базы данных (БД), поддерживающей механизм асинхронной репликации данных. В этом случае вместо одной БД, с которой должны работать все клиенты информационной системы, создается несколько одинаковых (по крайней мере, частично) серверов БД на разных машинах и/или узлах сети. Клиенты имеют доступ к некоторому распределяющему устройству (реализованному аппаратно или программным методом), которое при появлении нового клиента оценивает загрузку каждого сервера БД и направляет клиента к наименее загруженному, с которым он (клиент) и будет работать до отсоединения.

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

Такое построение позволяет значительно (в самом лучшем случае, прямо пропорционально количеству серверов БД) увеличить производительность системы и наращивать ее по мере роста нагрузки (увеличения количества клиентов или размеров БД) простым прибавлением серверов БД в информационную систему.

Для управления системой на логическом уровне используются правила репликации, которые создаются с помощью языка БД SQL и представляют собой описание того, какие объекты, куда и каким образом реплицировать.

2.4 Функциональные требования к серверу репликации

При разработке сервера репликации были определены основные требования, которым он должен удовлетворять:

·  совмещение функции сервера публикации и сервера подписки;

·  исключение нарушения структуры базы данных;

·  использование в гетерогенной (смешанной) системе, т.е. система репликации может включать сервера баз данных как Oracle, так и MS SQL;

Страницы: 1, 2


Новости

Быстрый поиск

Группа вКонтакте: новости

Пока нет

Новости в Twitter и Facebook

  скачать рефераты              скачать рефераты

Новости

скачать рефераты

© 2010.