Алгоритм репликации
Подробно алгоритм репликации включает следующие шаги.
· Установление соединения с сервером. В соответствии с имеющимся в адресной книге расписанием, составленным администратором, или по введенной вне расписания команде консоли, используя Randomized exponential backoff algoritm, инициирующий репликацию сервер соединяется с вызываемым сервером. Выполняется процедура аутентификации серверов и дополнительные процедуры, выбранные в секциях Security и Restrictions документа Server на вызванном сервере.
· Построение списка реплицируемых баз. Каждый сервер поддерживает в своей виртуальной памяти упорядоченную по идентификатору реплики базы таблицу с информацией обо всех имеющихся на нем базах - т.н. "кэш идентификаторов реплик". В нем содержатся сведения о базах и шаблонах, находящихся в каталоге данных Notes и рекурсивно его подкаталогах, а также во всех Directory Links
и рекурсивно их подкаталогах. В общем случае репликатор, сравнивая кэш идентификаторов реплик "своего" сервера и кэш идентификаторов реплик на вызванном сервере, создает список имеющих одинаковый идентификатор реплики баз на обоих серверах. Однако из команды консоли или документа Connection может следовать, что в репликации должны участвовать только базы соответствующих приоритетов или только базы в указанных каталогах или явно перечисленные базы на вызывающем сервере. Если это так, то репликатор, сравнивая кэши идентификаторов реплик, учитывает не все, а только необходимые базы из кэша идентификаторов реплик "своего" сервера.
· Далее для каждой базы из списка реплицируемых выполняется следующее.
· Не запрещены ли репликации базы? Если в установках одной из реплик выбрана опция Temporary disable replication, все заканчивается появлением на консоли сервера сообщения Replication is disabled for <сервер база>.
· Может ли каждый из серверов открыть реплику на другом сервере? Если один из серверов имеет в ACL реплики на другом сервере уровень доступа No Access, все заканчивается появлением сообщения Access control is set in <сервер база> to not allow replication from <сервер база>. Аналогично происходит, если реплика находится в Directory Link, а сервер не имеет доступа к этой Directory Link. Если же оба сервера имеют доступ к обеим репликам, репликатор открывает реплику на вызванном сервере.
· Репликация ACL. Это происходит, если вызванный сервер имеет в ACL вызвавшего сервера доступ менеджера и в установках реплики на вызвавшем сервере выбрана опция Replicate incoming: Access Control List. Репликатор проверяет, не изменилась ли ACL в реплике на вызванном сервере после последнего изменения ACL "своей" реплики. Если изменилась, репликатор получает ACL с вызванного сервера и заменяет ACL "своей" реплики, после чего снова проверяет, может ли каждый из серверов открыть реплику на другом сервере. Если репликация выполняется по схеме Pull-Push, зеркально-аналогичные проверки и действия выполняются этим репликатором по отношению ACL на вызванном сервере. При репликации по схеме Pull-Pull их выполнит репликатор вызванного сервера на второй фазе репликации.
· Репликация элементов дизайна. Это происходит, если вызванный сервер имеет в ACL вызвавшего сервера доступ не ниже дизайнера, а в установках реплики на вызвавшем сервере выбраны опции Replicate incoming: Forms, Views, еtс., Agents, Replication formula.
Элемент дизайна хранится в базе данных подобно документу. И, подобно документу, каждый элемент дизайна имеет свой идентификатор. Универсальный идентификатор, являющийся частью идентификатора, одинаков во всех репликах базы. Но имеющаяся в составе идентификатора дата-время последней модификации элемента дизайна (SD) может быть разной в каждой реплике.
Репликатор создает список идентификаторов всех элементов дизайна в реплике на вызванном сервере, которые были изменены со времени последней репликации, а если история репликаций очищена, то с Cutoff Date. Затем для каждого идентификатора из этого списка предпринимается попытка определить идентификатор элемента дизайна из "своей" реплики, имеющего такой же универсальный идентификатор.
Если это удалось (т.е. в репликах есть элементы дизайна с одинаковым универсальным идентификатором), остается сравнить времена последней модификации этих элементов. Если в реплике на вызванном сервере "более свежий" элемент дизайна, репликатор получает его и заменяет им имеющийся в "своей" реплике. Но если только этого не запрещают делать опции Replicate incoming: Forms, Views, еtс., Agents, Replication formula "своей" реплики. Удаление элементов дизайна тоже происходит подобно удалению документов - посредством передачи "окурков" с более поздним временем модификации. А репликационных конфликтов для элементов дизайна не бывает.
Если же в реплике на "своем" сервере нет элемента дизайна с таким же универсальным идентификатором, как в реплике на вызванном сервере, остается добавить в "свою" реплику новый элемент дизайна.
Если репликация выполняется по схеме Pull-Push, зеркально-аналогичные проверки и действия выполняются этим репликатором и по отношению элементов дизайна на вызванном сервере. При репликации по схеме Pull-Pull их выполнит репликатор вызванного сервера на второй фазе репликации.
· Репликация документов. Это происходит, если вызванный сервер имеет в ACL вызвавшего сервера возможность создавать или изменять документы.
Вначале репликатор, используя формулу отбора селективной репликации "своей" реплики (или по умолчанию SELECT @All), создает по документам на вызванном сервере вид, содержащий "потенциально допустимые" для приема в "свою" реплику документы. Затем репликатор "просматривает" этот вид и создает список идентификаторов документов в реплике на вызванном сервере, которые были изменены со времени последней репликации, а если история репликаций очищена, то с Cutoff Date. Если документ в реплике на вызванном сервере был в последний раз модифицирован раньше, чем текущее время минус интервал удаления для реплики на "своем" сервере, его идентификатор исключается из списка.
Для каждого идентификатора из этого списка предпринимается попытка определить идентификатор документа из "своей" реплики, имеющего такой же универсальный идентификатор.
Если это удалось (т.е. в обеих репликах есть документы с одинаковым универсальным идентификатором), остается сравнить времена последней модификации (SD) и последовательные номера (SN) этих документов.
Если документ с предшествующей репликации изменился в реплике на вызванном сервере, но не изменился в реплике на "своем" сервере, репликатор копирует измененный документ и замещает им документ в "своей" реплике. То же произойдет, если документ в реплике на вызванном сервере был удален. Вместо удаленного документа остается "окурок" с большим последовательным номером и датой модификации. "Окурок" должен копироваться репликатором в "свою" реплику и заместить имевшийся в ней документ, вызывая тем самым его удаление. Но если только этого не запрещает делать опция Replicate incoming: Deletions "своей" реплики.
Если же документ изменился на обеих сторонах, происходит репликационный конфликт (рассматривается в 6.2.14).
Если же в реплике на "своем" сервере нет документа с таким же универсальным идентификатором, как в реплике на вызванном сервере, его остается добавить в "свою" реплику как новый документ.
Если репликация выполняется по схеме Pull-Push, зеркально-аналогичные проверки и действия выполняются этим репликатором и по отношению документов
на вызванном сервере. При репликации по схеме Pull-Pull их выполнит репликатор вызванного сервера на второй фазе репликации.
Если документ был модифицирован в одной реплике позже, чем было произведено его удаление в другой реплике, модифицированный документ должен "перекрыть окурок". То же произойдет, если в результате ряда модификаций последовательный номер документа в одной реплике оказался больше, чем последовательный номер "окурка".
Наконец, в версиях 4.х при копировании документа происходит не полное копирование всех полей, как это было в версиях 3.х. Копируются только поля, у которых неодинаковые Seq Num. Поля же с одинаковым Seq Num нет смысла копировать - они одинаковы в обеих репликах. Это существенным образом сокращает объем информации, передаваемой при репликации. Именно это и называют "репликацией на уровне полей" - а более строго, пунктов.
Обновление записи в истории репликаций. Только когда репликация успешно завершилась, репликатор вызывавшего сервера обновляет записи в истории репликаций "своей" реплики: когда с вызванного сервера были приняты документы (Received) и когда с вызывавшего сервера были отправлены документы на вызванный (Send). При неуспешной репликации записи в истории репликаций не обновляются. Если репликация выполняется по схеме Pull-Push, репликатор обновляет и историю репликаций на вызванном сервере. При репликации по схеме Pull-Pull это выполнит репликатор вызванного сервера на второй фазе репликации.
· Завершение репликационной сессии. Когда список реплицируемых баз "исчерпан", репликатор или разрывает соединение (схема Pull-Push), или передает запрос "на обратную репликацию" в очередь репликатора на вызванном сервере (схема Pull-Pull).
