Репликация: возможность автономной работы. Разрешение использования нескольких репликаторов

Система управления документооборотом 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 (LN) , но относительно немногие имели с ним дело на практике. Вследствие этого по Лотусу имеется катастрофический дефицит объективной информации. Вся доступные публикации об этом продукте имеют вид рекламных проспектов или фрагментов технических описаний.

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

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

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

Немного истории

Компания Лотус была пионером во многих направлениях софтверного бизнеса. Сейчас это многие не помнят, но в самом начале 90-тых "Lotus 1-2-3" был синонимом электронной таблицы - достойных конкурентов у него просто не было... Почтовая программа "CC-mail" оставалась лучшей корпоративной почтовой системой до середины 90-х.

Аналогов выпущенного в конце 80-х LN вообще не существовало - для него пришлось придумать отдельный термин - "GroopWare" (обеспечение коллективной работы). Это была первая и долгое время единственная система, реально позволяющая обеспечить быстрое создание единого информационного пространства компании и системы корпоративных коммуникаций.

Триумфальное шествие LN продолжалось почти десять лет, и основными его пользователями являлись крупные и средние корпорации. Неудивительно, что интерес к компании Лотус проявила IBM, традиционно обслуживающая Top1000 мирового бизнеса, и в конце концов таки купила эту компанию на корню. Так что ныне Лотус - это подразделение IBM, сохранившее некоторую самостоятельность, и торговую марку "Lotus".

Сейчас, впрочем, от всей линейки продуктов Лотус на рынке реально остался только Lotus Notes - остальные офисные приложения практически умерли, не выдержав конкуренции с Microsoft Office . А Lotus Notes не просто остался, но активно продвигается - по крайней мере, на российском рынке.

Lotus Notes - что это такое?

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

Главной особенностью лотусовской базы данных является ее ориентация на хранение больших плохо структурированных документов и коллективную работу с ними. Под коллективной работой подразумевается возможность нескольким человекам одновременно править одну и ту же запись (документ). Соответственно, поддерживается аппарат версий и возможности отслеживания изменений, сделанных отдельными пользователями. Кроме текстов, записи лотусовских БД могут содержать произвольное количество настраиваемых пользователями реквизитов разных типов. Причем настройка состава реквизитов достаточно проста и посильна конечным пользователям. Документы в базе могут ссылаться друг на друга (что-то типа вебовских гипертекстовых ссылок), и кликнув на ссылку в тексте документа, можно открыть другой документ.

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

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

Еще одним базовым механизмом, впервые реализованный именно в Lotus Notes, является репликация - т.е. возможность серверов LN синхронизировать свои базы, пересылать друг другу документы в свободное от основной работы время. Таким образом обеспечивается возможность работы в территориально распределенной среде при медленных каналах связи, когда каждый сотрудник работает со своим ближайшим сервером (т.е. быстро), а, скажем, по ночам эти сервера синхронизируют свои базы.

Естественно, предусмотрена возможность разработок специализированных приложений в среде LN. Для этой цели в систему встроен язык программирования (Lotus script), открывающий доступ к API системы, и позволяющий создавать достаточно сложные приложения. Можно также разрабатывать приложения для Lotus на более традиционных Java & JavaScript, к которым также имеются библиотеки объектов для работы с Lotus-овским API.

Обратная сторона медали

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

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

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

Но сегодня значительная часть пользователей предпочитает использовать офисные приложения других фирм - например, Microsoft, которые стали сегодня стандартом де-факто. В Lotus-овском хранилище документов можно хранить "чужие" файлы, но, как только мы начинаем использовать MS Word совместно с Lotus, тут же выясняется, что половина всех прелестей, которые были при работе со встроенным редактором LN, теряется.

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

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

А необходимость во множестве серверов возникала из-за того, что одиночные сервера не справлялись с нагрузкой, поскольку LN в силу свой интегрированности очень требователен к серверным ресурсам. И когда в результате они переписали приложение на MS SQL , выяснилось, что всех пользователей спокойно "тянет" один не самый крутой сервер, и пропускной способности каналов (которой не хватало для репликации) вполне хватает для нормальной удаленной работы пользователей.

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

• Во первых, БД Lotus Notes не поддерживает транзакции - т.е. согласованные изменения нескольких таблиц, выполняемые как единое целое. Т.е. если, например, приложение, работающее на клиенте, успело модифицировать одну запись, но не успело другую, и "упало" (например, свет выключился), то в базе данных LN измененная запись останется таковой, в то время как во всех современных СУБД в такой ситуации на сервере произойдет откат до начального состояния. Из-за этого поддерживать целостность больших баз на LN становится проблематично.
• Во-вторых, как мы говорили выше, LN поддерживает возможность связывания документов. Но при этом контроля ссылочной целостности в нем нет - Вы спокойно можете удалить документ, на который кто-то ссылается, и образуется "висячая" ссылка. Естественно, нет никаких более продвинутых механизмов контроля целостности - типа constraints в реляционных базах данных.
• И наконец, в-третьих - в отличие от современных реляционных СУБД, где индексирование записи происходит при помещении ее в базу, в LN индексирование - это отдельный процесс, происходящий асинхронно.

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

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

Лотус как система документооборота

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

Но наряду с этим у него есть и большой недостаток - что, кроме этого Lotus сам по себе ничего больше не умеет. Т.е. сделать макет базовыми средствами Lotus можно, а вот реализовать полноценную систему корпоративного документооборота, удовлетворяющую требованиям ГОС-ов, не получается. Говорить - "Для автоматизации делопроизводства мы купим Lotus Notes" - такой же нонсенс, как и "Для автоматизации делопроизводства мы купим MS SQL". Необходимо либо разрабатывать систему, используя LN как инструмент, либо покупать специализированное решение.

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

В целом выходит, что при несколько меньшей трудоемкости сроки разработки прикладной системы на базе Lotus не отличаются от аналогичных разработок на базе скажем, MS SQL и Visual Basic , а стоимость (с учетом лицензий и дорогих разработчиков) может и заметно превосходить. Не говоря уж о том, что эксплутационные свойства систем на LN, такие, как надежность и эффективность, заметно хуже, чем у решений на базе полноценных СУБД.

Специализированные решения для организации делопроизводства на Lotus на российском рынке есть. Наиболее распространенными системами являются разработка компании Intertrust - "Office Media", система "Босс-референт" от АйТи и "Золушка" разработки Института развития Москвы, и ряд других систем.

Но они стоят дополнительных к самому Lotus Notes денег, не являются готовыми продуктами, а, скорее, "полуфабрикатами". По оценке специалистов, их функциональности и эксплутационным характеристикам также уступают системам, реализованным на базе полноценных СУБД и функционирующим в среде Microsft Office, таким как "Дело" от "Электронных офисных систем", LanDocs от "Ланит", Optima Workflow от Оптимы.

Заключение

И все-таки, почему при всем вышесказанном Lotus Notes достаточно популярен у IT-менеджеров и продолжает свою экспансию в крупные российские компании?

Видимо, основных резона два.

• Во первых, конъюнктурно - имиджевые соображения - типа "у нас все, как у лидеров западного бизнеса - вот и Lotus Notes стоит".
• Во вторых, LN создает иллюзию быстрого решения. При относительно небольших трудозатратах можно получить видимый результат и решить слой самых простых задач. А то, что дальше развивать это решение будет очень сложно - так к тому времени либо бизнес помрет, либо IT-менеджер поменяется...

Не стоит также сбрасывать со счетов активную директ-маркетинговую политику партнеров IBM.

Каковы перспективы этого продукта на рынке? Те, кто много лет эксплуатируют сотни и тысячи рабочих мест LN, скорее всего, не откажутся от него никогда - по крайней мере, до следующего катаклизма уровня "проблемы 2000 года". Просто потому, что издержки перехода на что-то другое будут слишком велики - возникающие проблемы проще и дешевле решать в его рамках…

Но мне кажется, что в современных условиях Lotus Notes уже уходит в те глубоководные впадины рынка, где живут лох-несские чудовища, IBM-овские мэйнфреймы и Кобол. Там Lotus будет жить вечно, но компаниям, выбирающим для себя решения сейчас, ставить на Lotus Notes видимо, не имеет большого смысла.

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

Интернет-магазин

IBM Lotus Domino Express / IBM Domino Collaboration and Messaging Express Надежно защищенная полнофункциональная среда приложений для совместной работы, ориентированная на потребности среднего бизнеса Программное обеспечение IBM Domino Collaboration and Messaging Express предлагает надежно защищенную полнофункциональную среду приложений для электронной почты и широкого круга приложений для бизнеса и совместной работы. Его комплектация и цена ориентированы на потребности среднего бизнеса, а поддержка обеспечивается на широком круге платформ и операционных систем. Три предложения для малого и среднего бизнеса не более 1000 пользователей, которые предоставляют возможности электронной почты, планирования и обмена мгновенными сообщениями, а также поддерживают широкий спектр бизнес-приложений - Lotus Domino Messaging Express, Lotus Domino Collaboration Express и Lotus Domino Server Express.

IBM Notes (ранее: IBM Lotus Notes) IBM Notes (ранее: IBM Lotus Notes) - является настольным клиентом для социального бизнеса. Он обеспечивает доступ к необходимым людям, бизнес-приложениям и информации на предприятии и в Интернете. Теперь можно выполнять свою работу быстрее и эффективнее. Программное обеспечение IBM Notes помогает быстро справляться с работой, предоставляя единую точку доступа для создания информационных ресурсов, получения и передачи знаний, совместной работы в группах и принятия решений. Устраняя традиционные ограничения на рабочих местах, программное обеспечение IBM Notes помогает вам связываться с людьми и находить информацию в пределах предприятия и в сети Интернет.

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

• иметь доступ к базе данных (минимум Корреспондент - Depositor в ACL базы данных)
• база должна быть разрешена к репликации (в настройках репликации базы снят соответствующий флажок - подробнее о настройках - ниже)
• база, расположенная на локальной станции, не должна быть зашифрована чужим ключом
• при создании реплики базы на сервере в установках сервера (в серверном документе - раздел Security или переменной NOTES.INI Create_Replica_Access ) пользователь должен быть наделен правами на создание реплик баз на этом сервере

Создание реплики конкретной базы данных инициируется выбором команды Главного меню Файл -> Репликация -> Создать реплику... (либо командой контекстного меню Репликация -> Создать реплику... ). Открывшееся окно диалога предоставляет возможность задать имя сервера или выбрать локальный вариант (Local ) и задать размещение файла базы данных в файловой системе.

Дальнейшие опции позволяют задать:

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

• Группа опций How often replication occurs (С каким интервалом происходит репликация) задаёт расписание репликаций для текущего Места вызова (Location) - собственно, предоставляет доступ к соответствующему разделу документа Адресной книги. Собственно, все заполняемые опции находят своё отражение в документе
• Опция Apply changes to all locations (Применить изменения ко всем местам вызова - внизу окна диалога) применяет данные настройки и к прочим документам Locations Адресной книги
• Группа опций How much will be replicated (Количество данных для репликации) относится уже собственно к базе и задаёт направление репликации (опции Send documents to server - Отпрвлять документы на сервер и Receive documents from server - Получать документы с сервера) и режим приёма документов с сервера (полноту приёма этих документов). Можно задать четыре режима:
  Full documents (Документы целиком) . Документы реплицируются полностью
  Partial documents (Документы по частям) . Содержимое документов реплицируется частично, размер усекается в соответствие со следующими опциями (Усечение документов, размер которых превышает - Truncate documents larger than , Ограничение размера вложения до - Limit attachments size ). Документы с неполным содержимым определяются как усечённые (truncated ). При открытии в заголовок окна документа добавляется термин УСЕЧЁН (TRUNCATED ). Для восстановления полной информации можно воспользоваться действием главного меню Actions -> Retrieve Entire Document (Действия -> Принять документ полностью ). Усечённые документы невозможно редактировать, они также не обрабатываются агентами
  Summary only (Только аннотации) . В данном режиме документы усекаются с передачей информации из полей Author и Subject , а также первых 40 Кбайт форматированного поля
  Smallest first (Начиная с маленьких) . Режим, появившийся в Notes R6. При репликации в этом режиме сначала реплицируются маленькие по размеру документы, что делает репликационный механизм более дружелюбным пользователю в приложениях типа библиотека документов , в стандартной почтовой базе
• Опция Which server is used for replication (Сервер, использующийся для репликации)
Группа опций Экономия места (Space Savers)

• Remove documents not modified in the last ... days: (Удалить документы, не измененные за последние... дней) . Установка опции автоматически удаляет из данной реплики документы, с момента последнего сохранения которых прошло более указанного количества дней. Документы, удаленные из данной реплики на основании этой установки, будут удалены в других репликах, если 1). список управления доступом (ACL) реплик позволяет серверу или пользователю-инициатору репликации удалять документы; 2). Не установлен флаг Do not send deletions made in this replica to other replicas (Не отправлять удаления, сделанные в этой реплике, в другие реплики ). Для баз, размещенных на сервере "автоудаление" производится серверной задачей Updall , запускаемой в ночное время, для локальных баз - в момент открытия базы
• Количество дней в вышеприведенной строке (даже если флажок Remove documents... не поднят) определяет также процесс удаления информации об удаленных документах ("окурков", stubs ). Для того, чтобы сервер смог отличить удаленный в этой реплике документ от только что созданного в другой реплике, документ не удаляется сразу полностью, остается stub как некая информация о том, что этот документ был в реплике. Удаление stub откладывается на интервал времени, составляющий третью часть от указанного в этом поле. За это время должны произойти репликации со всеми другими репликами, иначе по прошествии отведенного срока stub удаляется и документ из залежалой реплики может появиться вновь.
• Receive only a subset of the documents (Принимать часть документов) : Опция используется, если в реплику должны поступать не все документы, а только из некоторых видов и папок (опция ) или удовлетворяющие условию отбора, заданному при включении опции Documents that meet a selection formula (Выбирать по формуле) . Эта возможность заключает в себе понятие выборочной (селективной) репликации. Кроме того на закладке Advanced можно задать правила для репликаций элементов дизайна и списка управления доступом (см. ниже)
Закладка Отправка (Send)

• Do not send deletions made in this replica to other replicas (Не отправлять удаления, сделанные в этой реплике, в другие реплики ). Установка этого флага позволяет не распространять удаления, имевшие место быть в этой реплике, в другие реплики базы данных. Если опция не выбрана - появившиеся после удаления документов в этой реплике stubs ("окурки") передаются в другие реплики и вызывают удаление соответствующих документов и в прочих репликах
• Do not send changes in database title and catalog info to other replicas (Не отправлять изменения в названии базы данных и информацию для каталога в другие реплики ). Поднятие этого флага запрещает передачу изменений некоторых параметров базы данных на другие реплики базы. В противном случае эти изменения будут подхвачены другими репликами, если имеется достаточный доступ (уровень разработчика) у сервера или пользователя, производящего репликацию
• Do not send changes in local security property to other replicas (Не отправлять изменения в локальной защите в другие реплики ). Подобно предыдущему, но в отношении свойств базы данных, касающихся локальной безопасности этой реплики
Закладка Прочее (Other)

• Temporary disable replication for this replica (Временно отключить репликацию ). Выбор опции запрещает участие базы в любых репликационных процессах. Сервер выдает сообщение Replication is disabled . Опция полезна администратору, если база по каким-то причинам оказалась поврежденной и требуется ее восстановление, прежде чем будет возможность возобновить репликации
• Scheduled replication priority (Приоритет репликации по расписанию ). Параметр задает приоритет участия базы в репликациях согласно документам Connection Корпоративной Адресной книги или Location (Место вызова ) Локальной Адресной книги. Реплики с высоким (High ) приоритетом могут нуждаться в более частом обновлении, чем остальные. В соответствии с выбранным расписанием репликаций в Адресной книге создаются документы Connection : один - для поддержки репликаций с высоким приоритетом (наиболее частые репликационные сессии), один - для репликаций с высоким и средним приоритетом, и для репликаций баз всех трех приоритетов - в самое дешевое время и нечасто. Документы Connection для поддержки репликаций различного приоритета не должны содержать накрывающих участков времени. В противном случае, расписание составлено некорректно, и репликационные сессии могут происходить беспорядочно, а часть реплик может совсем не обслуживаться
• Only replicate incoming documents saved or modified after (Только входящие документы, сохраненные/измененные после ):. Значение даты (Cutoff Date ), содержащееся в этом поле, требуют принимать в реплику только документы, имеющие дату модификации позже указанной. Документы из других реплик с датой модификации ранее Cutoff Date не включаются в списки реплицируемых документов и, следовательно, никогда не будут приняты в реплику этой базы с других серверов.
• CD-ROM publishing date (Дата выпуска компакт-диска ):. При распространении реплики на компакт-диске рекомендуется задать в этом поле дату записи на диск до проведения первой репликации (записи диска). Тогда при первой репликации (когда чиста история репликаций) будут просматриваться документы, модифицированные после даты публикации, а не все множество документов, что оптимизирует время первой репликации
Дополнительные возможности по определению формул отбора селективной репликации имеются на закладке Дополнительно (Advanced)

• Прежде всего, имеется возможность задать разные формулы отбора для разных пар принимающих изменения (поле When computer/Если компьютер ) серверов и станций и серверов или станций, с которых принимаются изменения (поле Receives from/ Принимает данные от ). Для разных пар можно указать:
• Формулу отбора при установке флага в полях Documents in specified views or folders и Documents by selection formula наподобие описанной выше для закладки Space Savers
• Access Control List (Таблицы управления доступом) - принимаются изменения в списке управления доступом
• Design elements (Элементы дизайна) - принимаются все элементы дизайна кроме агентов и репликационных формул
• Agents - принимаются агенты
• Replication formula - разраешает принимать в базу назначения формулы селективной репликации, имеющие более позднее время модификации. Это позволяет менеджеру "центральной реплики" базы задавать формулы селективной репликации в процессе эксплуатации базы.
• Deletions - принимается информация об удаленных документах, вызывая удаление документов и в выбранной реплике
• Fields - принимаются не все поля документов, а только выбранные из списка. В результате документ становится усечённым (см. описание выше) и нередактируемым.
Ограничение размера реплики (для баз формата ниже R5). Можно задать максимальный размер реплики. Список выбора позволяет установить ограничение на уровне 1 Гб, 2 Гб, 3 Гб или 4 Гб. Вообще-то здесь можно вести речь не об ограничении, а об увеличении размера реплики. Дело в том, что в версии Notes R4.x при создании размер базы автоматически ограничивался 1 Гб. При активном росте этой базы лимит в конце концов выбирался, а установить новый лимит можно было только создав реплику и установив ей более высокий лимит.
Возможность создания реплики немедленно или в фоновом режиме при следующей репликации по расписанию. При выборе второго варианта создается заготовка базы данных, которая впоследствии наполняется содержимым
Поддержка Списка управления доступом (ACL) базы-оригинала для вновь создаваемой базы. Для нормальной поддержки функционирования базы (в том числе и нормального процесса репликации) необходимо иметь этот флажок включенным
Создание полнотекстового поискового индекса базы. Нельзя забывать, что для создания полнотекстового индекса базы, расположенной на сервере, в дальнейшем потребуется наличие полномочий разработчика базы, в то время как при создании реплики возможно создать полнотекстовый индекс, не имея этих прав.

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

Шаг 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 ) конфликтных документов, если разные пользователи изменяли в них разные поля.
К организационным моментам относится, в первую очередь, технологическое ограничение возможности редактирования документа как можно меньшим количеством пользователей (в идеале - автор документа плюс, для страховки, управляющий базы). Остальные пользователи вносят изменения в документ путем создания ответных к нему документов в форме замечаний.