Глава 6. Наложение OpenLDAP syncprov

Наложение syncprov (Sync Provider) должно быть определено для каждого DIT, выполняющего роль поставщика (главного DIT) при использовании репликации в стиле syncrepl, то есть с помощью LDAP Content Synchronization protocol (RFC 4533). Это наложение может использоваться с любым механизмом манипуляции данными, поддерживающим в записях атрибуты entryCSN и entryUUID (в настоящий момент только механизмы bdb и hdb). Для управления синхронизацией наложение создаёт в корневой записи базы данных (DIT) атрибут contextCSN.

Для повышения производительности синхронизации рекомендуется при использовании данного наложения назначать индекс eq на атрибут entryCSN в том DIT, где используется это наложение. Пример для файла slapd.conf:

database bdb
...
index contextCSN eq
...

Эквивалент для OLC (cn=config):

olcDbIndex: contextCSN eq

Наложение syncprov (и любые его директивы) должно быть определено для каждого DIT (раздела database), выступающего в роли поставщика для операций репликации. Наложение syncprov определяется в конце раздела, но перед указанием параметров, специфичных для базы данных. Примеры использования для файла slapd.conf:

# определение первого DIT
database bdb
...
# DIT будет выполнять роль поставщика
overlay syncprov
...
# дополнительные параметры базы данных
cachesize 10000
...

# определение второго DIT
database bdb
...
# DIT НЕ будет выполнять роль поставщика

# дополнительные параметры базы данных
cachesize 10000
...

# определение третьего DIT
database bdb
...
# DIT будет выполнять роль поставщика
overlay syncprov
...
# дополнительные параметры базы данных
cachesize 10000
...

В OLC (cn=config) каждое наложение определяется как дочерняя запись к соответствующей записи базы данных (смотрите информацию по использованию наложений в OLC (cn=config) здесь).

В типичной репликации типа Главный-Подчинённый сервер LDAP, содержащий главное DIT (поставщик), определяется наложением syncprov, а подчинённый сервер LDAP (потребитель) — директивой syncrepl (атрибутом olcSyncRepl в OLC), в которой описывается способ доступа к поставщику. Дополнительная информация и примеры конфигурации репликации здесь. Единственное исключение — это конфигурация с несколькими главными серверами (multi-master), при которой каждое DIT является одновременно и главным (поставщиком), и подчинённым (потребителем).

Параметры конфигурации

Следующие атрибуты syncprov могут присутствовать в записи наложения syncprov в OLC (cn=config) или быть определены после директивы overlay syncprov в файле slapd.conf.

olcSpCheckPoint (syncprov-checkpoint)

olcSpCheckpoint: ops minutes
syncprov-checkpoint ops minutes

Данный атрибут (директива) управляет обслуживанием значения contextCSN, которое обычно содержится и изменяется только в оперативной памяти, а запись в базу данных осуществляется лишь при нормальном завершении работы сервера; соответственно, загрузка значения из базы данных происходит во время операции старта сервера. Данный атрибут (директива) используется, чтобы обязать поставщика принудительно записывать значение contextCSN в соответствующую базу данных при условии выполнения успешных операций записи в эту базу данных, либо по прошествии определённого числа (ops) операций записи, либо по истечении определённого количества времени в минутах (minutes) после последнего обновления значения contextCSN в базе данных (или сброса в контрольной точке). По умолчанию syncprov-checkpoint отключена. Цель данной директивы — минимизировать количество предпринимаемых потребителем действий по синхронизации, которые потребуются в случае аварийного завершения работы сервера, на котором располагается главное DIT (поставщик). Пример:

overlay syncprov
# обновлять значение contextCSN в базе данных после ЛИБО
# 100 успешных операций записи, ЛИБО
# по прошествии более 5 минут 
# с момента последней записи contextCSN в базу данных
olcSpCheckPoint: 100 5
syncprov-checkpoint 100 5

olcSpNoPresent (syncprov-nopresent)

olcSpNoPresent: TRUE | FALSE
syncprov-nopresent TRUE | FALSE

Если эта директива установлена в TRUE, при обновлении будет пропущена фаза наличия (Present phase). Для экземпляров syncprov, используемых совместно с базами данных журналов (например, управляемых с помощью наложения accesslog), данное значение должно быть установлено в TRUE. Значение по умолчанию — FALSE.

olcSpReloadHint (syncprov-reloadhint)

olcSpReloadHint: TRUE | FALSE
syncprov-reloadhint TRUE | FALSE

Указывает, что наложение должно соблюдать флаг reloadHint в Sync Control (примечание: некоторые клиенты версии 2.3 не устанавливают корректно этот флаг). При использовании наложения accesslog для delta-синхронизации данная директива должна быть установлена в TRUE. Значение по умолчанию — FALSE. Флаг reloadhint может использоваться потребителем, запрашивающим операцию репликации, для указания того, что он хочет принудительно выполнить загрузку полного DIT независимо от всех остальных параметров и значений, таких как Sync Cookie.

olcSpSessionlog (syncprov-sessionlog)

olcSpSessionlog: ops
syncprov-sessionlog ops

Указывает, что на сервере-поставщике должен вестись журнал, в который записывается информация об операциях записи, производимых в базе данных. Аргумент ops определяет количество операций, которое можно поместить в данный журнал. Туда помещается информация о всех операциях записи (за исключением операций добавления add). Если такой журнал сессии используется, целесообразно назначить индекс eq на атрибут entryUUID в соответствующей базе данных поставщика.

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