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


О Notes

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

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


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


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

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

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


Репликация между серверами. Типы репликаций. Взаимодействие серверов при репликации
Прежде всего следует описать процедуру репликации между двумя серверами. В определённое расписанием время на одном из серверов серверная задача Replicator вызывает другой сервер. Если соединение состоялось, репликатор составляет списки баз, предназначенных для этого сеанса репликации
Далее репликатор на вызывавшем сервере сравнивает списки документов, изменённых, появившихся и удалённых с момента последней репликации между данной парой серверов. Изменения, произошедшие в базе на вызываемом сервере, втягиваются (Pull) в базу сервера-инициатора. Запрос от репликатора первого сервера обслуживается на втором сервере задачей Database Server как обычный пользователь. Существенно то, что один репликатор может одновременно поддерживать только репликацию с одним сервером (одну нить), тогда как сессий Database Server открывается столько, сколько нужно (Можно упомянуть еще и о том, что "активный" репликатор затрачивает больше "калорий", чем "пассивная" задача Database Server). Далее в зависимости от типа репликации происходит передача изменений от вызывающего сервера на вызываемый. Если вызываемый сервер по-прежнему остается "паразитировать" на трудолюбии сервера-инициатора, то репликатор последнего начинает выталкивать (Push) изменения документов, произошедшие на его стороне. Со стороны вызываемого сервера сессия по-прежнему поддерживается задачей Database Server. Описанная схема носит название Pull-Push. В отличие от нее, в схеме Pull-Pull, активность и "усилия" серверов распределены более равномерно. После окончания приема изменений сервер-инициатор "передает бразды" задаче репликатора вызываемого сервера, сам поддерживая процесс репликации сессией Database Server. Репликатор, работающий на стороне вызываемого сервера, производит прием (Pull) изменений.
Возможны еще два урезанных варианта репликации. Push-only -односторонний процесс, в котором вызывающий сервер только выталкивает документы на другой сервер. Pull-only - сервер-инициатор запроса только скачивает изменения, не делясь изменениями на своей стороне.
При сравнении двух основных типов репликации хочется обратить внимание, что схема Pull-Push более применима для репликаций, где вызываемой стороной является коммутационный (hub) сервер либо сервер с "главной" репликой базы данных, к которому направлены запросы по топологии звезда. Недостатком этой схемы будет то, что документы настройки подключений находятся на стороне серверов-инициаторов репликаций, и, следовательно, управление расписанием репликаций на стороне вызываемого сервера затруднено. Также на стороне серверов-инициаторов создаются документы журнала репликаций, что опять же неудобно для мониторинга работы задачи на коммутационном сервере.

Репликации между серверами могут происходить по расписанию (основной вид задания репликаций, на нем остановимся подробнее чуть позднее), запуском задачи с консоли сервера, запуском задачи из операционной системы загрузкой исполняемого файла
  • основная задача 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 [direction] servername [filename or directory],
        где
        x - I для OS/2, N для Windows, V для Novell. unix-системы используют исполняемый файл без начального символа (просто REPLICA)
        [direction] - необязательный параметр, определяющий тип репликации (-p - Pull only, -s - Push only, пропущен - Pull-Push)
        servername - имя вызываемого сервера
        [filename or directory] - реплицируемые базы
Наконец, следует сказать, что для выгрузки репликаторов (правда, всех сразу) используется команда Tell Replica Quit

1 2 3 4 5

Читайте на Notesnet.ru
Документы, создаваемые программно с использованием метода CopyToDatabase, не реплицируются >>>
Параметр Дата отсечки не работает при репликации в Notes/Domino 6.x or 7.x >>>
 
  Опубликовано — 07/30/2007 |    



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

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