Протоколы на базе первичной копии, подразумевающие репликацию данных
Все протоколы на базе первичной копии подразумевают наличии для каждого элемента данных Х, ассоциированного с ним первичного элемента данных, который отвечает за координацию операций записи. В[1] выделяется два протокола поддерживающих репликацию:
Протокол первичного архивирования с удаленной записью
Описание протокола:
Расшифровка обозначений:
W1 - запрос на запись
W2 - пересылка запроса на сервер
W3 - сигнал на обновление резервных копий
W4 - подтверждение выполнения обновления
W5 - подтверждение выполнения записи
R1 - запрос на чтение
R2 - ответ для чтения
При реализации этого протокола необходимо гарантировать, что в каждый момент времени только один узел имеет доступ к первичной копии, тем самым, имея возможность изменять данные. Существует асинхронный вариант, при котором подтверждение о выполнение записи посылается сразу после обновления первичной копии (не дожидаясь обновления всех копий). Это повышает производительность операции записи, однако требует дополнительных действий для обеспечения: гарантированного обновления всех реплик (защита от сбоев при распространении) и согласованного чтения для узла, инициировавшего обновление (он не должен иметь возможность считать значение, который имел элемент данных до записи). В случае если все первичные копии находятся на одном узле, имеем реализацию последовательной непротиворечивости, иначе не предпринимая дополнительных мер можно говорить только о непротиворечивости FIFO.
Протокол первичного архивирования с локальной записью
Описание протокола:
Расшифровка обозначений:
W1 - запрос на запись
W2 - перемещение элемента данных х на новый первичный сервер
W3 - подтверждение завершения записи
W4 - сигнал на обновление резервных копий
W5 - подтверждение обновления
R1 - запрос на чтение
R2 - ответ для чтения
В протоколе подразумевается асинхронное обновление остальных копий. Здесь также необходимо предпринимать дополнительные меры, чтобы гарантировать обновление остальных реплик, однако проблемы согласованного чтения для узла, инициировавшего обновление, здесь не возникает. Без дополнительных мер протокол реализует FIFOнепротиворечивость, реализовав полностью упорядоченную групповую рассылку (с помощью отметок времени Лампорта)[1], можно получить реализацию последовательной непротиворечивости. Поскольку в протоколе допускается перемещение первичной копии то необходимо решить задачи поиска узла, содержащего первичную копию и смены владельца.
Пример решения задач поиска и смены владельца первичной копии
В СУБД Oracle существует метод репликации данных, предотвращающий возникновение конфликтов[2,3], и который содержит решения двух рассматриваемых задач. В [2] он определяется как dynamic ownership with token passing(динамическое владение с переходящим маркером). В этом методе подразумевается наличие нескольких реплик табличных данных, расположенных на разных узлах, на каждом из которых установлена СУБД Oracle. К реплицируемой таблице добавляется два столбца, первый из которых содержит имя узла (owner), который владеетстрокой данных, а второй номер версии строки данных (epoch). Столбец epoch используется для предотвращенияконфликтов упорядочивания при асинхронной рассылке изменений.