Чумак Дмитрий Юрьевич

Факультет: Вычислительной техники и информатики

Специальность: Программное обеспечение автоматизированных систем

Тема выпускной работы:

Исследование распределенных баз данных на кластерной вычислительной сети

Руководитель: Ладыженский Юрий Валентинович

Библиотека

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

Авторы: Esther Pacitti, Cedric Coulon, Patrick Valduriez, M. Tamer Ozsu

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

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

Масштабируемость. Служба репликации должна обеспечивать эффективное копирование как малых, так и больших объемов данных.

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

Репликация объектов. Должна существовать возможность копировать объекты, а не просто данные. Например, в некоторых системах допускается репликация индексов и хранимых процедур (или триггеров).

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

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

Механизм инициализации. Система должна включать средства, обеспечивающие инициализацию вновь создаваемой копии.

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

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

1. Esther Pacitti, Cedric Coulon, Patrick Valduriez, M. Tamer Ozsu. PREVENTIVE REPLICATION IN A DATABASE CLUSTER.