Алгоритм реплікації
Розглянемо покроково, що відбувається у сеансі реплікації

Крок 1. Встановлення з'єднання із сервером. Ініціюючий реплікацію сервер (станція) з'єднується з сервером, що викликається. Відбувається процедура аутентифікації та перевірка можливості доступу до даному серверу(про механізм аутентифікації та контроль доступу до сервера >>>)
Для встановлення розкладу реплікацій сервер використовує документ Connection Адресної книги, клієнт Notes - документ Location (Місце виклику)
Крок 2. Побудова списку баз, що реплікуються. Кожен сервер підтримує у своїй віртуальної пам'ятівпорядковану за ідентифікатором репліки таблицю всіх баз даних і шаблонів, що є на ньому, - так званий, кеш ідентифікаторів реплік. Реплікатор порівнює свій кеш і кеш сервера, що викликається і, з урахуванням реплікаційних пріоритетів і вказаних до реплікування (у документі Connection або в параметрах команди консолі) баз, будує список баз, що підлягають реплікуванню в даному сеансі
Крок 3. Далі для кожної бази зі списку
• Визначається, чи не заборонено реплікацію бази. Якщо в установках однієї з реплік вибрано опцію, яка забороняє реплікацію ( Temporarily disable replication for this replicaв налаштуваннях реплікації), реплікації бази не відбувається, про що повідомляє рядок на консолі сервера Replication is disabled for<сервер> <база>
• Чи може кожен із серверів відкрити репліку на іншому сервері. Якщо один із серверів не має доступу (рівень доступу No Access) до однієї з реплік, або не має доступу до підключеного (пов'язаного) каталогу, всередині якого знаходиться репліка, реплікація бази закінчується видачею повідомлення Access control is set in<сервер> <база>не може бути ніяким поданням від<сервер> <база> . Якщо обидва сервери мають доступ до обох реплік, реплікатор відкриває репліку на сервері.
• Реплікація 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 Різновиди ідентифікаторів
Ідентифікатор	Область видимості	Опис
Універсальний ідентифікатор (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 Різновиди ідентифікаторів
Ідентифікатор	видимості	Опис
Універсальний ідентифікатор (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 або (у разі рівності послідовних номерів) з більшою позначкою часу .

Реплікація у кластері

У кластері замість явного планування реплікації за допомогою сполучних документів, зміни просто негайно передаються на всі репліки кластера.

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