Репликация Domino

Репликация Domino — это технология распределённого хранения и синхронизации данных, реализованная в платформе IBM Domino (ранее Lotus Domino). Она обеспечивает автоматическое копирование и согласование содержимого баз данных (БД) между несколькими серверами и клиентскими устройствами в гетерогенной сетевой среде. Основное назначение репликации — повышение отказоустойчивости, доступности данных и поддержка работы пользователей в режиме офлайн с последующей синхронизацией изменений.

История

Технология репликации впервые появилась в системе Lotus Notes, разработанной американской компанией Iris Associates (основана Рэем Оззи) в 1984 году. Первая коммерческая версия Lotus Notes 1.0 была выпущена в 1989 году. С самого начала репликация была ключевым элементом архитектуры, отличавшим её от традиционных реляционных баз данных. В 1995 году компания Lotus Development Corporation была приобретена корпорацией IBM, и продукт получил название IBM Lotus Domino. В 2012 году IBM передала развитие платформе IBM Notes и Domino, а в 2018 году права на продукт перешли к компании HCL Technologies (Индия), которая продолжает выпуск версий под названием HCL Domino. На протяжении всей эволюции (от Lotus Notes 1.0 до HCL Domino 14.0) принципы репликации оставались неизменными, хотя алгоритмы сжатия, фильтрации и управления конфликтами совершенствовались.

Архитектура и принцип работы

Репликация Domino основана на модели «множество мастеров» (multi-master replication). В отличие от классической схемы «ведущий-ведомый» (master-slave), где только один узел может вносить изменения, в Domino любой сервер или клиент может модифицировать данные в своей локальной копии базы. Все изменения затем распространяются на другие реплики.

Ключевые компоненты

• Реплика — копия базы данных Domino, расположенная на другом сервере или на клиентском устройстве. Реплики могут быть полными или частичными (с фильтрацией по документам, формам или полям).
• Идентификатор реплики (Replica ID) — уникальный 16-символьный шестнадцатеричный код, присваиваемый каждой базе при создании. Все реплики одной базы имеют одинаковый Replica ID, что позволяет системе идентифицировать их как части одного набора.
• Таблица изменений (Change Table) — внутренняя структура, хранящая метаданные о каждом изменении: время изменения, тип операции (создание, модификация, удаление), идентификатор документа и универсальный идентификатор (UNID).
• Универсальный идентификатор (UNID) — 32-символьный шестнадцатеричный идентификатор, присваиваемый каждому документу при создании. Он остаётся неизменным при репликации и позволяет сопоставлять документы в разных репликах.

Процесс репликации

Репликация может быть инициирована по расписанию, вручную администратором или автоматически при изменении данных (push-репликация). Процесс включает следующие этапы:

1. Установление соединения — серверы или клиент и сервер обмениваются аутентификационными данными (по протоколам NRPC (Notes Remote Procedure Call) или HTTP/HTTPS).
2. Обмен таблицами изменений — каждый участник отправляет свою таблицу изменений с момента последней успешной репликации.
3. Выявление расхождений — сравниваются UNID документов и временные метки. Документы, отсутствующие в одной из реплик или имеющие более новую версию, помечаются для передачи.
4. Передача данных — изменённые документы передаются в сжатом виде (алгоритм LZ1 или LZ2). Для больших документов (например, с вложениями) используется потоковая передача.
5. Разрешение конфликтов — если два пользователя одновременно изменили один и тот же документ в разных репликах, система создаёт конфликтный документ (conflict document), который сохраняется рядом с основным. Администратор или пользователь вручную разрешает конфликт.
6. Обновление таблиц изменений — после успешной передачи обе стороны обновляют свои таблицы, фиксируя время последней синхронизации.

Типы репликации

• Pull-репликация — сервер запрашивает изменения у другого сервера.
• Push-репликация — сервер отправляет изменения другому серверу.
• Pull-Push-репликация — двусторонняя синхронизация: сначала сервер получает изменения, затем отправляет свои.
• Клиент-серверная репликация — клиентское приложение (IBM Notes или HCL Notes) синхронизируется с сервером. Поддерживается как полная, так и выборочная репликация (например, только определённые папки или представления).

Классификация репликаций

По направлению

• Однонаправленная — изменения передаются только от источника к приёмнику. Используется для распространения шаблонов или справочных данных.
• Двунаправленная — изменения передаются в обе стороны. Является стандартным режимом для большинства баз.

По объёму

• Полная репликация — передаются все документы, независимо от времени последнего изменения. Применяется при первом создании реплики или после восстановления.
• Инкрементальная репликация — передаются только документы, изменённые после последней репликации. Составляет основную часть трафика.

По способу инициирования

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

Настройка и управление

Администрирование репликации в Domino осуществляется через конфигурационные документы сервера (Server Configuration) и документы соединений (Connection Documents). Ключевые параметры:

• Расписание репликации — интервал, дни недели, время начала и окончания.
• Порт и протокол — обычно NRPC (порт 1352) или HTTP/HTTPS для репликации через интернет.
• Фильтры репликации — ограничение набора реплицируемых документов по формулам (например, только документы с определённым значением поля «Категория»).
• Приоритет репликации — для критичных баз можно задать более частое расписание.
• Максимальный размер передаваемого документа — ограничение на размер одного документа (по умолчанию 1 МБ, может быть увеличен до 10 МБ).

Для мониторинга репликации используются:

• Журнал репликации — файл log.nsf, где фиксируются все события репликации (успехи, ошибки, конфликты).
• Статистика сервера — команда show stat в консоли сервера выводит количество реплицированных документов, объём трафика и время последней репликации.
• Инструменты HCL Domino Administrator — графический интерфейс для просмотра состояния реплик и ручного запуска репликации.

Применение

Репликация Domino используется в следующих сценариях:

• Распределённые организации — филиалы и удалённые офисы синхронизируют базы данных (почтовые, документооборот, календари) с центральным сервером.
• Мобильные пользователи — сотрудники работают с локальными копиями баз на ноутбуках в офлайн-режиме, а при подключении к сети синхронизируют изменения.
• Отказоустойчивость — создание нескольких реплик на разных серверах (в том числе в разных дата-центрах) для обеспечения непрерывности работы при сбоях.
• Архивирование и репликация для чтения — создание реплик только для чтения для снижения нагрузки на основной сервер.
• Резервное копирование — репликация на выделенный сервер для последующего создания резервных копий без остановки основного сервера.

Преимущества и недостатки

Преимущества

• Автономность — пользователи могут работать с данными без постоянного подключения к серверу.
• Масштабируемость — добавление новых серверов не требует изменения архитектуры.
• Отказоустойчивость — выход из строя одного сервера не приводит к потере данных.
• Гибкость — возможность настройки фильтров и расписаний для каждой базы.

Недостатки

• Конфликты данных — при одновременном редактировании одного документа в разных репликах возникают конфликты, требующие ручного разрешения.
• Задержки синхронизации — в зависимости от расписания, расхождения могут сохраняться от нескольких минут до нескольких часов.
• Сложность администрирования — требуется настройка соединений, фильтров и мониторинг для больших кластеров.
• Трафик — при большом количестве изменений репликация может создавать значительную нагрузку на сеть.

Интересные факты

• В ранних версиях Lotus Notes репликация работала через модемные соединения со скоростью 2400 бод, что потребовало разработки эффективных алгоритмов сжатия.
• Идентификатор реплики (Replica ID) генерируется на основе MAC-адреса сетевой карты сервера и текущего времени, что гарантирует уникальность в пределах организации.
• В версии HCL Domino 12.0 была добавлена поддержка репликации через REST API, что позволяет синхронизировать данные с внешними системами (например, с облачными сервисами).

Источники

• IBM Redbooks. «IBM Lotus Domino: Administration and Security». IBM Corporation, 2008.
• HCL Technologies. «HCL Domino 14.0 Administration Guide». HCL Software, 2023.
• Kern, S. «Lotus Notes and Domino 6 Development Unleashed». Sams Publishing, 2003.
• Официальная документация IBM Domino (архивная версия на сайте IBM Knowledge Center, 2019).