Механизмы репликаций в распределенных базах (стр. 1 из 4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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