Алгоритм репликации
Рассмотрим пошагово, что происходит в сеансе репликации

Шаг 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 и пустым значением. В представлениях, поддерживающих иерархическую организацию документов, такие документы отображаются в виде ответного документа, отмеченного ромбиком в колонке выделения документов, и строкой .
Собственно, на разрешение конфликтов, начиная с пятой версии Notes, влияет значение поля $ConflictAction , значение которого в интерфейсе клиента Domino Designer может быть задано через свойство формы Conflict Handling , по которой создаются документы

• Значение этого свойства Create Conflicts (отсутствие поля $ConflictAction или значение поля, установленное в значение "1" , в документе) задаёт описанное выше разрешение конфликтной ситуации - создание репликационного конфликта
• Значение свойства Merge Conflicts (значение поля $ConflictAction , равное "2" ) - объединение конфликтов, произошедших при редактировании различных полей в различных репликах базы данных

Организационно для разрешения возникших конфликтов необходимо собрать авторов изменений "за круглым столом" для осмысления внесенных изменений и выработки согласованного варианта.
Технически этот вопрос разрешается так. Если решено оставить версию документа, принятую за основную, конфликтный документ просто удаляют. Если нужно оставить версию конфликтного документа, то его открывают в режиме редактирования, сохраняют (при этом исчезают поля $Conflict и $Ref , и документ становится главным), а затем удаляется другая версия документа. [Но в этом случае, если конфликт произошел с ответным (response) документом, вместе с полем $Ref теряется и его привязка к главному документу. Необходимо восстановить утерянную связь]. Наконец, если должны остаться обе версии, достаточно пересохранить конфликтный документ.
Если в процессе эксплуатации базы наблюдается усиленная тенденция к образованию конфликтов, скорее всего, необходимо изменять или дизайн базы, или технологию работы с ней. Одним из наиболее эффективных приемов изменения дизайна - разбиение большого документа на несколько мелких, где изменения вносятся не в один документ, а на основе создания новых, более мелких документов. Кроме этого, в окне свойств формы предусмотрены опции Versioning (Поддержка версий) - управление версиями документа и Conflict Handling (Обработка конфликтов) - с параметром автоматического слияния (Merge conflicts ) конфликтных документов, если разные пользователи изменяли в них разные поля.
К организационным моментам относится, в первую очередь, технологическое ограничение возможности редактирования документа как можно меньшим количеством пользователей (в идеале - автор документа плюс, для страховки, управляющий базы). Остальные пользователи вносят изменения в документ путем создания ответных к нему документов в форме замечаний.

По умолчанию, Domino реплицирует все базы данных, которые имеют одинаковые ID реплик. Для реплик только определенных баз данных, редактируйте поле File/Directories to Replicate в документе подключения. В это поле, введите имена баз данных или имена каталогов, которые Вы хотите реплицировать. Отделите их друг от друга, точкой с запятой.

Чтобы определить выбранную базу данных для репликации, введите ее имя файла, включая.NSF расширение. Если база данных находится в подкаталоге, включите путь относительно каталога данных Notes - например, EAST\SALES.NSF.

Чтобы определить все файлы расположенные в каталоге, введите EAST\. Вы не можете использовать для этой цели звездочку (*).

Репликации баз данных согласно их приоритетов.

Менеджеры Базы данных назначают приоритет репликаций базам данных так, чтобы Domino администраторы могли наметить репликации для баз данных, основанных на приоритете. Например, Вы можете наметить первоочередной приоритет для баз данных, которые являются критическими для делового процесса - например, Domino Directory реплицируется часто. Вы можете наметить так же низкоприоритетные базы данных.

Установки репликаций с использованием приоритета, редактируются в поле Replicate databases of документа подключения. Установка по умолчанию Low & Medium & High priority.

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

Ограничение времени репликаций.

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

Чтобы ограничивать время реплик, Вы вводите значение в поле Replication Time Limit из документа подключения.

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

Чтобы ограничивать репликации по времени для всего сервера, редактируйте NOTES.INI файл, чтобы включить переменную ReplicationTimeLimit.

Использование нескольких репликаторов одновременно

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

Когда Вы используете несколько репликаций, каждый репликатор обращается только с одной сессией репликаций. Например, если на сервере Hub-E/East/Acme намечена репликация с сервером HR-E/East/Acme и с Hub-W/West/Acme одновременно, один репликатор обрабатывает репликацию Hub-E/East/Acme и HR-E/East/Acme, другой репликатор обрабатывает реплику между Hub-E/East/Acme и Hub-W/West/Acme.

Несколько репликаторов обращаются с несколькими репликами, между одним сервером источником и несколькими серверами назначения одновременно.

Пример. Если База данных 1 и База данных 2 на Hub-E/East/Acme нуждаются в репликации с Hub-W/West/Acme, то только один репликатор общается с каждой сессией репликации, по очереди.

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

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

Пример. Если Вы используете один репликатор, не намечайте реплику с Hub-E/East/Acme на Hr-E/East/Acme по COM1, на тоже самое время, что и с Hub-E/East/Acme, на Hub-W/west/Acme по COM2 одновременно.

Разрешение использования нескольких репликаторов.

Отклонение запросов на репликации с сервера.

Чтобы оградить сервер от принятия просьб о репликациях, редактируйте NOTES.INI файл, чтобы включить переменную ServerNoReplRequests. Если эта установка установлена в 1, сервер отказывается от всех запросов на репликацию.

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

Запрещение репликаций.

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

Чтобы запретить репликации, отредактируйте документ подключения в Domino Directory. В секции Replication, запретите использование репликации, установите значение поля Replication в Tasks – Disabled.

Форсирование намеченных репликаций.

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

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

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

Команды для репликатора:

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

Pull - Реплицируются изменения в базах данных в одном направлении, где сервер только забирает изменения с другого сервера

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

Система управления документооборотом Lotus Notes

Характеристика

Lotus Notes – ориентированная на БД собственного формата система клиент-серверной архитектуры, разработанная корпорацией Lotus Development, разработкой и продажами которой в настоящее время занимается IBM . Система работает под управлением различных платформ семейств Windows и UNIX.

Назначение

Lotus Notes изначально разрабатывалась для работы в локальных сетях, но сейчас может работать и в глобальных, например, в Интернете .

Основные компоненты:

ПО промежуточного уровня (Middleware).

Краткое описание функционирования

Каждый клиент или сервер может иметь несколько локальных БД. Каждая БД представляет собой коллекцию заметок (notes). Клиент представляет собой совокупность запускающей подсистемы и модулей просмотра, сопоставимых по функциональности с Web-браузерами. В отличие от браузеров, они предоставляют возможности не только чтения, но и редактирования информации.

Основная функция сервера Lotus (Lotus Domino) – управлять коллекцией БД и предоставлять к ним доступ клиентам и другим серверам.

Репликация

Репликация основывается на связующих документах (connection documents) – особых заметках, содержащихся в каталоге Domino и описывающих время, способ (схему репликации – см. табл. 5) и объект репликации .

Таблица 4 Разновидности идентификаторов Notes
Идентификатор	Область видимости	Описание
Универсальный идентификатор (Universal ID, UNID)	Глобальная	Глобально уникальный идентификатор, присваиваемый каждой заметке
Идентификатор инициатора (Originator ID, OID)	Глобальная	Идентификатор заметки, включающий информацию об истории
Идентификатор БД (Database ID)	В пределах сервера	Отметка времени создания БД или восстановления БД после сбоя сервера
Идентификатор заметки (Note ID)	В пределах БД	Идентификатор заметки, зависящий от экземпляра БД
Идентификатор реплики (Replica ID)	Глобальная	Отметка времени, используемая для идентификации копий одной БД

Операции изменения:

Модификация документа;

Добавление документа;

Удаление документа.

Модифицированный документ должен быть разослан на все реплики. Изменения заметки заканчиваются изменением ее OID, предыдущее значение которого копируется в журнал истории документа. При добавлении документа для него создаются новые UNID и OID. При удалении документа на его место в БД помещается заглушка удаления (deletion stub). Заглушка удаления не уничтожается до тех пор, пока не уничтожены все копии удаленного документа .

Разрешение конфликтов репликации

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

Для заметок, имеющих в списках серверов A и B одинаковые UNID, но разные OID, выполняются следующие действия. Задание на репликацию просматривает истории обеих заметок. Если одна из историй является частью другой, то конфликт отсутствует: более новая заметка замещает более старую. Если изменения относятся к различным элементам заметки, то конфликтующие модификации также отсутствуют: в объединенную заметку передаются наиболее новые элементы. Во всех остальных случаях конфликт неразрешим. При этом Notes выбирает один из документов победителем. Им становится копия с большим последовательным номером в OID или (в случае равенства последовательных номеров) с большей отметкой времени .

Репликация в кластере

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

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

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

1
Распределённые базы данных. Суть механизма репликаций
Одна из отличительных черт Lotus Notes/Domino как продукта поддержки групповой работы (groupware ) - наличие механизма поддержки распределённых баз данных. Термин Распределённая база данных в этом контексте следует понимать как совокупность нескольких расположенных на различных серверах Domino или клиентских станциях "версий" (реплик ) одной базы данных. Эти реплики могут не являться (и, в общем случае, не являются) точными зеркалами друг друга. Настройка прав доступа к базе и настройка селективного отбора документов и элементов дизайна реплик предоставляют возможность выбора подмножества документов для конкретной реплики. Но реплики, в отличие от копий баз данных, объединяет возможность обмениваться изменениями, происшедшими в документах, или появившимися/удаленными документами (С учётом предыдущего пассажа употреблять термин синхронизация уместно с некоторыми оговорками). Такое распределение позволяет пользователям обращаться к данным сервера Domino, который им более близок. Либо вообще пользоваться данными, размещёнными на мобильном рабочем месте, лишь изредка дозваниваясь до сервера для актуализации информации. Благодаря простоте и надежности репликационного механизма возможна эффективная организация работы с ресурсами для больших сообществ территориально удалённых друг от друга пользователей. Процесс поиска изменений и обмена ими именуется репликацией . Поддержкой этого процесса на сервере и клиентских станциях ведает задача Репликатор (Replicator)
Реплики базы данных объединяет одинаковый идентификатор реплики (Replica ID) , который присваивается при создании базы данных и распространяется на все её реплики. В отличие от реплик, создание копии базы данных (копии не на файловом уровне, а по понятиям Notes) ведет к присвоению копии другого идентификатора реплики и исключение полученной копии из механизма обмена изменениями с породившей его базой. Идентификатор (Код) реплики можно увидеть в окне Свойств базы данных

Также идентификатор реплики используется при указании местоположения документа (URL документа):

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

• основная задача Replicator , обслуживающая репликации по расписанию, загружается (обычно) при старте сервера, для чего указывается в списке задач сервера - переменной ServerTasks (ServerTasks=список_задач, Replica, список_задач ), и в каждый момент времени может обслуживать только одну репликационную сессию. Для обслуживания нескольких репликаций одновременно необходим запуск нескольких задач. Это может быть обеспечено указанием переменной Replicators или указанием нескольких задач Replicator (Replica ) в списке запускаемых задач в переменной ServerTasks (обе переменные прописываются в файле настроек NOTES.INI)
• Дополнительная задача репликатора загружается командой Load Replica с консоли сервера
• Дополнительная задача репликатора для репликации с определенным сервером загружается командой

Load Replica <имя сервера> <имя базы данных> (схема Pull-Push),
Replicate <имя сервера> <имя базы данных> (аналогична предыдущей команде),
Load Pull <имя сервера> <имя базы данных> (Pull only)
или Load Push <имя сервера> <имя базы данных> (схема Push only) с консоли сервера. Запущенный такой командой репликатор завершится после выполнения репликации. При указании имени вызываемого сервера постарайтесь указывать его иерархическое (Canonical или Abbreviated ) имя, а не общее (Common ). Известна проблема, связанная с различием в доступе к базе данных, где вызываемый сервер (при указании его канонического имени ) обладал большими правами и мог видеть большее число документов, в то время как общее имя проходило как -Default- , и в результате подобной репликации большинство документов на стороне вызываемого сервера оказалось удалено

• Возможен также запуск репликатора на уровне операционной системы как запуск файла из программного каталога Notes с ключами:
  xREPLICA servername ,
  где
  x - I для OS/2, N для Windows, V для Novell. unix-системы используют исполняемый файл без начального символа (просто REPLICA)
  - необязательный параметр, определяющий тип репликации (-p - Pull only, -s - Push only, пропущен - Pull-Push)
  servername - имя вызываемого сервера
  - реплицируемые базы

Наконец, следует сказать, что для выгрузки репликаторов (правда, всех сразу) используется команда Tell Replica Quit

Система управления документооборотом Lotus Notes

Характеристика

LotusNotes– ориентированная на БД собственного формата система клиент-серверной архитектуры, разработанная корпорациейLotusDevelopment, разработкой и продажами которой в настоящее время занимаетсяIBM. Система работает под управлением различных платформ семействWindowsиUNIX.

Назначение

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

Основные компоненты:

• ПО промежуточного уровня (Middleware).

Краткое описание функционирования

Каждый клиент или сервер может иметь несколько локальных БД. Каждая БД представляет собой коллекцию заметок (notes). Клиент представляет собой совокупность запускающей подсистемы и модулей просмотра, сопоставимых по функциональности сWeb-браузерами. В отличие от браузеров, они предоставляют возможности не только чтения, но и редактирования информации.

Основная функция сервера Lotus(LotusDomino) – управлять коллекцией БД и предоставлять к ним доступ клиентам и другим серверам.

Репликация

Репликация основывается на связующих документах (connection documents) – особых заметках, содержащихся в каталоге Domino и описывающих время, способ (схему репликации – см. табл. 5) и объект репликации .

Таблица 4 Разновидности идентификаторов Notes
Идентификатор	видимости	Описание
Универсальный идентификатор (Universal ID, UNID)	Глобальная	Глобально уникальный идентификатор, присваиваемый каждой заметке
Идентификатор инициатора (Originator ID, OID)	Глобальная	Идентификатор заметки, включающий информацию об истории
Идентификатор БД (Database ID)	В пределах сервера	Отметка времени создания БД или восстановления БД после сбоя сервера
Идентификатор заметки (Note ID)	В пределах БД	Идентификатор заметки, зависящий от экземпляра БД
Идентификатор реплики (Replica ID)	Глобальная	Отметка времени, используемая для идентификации копий одной БД

Операции изменения:

модификация документа;

добавление документа;

удаление документа.

Модифицированный документ должен быть разослан на все реплики. Изменения заметки заканчиваются изменением ее OID, предыдущее значение которого копируется в журнал истории документа. При добавлении документа для него создаются новые UNID и OID. При удалении документа на его место в БД помещается заглушка удаления (deletion stub). Заглушка удаления не уничтожается до тех пор, пока не уничтожены все копии удаленного документа .

Таблица 5 Схемы репликации
	Описание
Извлечение-продвижение	Задание на репликацию считывает изменения с целевого сервера и передает на него собственные изменения
извлечение	Задание на репликацию считывает изменения с целевого сервера и передает на него собственные изменения по его запросам
Продвижение	Задание на репликацию передает собственные изменения на целевой сервер, никак не реагируя на имеющиеся на нем изменения
Извлечение	Задание на репликацию считывает изменения с целевого сервера, не пытаясь передать ему собственные изменения

Разрешение конфликтов репликации

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

Для заметок, имеющих в списках серверов A и B одинаковые UNID, но разные OID, выполняются следующие действия. Задание на репликацию просматривает истории обеих заметок. Если одна из историй является частью другой, то конфликт отсутствует: более новая заметка замещает более старую. Если изменения относятся к различным элементам заметки, то конфликтующие модификации также отсутствуют: в объединенную заметку передаются наиболее новые элементы. Во всех остальных случаях конфликт неразрешим. При этом Notes выбирает один из документов победителем. Им становится копия с большим последовательным номером в OID или (в случае равенства последовательных номеров) с большей отметкой времени .

Репликация в кластере

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

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