Непротиворечивость и репликация в распределенных системах

Размещено на http://www.allbest.ru/

Министерство образования и науки Республики Казахстан

Карагандинский государственный технический университет

Кафедра информационных систем

Контрольная работа

по предмету "Распределенные информационные системы"

Тема: "Непротиворечивость и репликация в распределенных системах"

Вариант 1

Принял: ст. преподаватель

Солодовникова И.В.

Выполнил: ст. гр. ИС-11з-ВВ

Наврузбаева Н.Б.

Караганда 2013

Содержание

Введение

1. Непротиворечивость

1.1 Компоненты непротиворечивого чтения

1.2 Модели непротиворечивости

1.2.1 Модель последовательной непротиворечивости

1.2.2 Модель непротиворечивости FIFO

1.2.3 Модель слабой непротиворечивости

1.2.4 Протокол первичного архивирования с удаленной записью

1.2.5 Протокол первичного архивирования с локальной записью

2. Репликация

2.1 Сравнительные характеристики различных стратегий размещений данных

2.2 Основные концепции репликации данных

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

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

2.5 Полусинхронная репликация

2.6 Типы репликации

2.7 Функциональные средства

2.8 Проблемы реализации

2.8.1 Обновления, выполняемые в составе транзакций

2.8.2 Снимки и триггеры базы данных

2.8.3 Триггеры базы данных

2.8.4 Выявление и разрешение конфликтов

Заключение

Список литературы

Введение

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

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

Если система в целом выглядит и ведет себя как классическая однопроцессорная система с разделением времени (то есть многопользовательская), она считается распределенной системой.

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

Появившаяся в 70-х годах возможность объединения компьютеров в единую сеть произвела революцию в компьютерной промышленности. Эта возможность, прежде всего, вызвала желание организовать разделение доступа к файлам между различными компьютерами. Первые достижения в этой области были ограничены возможностью копирования целых файлов из одной машины в другую. В качестве примера можно указать программу UNIX-to-UNIX copy (uucp) и File Transfer Protocol (ftp). Однако эти решения не позволяли даже близко подойти к реализации доступа к файлам на удаленной машине, по своим возможностям напоминающего доступ к файлам на локальных дисках.

1. Непротиворечивость

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

*Непротиворечивость - свойство дедуктивной теории (или системы аксиом, посредством которых теория задаётся), состоящее в том, что из неё нельзя вывести противоречие, т. е. какие-либо два предложения А и Ш А, каждое из которых является отрицанием другого. (Большая советская энциклопедия)

Для уменьшения риска возникновения противоречивых данных надо устранить избыточность данных или контролировать её.

Существуют следующие способы:

1) Если элемент данных хранится в базе только в одном экземпляре, то для изменения его значения потребуется выполнить только обновления, причем новое значение станет доступным сразу всем пользователям базы данных.

2) А если этот элемент данных (с ведома системы) хранится в базе данных в нескольких экземплярах, то такая система сможет следить за тем, чтобы копии не противоречили друг другу.

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

1.1 Компоненты непротиворечивого чтения

1. сегменты отката

2. номер системного изменения (System Change Number - SCN)

3. блокировки.

Сегменты отката (С.О.) представляют собой структурные компоненты базы данных, предназначенные для хранения информации отката.

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

Номер системного изменения (System Change Number - SCN) Для соблюдения правильного хронологического порядка операций в СУБД ведется единый номер системного изменения (SCN), который представляет собой логическую временную отметку, которая позволяет зарегистрировать последовательность выполнения операций.

СУБД записывает текущие значения SCN в журнал восстановления для обеспечения возможности выполнить накат транзакций в правильной последовательности. В этой СУБД SCN применяется для определения того, какая версия элемента данных должна использоваться в транзакции. SCN позволяет также определить, какая информация, хранящаяся в сегментах отката, уже не нужна и может быть удалена.

Блокировки неявно применяются при выполнении всех операторов SQL, поэтому пользователю никогда не требуется явно блокировать какие-либо ресурсы. Тем не менее, в СУБД предусмотрен механизм, позволяющий пользователю устанавливать блокировки вручную или изменять, правила установки и снятия блокировок, предусмотренные по умолчанию.

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

1.2 Модели непротиворечивости

Ориентированные на данные (без явной синхронизации):

• Строгая непротиворечивость - абсолютная упорядоченность во времени всех обращений к совместно, используемой памяти.

• Линеаризуемая(максимально правдоподобная) непротиворечивость - все процессы наблюдают все обращения к совместно используемой памяти в одном и том же порядке. Обращения упорядочены в соответствии с глобальными отметками времени.

• Последовательная непротиворечивость - все процессы наблюдают все обращения к совместно используемой памяти в одном и том же порядке. Обращения не упорядочены по времени.

• Причинная непротиворечивость - все процессы наблюдают все обращения, связанные причинно-следственными связями.

Ориентированные на данные (с явной синхронизацией):

• непротиворечивость FIFO

• Слабая непротиворечивость - совместно используемые данные могут считаться непротиворечивыми только после синхронизации.

• Свободная непротиворечивость - совместно используемые данные становятся непротиворечивыми после выхода из критической области.

• Поэлементная непротиворечивость - совместно используемые данные, относящиеся к данной критической области становятся непротиворечивыми при входе в эту область.

Последовательная, FIFO, Слабая

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

1.2.1 Модель последовательной непротиворечивости

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

1.2.2 Модель непротиворечивости FIFO

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

1.2.3 Модель слабой непротиворечивости

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

1.2.4 Протокол первичного архивирования с удаленной записью

* Расшифровка обозначений:

W1 - запрос на запись

W2 - пересылка запроса на сервер

W3 - сигнал на обновление резервных копий

W4 - подтверждение выполнения обновления

W5 - подтверждение выполнения записи

R1 - запрос на чтение

R2 - ответ для чтения

Размещено на http://www.allbest.ru/

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

• Существует асинхронный вариант, при котором подтверждение о выполнении записи посылается сразу после обновления первичной копии (не дожидаясь обновления всех копий). Это повышает производительность операции записи, однако требует дополнительных действий для обеспечения: гарантированного обновления всех реплик и согласованного чтения для узла, инициировавшего обновление (он не должен иметь возможность считать значение, который имел элемент данных до записи).

• В случае если все первичные копии находятся на одном узле, имеем реализацию последовательной непротиворечивости, иначе не предпринимая дополнительных мер можно говорить только о непротиворечивости FIFO.

1.2.5 Протокол первичного архивирования с локальной записью

Размещено на http://www.allbest.ru/

Расшифровка обозначений:

W1 - запрос на запись

W2 - перемещение элемента данных х на новый первичный сервер

W3 - подтверждение завершения записи

W4 - сигнал на обновление резервных копий

W5 - подтверждение обновления

R1 - запрос на чтение

R2 - ответ для чтения

• В протоколе подразумевается асинхронное обновление остальных копий.

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

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

2. Репликация

архивирование репликация транзакция fifo

Репликация - процесс формирования и воспроизведения многочисленных копий данных на одном или нескольких узлах.

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

1. Увеличение надежности за счет наличия независимых копий каждого файла на разных файл-серверах.

2. Распределение нагрузки между несколькими серверами.

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

На рисунке 3.12 показаны три возможных способа репликации. При использовании первого способа (а) программист сам управляет всем процессом репликации. Когда процесс создает файл, он делает это на одном определенном сервере. Затем, если пожелает, он может сделать дополнительные копии на других серверах. Если сервер каталогов разрешает сделать несколько копий файла, то сетевые адреса всех копий могут быть ассоциированы с именем файла, как показано на рисунке снизу, и когда имя найдено, это означает, что найдены все копии. Чтобы сделать концепцию репликации более понятной, рассмотрим, как может быть реализована репликация в системах, основанных на удаленном монтировании, типа UNIX. Предположим, что рабочий каталог программиста имеет имя /machine1/usr/ast. После создания файла, например, /machine1/usr/ast/xyz, программист, процесс или библиотека могут использовать команду копирования для того, чтобы сделать копии /machine2/usr/ast/xyz и machine3/usr/ast/xyz. Возможно программа использует в качестве аргумента строку /usr/ast/xyz и последовательно попытается открывать копии, пока не достигнет успеха. Эта схема хотя и работает, но имеет много недостатков, и по этим причинам ее не стоит использовать в распределенных системах.

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

Рис. 3.12. а) Точная репликация файла; б) Ленивая репликация файла; в) Репликация файла, использующая группу

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

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

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

Чтобы предотвратить ситуацию, когда из-за отказа первичный сервер не успевает оповестить об изменениях все вторичные серверы, изменения должны быть сохранены в постоянном запоминающем устройстве еще до изменения первичной копии. В этом случае после перезагрузки сервера есть возможность сделать проверку, не проводились ли какие-нибудь обновления в момент краха. Недостаток этого алгоритма типичен для централизованных систем - пониженная надежность. Чтобы избежать его, используется метод, предложенный Гиффордом и известный как "голосование". Пусть имеется n копий, тогда изменения должны быть внесены в любые W копий. При этом серверы, на которых хранятся копии, должны отслеживать порядковые номера их версий. В случае, когда какой-либо сервер выполняет операцию чтения, он обращается с запросом к любым R серверам. Если R+W > n, то, хотя бы один сервер содержит последнюю версию, которую можно определить по максимальному номеру.

Интересной модификацией этого алгоритма является алгоритм "голосования с приведениями". В большинстве приложений операции чтения встречаются гораздо чаще, чем операции записи, поэтому R обычно делают небольшим, а W - близким к N. При этом выход из строя нескольких серверов приводит к отсутствию кворума для записи. Голосование с приведениями решает эту проблему путем создания фиктивного сервера без дисков для каждого отказавшего или отключенного сервера. Фиктивный сервер не участвует в кворуме чтения (прежде всего, у него нет файлов), но он может присоединиться к кворуму записи, причем он просто записывает в никуда передаваемый ему файл. Запись только тогда успешна, когда хотя бы один сервер настоящий.

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

Существуют четыре стратегии распределения, определяющие способ размещения данных:

1) централизация - единственная централизованная база данных;

2) фрагментация - каждый фрагмент размещается на одном из узлов;

3) полная репликация - полная копия всех данных поддерживается на каждом узле;

4) избирательная репликация - комбинация первых трех способов.

2.1 Сравнительные характеристики различных стратегий размещений данных

	Локализация ссылок	Надежность и доступность	Производительность	Стоимость хранения	Затраты на передачу данных
Централизованное размещение	Самая низкая	Самая низкая	Неудовлетворительная	Самая низкая	Самые высокие
Фрагментированное размещение	Высокая	Низкая для отдельных элементов, высокая для системы	Удовлетворительная	Самая низкая	Низкие
Полная репликация	Самая высокая	Самая высокая	Высокая при выполнении операции чтения	Самая высокая	Высокие при операции обновления, низкие при чтении
Избирательная репликация	Низкая для отдельных элементов, высокая для системы	Низкая для отдельных элементов, высокая для системы	Удовлетворительная	Средняя	Низкие

2.2 Основные концепции репликации данных

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

• Использование репликации позволяет достичь многих преимуществ, включая повышение производительности (когда централизованный ресурс оказывается перегруженным), надежности хранения и доступности данных, наличие "горячей" резервной копии на случай восстановления,

• Возможность поддержки мобильных пользователей и хранилищ данных.

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

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

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

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

Асинхронная репликация предусматривает обновление целевых баз данных после обновления исходной базы данных. Задержка в восстановлении согласованности данных может находиться в пределах от нескольких секунд до нескольких часов или даже суток. Однако в конечном итоге данные во всех копиях будут приведены в синхронное состояние.

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

2.5 Полусинхронная репликация

Вариантом, сочетающим в себе возможности синхронной и асинхронной репликации, является так называемая "semisynchronous" репликация, или "полусинхронная".

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

2.6 Типы репликации

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

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

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

• Процедурная репликация. Вызов пакетной процедуры или функции копируется в одной или нескольких базах данных.

2.7 Функциональные средства

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

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

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

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

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

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

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

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

2.8 Проблемы реализации

Тут будет рассмотрено некоторые проблемы реализации методов репликации данных, а именно:

* Обновления, выполняемые в составе транзакций.

* Снимки и триггеры базы данных.

* Выявление и разрешение конфликтов.

2.8.1 Обновления, выполняемые в составе транзакций

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



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

2.8.2 Снимки и триггеры базы данных

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

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

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

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

Для обеспечения целостности в процессе доставки сведений об изменениях необходимо сохранять исходную последовательность формирования этих сведений.

2.8.3 Триггеры базы данных

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

В частности, в СУБД Oracle для сопровождения копии отношения staff на другом узле, указанном с помощью соединения базы данных с именем RENTALS. GLASGOW. NORTH. COM можно использовать приведенный ниже триггер.



Недостатки

* В связи с необходимостью запуска и выполнения триггерных процедур создается дополнительная нагрузка на систему.

* Триггеры выполняются при каждом изменении строки в ведущей таблице.

* Триггеры не могут выполняться в соответствии с некоторым расписанием.

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

* Аннулирование результатов выполнения триггерной процедуры в случае отмены или отката транзакции - достаточно сложная задача.

2.8.4 Выявление и разрешение конфликтов

* Самая ранняя или самая поздняя временная отметка. Изменяются, соответственно, данные с самой ранней или самой поздней временной отметкой.

* Приоритеты узлов. Применяется обновление, поступившее с узла с наибольшим приоритетом.

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

salary = salary + х.

* Минимальное или максимальное значение. Применяются обновления, соответствующие столбцу с минимальным или максимальным значением.

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

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

Заключение

1) Непротиворечивость - это одна из основных характеристик хранилища данных, в которой определяются правила, необходимые соблюдать, чтобы хранилище возвращало разным процессам правильные результаты.

2) Рассмотрели протокол первичного архивирования с удаленной записью и с локальной записью на примерах.

3) Определили что такое последовательная модель непротиворечивости, модель непротиворечивости FIFO и модель слабой непротиворечивости.

4) Репликация - процесс формирования и воспроизведения многочисленных копий данных на одном или нескольких узлах.

5) Рассмотрели типы и виды репликации.

6) Рассмотрели триггеры баз данных.

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

Список литературы

1. Коннолли, Томас, Бегг, Карелии. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. - М. :Издательский дом "Вильяме",2003. - 1440 с. : ил. - Парал. тит. англ.

2. http://www.intuit.ru/department/database/

3. http://blog.aboutnetapp.ru/archives/29

4. http://citforum.ru/operating_systems/sos/glava_15.shtml

5. Э.Таненбаум. Распределенные системы принципы и парадигмы. Москва-Санкт-Петербург. 2003 г.

6. Всё об INTERNET. Руководство и каталог. Эд Крол. BHV, Киев.

7. Журналы Мир Internet.

8. Компьютерный журнал для пользователей Hard `n' Soft.

9. Журналы Компьютер Пресс.

10. Международный компьютерный еженедельник ComputerWorld Россия.

11. Еженедельник PC Week Russian Edition.

12. Еженедельник для предпринимателей и специалистов в области информационных технологий ComputerWeek Moscow.

Размещено на Allbest.ru

...