Как происходит процесс репликаций между двумя серверами?

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

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

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

Вы можете также использовать серверную командует - Pull, Push и Replicate, чтобы начать репликацию между серверами немедленно.

Что происходит при репликации между двумя серверами?

Replicator остается не задействован, пока сервер А не начинает репликацию на сервером B.

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

Два сервера сравнивают списки баз данных, чтобы найти базы данных с идентичными копиями ID.

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

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

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

Если передача документов, дизайна и изменения в ACL разрешено для документов, сервер реплицирует только поля, которые изменились, при этом не копирует документы полностью. Для документов, которые были удалены, остаются “окурки”. Чтобы экономить место на диске, Domino удаляет эти “окурки” согласно интервалу чистки, который установлен в назначениях репликаций баз данных.

В зависимости от выше перечисленных действий, происходит одно из следующего:

Если репликация заканчивает успешно, сервер А вписывает время в истории репликации сервера B, когда репликация была закончена. Сервер B использует такую же печать времени для сервера А, чтобы делать тот же самое.

Если репликация не заканчивается успешно, отметки времени не регистрируются в истории репликации - так, чтобы будущее репликации будут использовать более раннюю метку времени. Неудавшиеся репликации регистрируются в виде Replication базы данных LOG.NSF.

Рассмотрите следующие аспекты при планировании графика репликаций:

Топология Репликаций

Число документов подключения, которое Вам понадобится для реплик

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

Время репликаций

Базы данных, которые будут участвовать в репликациях

Приоритет баз данных, которые будут реплицироваться

Время ограничения для репликаций

Запуск нескольких копий репликатора