Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Дополнительные инструменты в панели инструментов   
Шаблоны и примеры Читать статью
 
Классы для работы со стабами удалённых документов для Windows64   
Шаблоны и примеры Читать статью
 
Базовые компоненты XPages Extension Library: Widget Container   Серия статьей дающая представление о базовых компонентах Extension Library, их основных свойствах и мест применения
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Всё о репликации Lotus Notes/Domino

Николай Норкин
Вятские Информационные Технологии
nickanor@mail.ru

Всё о репликации Lotus Notes/Domino
1 2 3 4 5
Алгоритм репликации
Рассмотрим пошагово, что происходит в сеансе репликации
    Шаг 1. Установление соединения с сервером. Инициирующий репликацию сервер (станция) соединяется с вызываемым сервером. Происходит процедура аутентификации и проверка возможности доступа к данному серверу (о механизме аутентификации и контроле доступа к серверу >>>)
    Для установления расписания репликаций сервер использует документ Connection Адресной книги, клиент Notes - документ Location (Место вызова)
    Шаг 2. Построение списка реплицируемых баз. Каждый сервер поддерживает в своей виртуальной памяти упорядоченную по идентификатору реплики таблицу всех имеющихся на нем баз данных и шаблонов - так называемый, кэш идентификаторов реплик. Репликатор сравнивает свой кэш и кэш вызываемого сервера и, с учетом репликационных приоритетов и указанных к реплицированию (в документе Connection или в параметрах команды консоли) баз, строит список баз, подлежащих реплицированию в данном сеансе
    Шаг 3. Далее для каждой базы из списка
      • Определяется, не запрещены ли репликации базы. Если в установках одной из реплик выбрана опция, запрещающая репликацию (Temporarily disable replication for this replica в настройках репликации), репликации базы не происходит, о чем уведомляет строка на консоли сервера Replication is disabled for <сервер> <база>
      • Может ли каждый из серверов открыть реплику на другом сервере. Если один из серверов не имеет доступ (уровень доступа No Access) к одной из реплик, либо не имеет доступа к подключенному (связаному) каталогу, внутри которого находится реплика, репликация базы заканчивается выдачей сообщения Access control is set in <сервер> <база> to not allow replication from <сервер> <база>. Если оба сервера имеют доступ к обеим репликам, репликатор открывает реплику на вызванном сервере.
      • Репликация ACL. Для репликации ACL необходимо, чтобы у вызванного сервера был доступ Управляющего (Manager) в ACL вызвавшего сервера и в настройках репликации на вызвавшем сервере была выбрана опция Receive these elements from other replicas: Access Control List. Репликатор сравнивает даты изменения ACL в обеих репликах. Если ACL "чужой" реплики изменился позднее, чем ACL "своей", репликатор получает ACL с вызванного сервера и заменяет им свой ACL, после чего снова проверяет, может ли каждый из серверов открыть реплику другого. При схеме Pull-Push зеркально-аналогичные действия выполняются репликатором по отношению к ACL на вызванном сервере. При схеме репликации Pull-Pull обновление (если необходимо) произведет репликатор вызванного сервера после передачи ему управления во второй фазе репликационной сессии
      • Репликация элементов дизайна. Для успеха этой части репликации базы необходимо, чтобы уровень доступа вызванного сервера в ACL реплики базы на сервере-инициаторе был не ниже уровня Разработчика (Designer). Сервер выискивает и принимает на свою сторону элементы дизайна, изменённые на вызванном сервере позднее, чем изменились эти элементы на его стороне, заменяя последние. Но только если это разрешают делать опции, прописанные в параметрах репликации базы в полях Receive these elements from other replicas: Design elements, Agents, Replication formulas. Удаление элементов дизайна происходит подобно удалению документов путем передачи информации об удалении (stubs). После приёма изменений сервер производит выталкивание изменений, произошедших на своей стороне (схема Pull-Push) после зеркально-аналогичных проверок, либо переходит к следующей стадии приема, оставив передачу изменений до второй фазы сессии (схема Pull-Pull)
      • Репликация документов. Прием изменений документов на сервер-инициатор происходит, если вызванный сервер имеет доступ к базе (ACL) и документам (поля доступа к документам типа Readers и Authors), позволяющий создавать, изменять или удалять документы. Среди документов вызываемого сервера строится специальное представление, содержащее документы согласно формуле репликации. Затем репликатор создает список идентификаторов документов, которые были изменены со времени последней репликации. Если в настройках репликации включен параметр Receive documents from server - Smallest first, полученный список сортируется по размеру документа, в противном случае - по дате модификации. Далее для каждого документа по идентификатору ищется его собрат в своей реплике. Если этого не удалось, новый документ добавляется в реплику. Если документ не новый - сравниваются время последней модификации и последовательные номера этих документов. Если документ оказался измененным с момента последней репликации на обоих серверах - возникает репликационный конфликт (этот случай рассматривается ниже). В противном случае изменения передаются на сервер-инициатор репликации, модифицируя документ на его стороне. Причем, начиная с версии 4.x происходит не полное копирование всех полей, копируются только поля, имеющие неодинаковые флаги Seq Num. Это существенным образом сокращает объём передаваемой информации. Именно это и называют репликацией на уровне полей (пунктов, items). Далее, в зависимости от схемы репликации, либо репликатор сервера повторяет описанные в этом пункте действия в зеркальном направлении, выталкивая новые и модифицированные документы (схема Pull-Push), либо сразу переходит к следующему пункту, оставляя эту работу для чужого репликатора (Pull-Pull)
      • Обновление записи в истории репликаций. При успешном завершении предыдущих стадий репликации репликатор делает запись в истории репликаций своей реплики. Если репликация происходит по схеме Pull-Push, то подобную запись репликатор вносит и в историю репликации чужой реплики
    Шаг 4. Завершение репликационной сессии. Когда список реплицируемых баз исчерпан, репликатор или разрывает соединение (схема Pull-Push), или передает запрос на активизацию репликатора на обратной стороне и передачу изменений в обратную сторону.

Устранение конфликтов репликаций
Когда репликатор обнаруживает, что с момента последней репликации оказались изменёнными версии документа в обеих репликах базы, он вынужден обрабатывать ситуацию репликационного конфликта. Выбирается версия документа, имеющая более позднее время модификации и используется в качестве основного документа. Вторая версия документа сохраняется в виде ответного документа (response) к основному (наличие поля $Ref с ссылкой на основной документ). Кроме того, в ответный документ добавляется поле с именем $Conflict и пустым значением. В представлениях, поддерживающих иерархическую организацию документов, такие документы отображаются в виде ответного документа, отмеченного ромбиком в колонке выделения документов, и строкой [Replication or Save Conflict].
Собственно, на разрешение конфликтов, начиная с пятой версии Notes, влияет значение поля $ConflictAction, значение которого в интерфейсе клиента Domino Designer может быть задано через свойство формы Conflict Handling, по которой создаются документы
  • Значение этого свойства Create Conflicts (отсутствие поля $ConflictAction или значение поля, установленное в значение "1", в документе) задаёт описанное выше разрешение конфликтной ситуации - создание репликационного конфликта
  • Значение свойства Merge Conflicts (значение поля $ConflictAction, равное "2") - объединение конфликтов, произошедших при редактировании различных полей в различных репликах базы данных
Организационно для разрешения возникших конфликтов необходимо собрать авторов изменений "за круглым столом" для осмысления внесенных изменений и выработки согласованного варианта.
Технически этот вопрос разрешается так. Если решено оставить версию документа, принятую за основную, конфликтный документ просто удаляют. Если нужно оставить версию конфликтного документа, то его открывают в режиме редактирования, сохраняют (при этом исчезают поля $Conflict и $Ref, и документ становится главным), а затем удаляется другая версия документа. [Но в этом случае, если конфликт произошел с ответным (response) документом, вместе с полем $Ref теряется и его привязка к главному документу. Необходимо восстановить утерянную связь]. Наконец, если должны остаться обе версии, достаточно пересохранить конфликтный документ.
Если в процессе эксплуатации базы наблюдается усиленная тенденция к образованию конфликтов, скорее всего, необходимо изменять или дизайн базы, или технологию работы с ней. Одним из наиболее эффективных приемов изменения дизайна - разбиение большого документа на несколько мелких, где изменения вносятся не в один документ, а на основе создания новых, более мелких документов. Кроме этого, в окне свойств формы предусмотрены опции Versioning (Поддержка версий) - управление версиями документа и Conflict Handling (Обработка конфликтов) - с параметром автоматического слияния (Merge conflicts) конфликтных документов, если разные пользователи изменяли в них разные поля.
К организационным моментам относится, в первую очередь, технологическое ограничение возможности редактирования документа как можно меньшим количеством пользователей (в идеале - автор документа плюс, для страховки, управляющий базы). Остальные пользователи вносят изменения в документ путем создания ответных к нему документов в форме замечаний.

1 2 3 4 5
 
  Опубликовано — 11/04/2007 |    



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :

Мероприятия
18.12.2012   Опыт реализованных проектов на базе технологий IBM
24.10.2012   Решения IBM для построения надежной ИТ-инфраструктуры и сервисов
09.10.2012   Форум «Ударим СЭДом по бездорожью, разгильдяйству и непрозрачным бизнес-процессам! Система электронного документооборота CompanyMedia 4.0: вперед в будущее!»
Пресс-релизы
02.06.2011   ООО "АДБ.РУ" выпустило очередную версию системы управления контентом для Lotus Domino - Logosphere 2.7.
21.01.2010   Компания «Поликом Про» выполнила для компании «Синергия» пилотный проект по внедрению системы защиты электронной почты IBM Lotus Protector for Mail Security
22.12.2009   Новые технологии разработки приложений на базе Lotus Domino
Биржа труда
18.04.2012 - разработчик Lotus Notes (ОАО "УРАЛСИБ")
26.07.2011 - Программист Lotus (удаленная работа) ()
06.06.2011 - Эксперт (Lotus Notes/Domino) (Крупный банк (ТОП-5))
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU