Введение
Термины
Репликация — процесс синхронизации данных между несколькими экземплярами служб каталогов (КД). Репликация обеспечивает отказоустойчивость, распределение нагрузки, географическую доступность данных. В инфраструктуре доменов FreeIPA (ALD Pro) репликация играет ключевую роль, поддерживая согласованность данных между контроллерами домена.
DN (Distinguished Name, отличительное имя) — уникальный, полный путь к записи в каталоге, однозначно идентифицирующий эту и только эту запись в иерархической структуре каталога.
Доменный суффикс — это корневое DN домена LDAP (например, `dc=example,dc=com`), определяющее корень каталога, пространство имен и границы репликации.
Атрибут — именованное свойство объекта в LDAP (например, `uid`, `cn`, `mail`), хранящее данные (логин, имя, email) и их метаданные (синтаксис, правила сопоставления).
Класс — шаблон объектов (например, `inetOrgPerson`, `posixAccount`), определяющий обязательные (`MUST`) и допустимые (`MAY`) атрибуты для описания сущностей (пользователей, групп, устройств) в каталоге.
Схема данных в LDAP — набор правил, определяющих структуру каталога, включая допустимые классы в (например, `user`, `group`), их атрибуты (например, `cn`, `uid`) и ограничения на значения (типы данных, уникальность, обязательность).
Конфликт репликации — возникновение несоответствия между разными экземплярами каталога, нарушающее идентичность данных и/или препятствующее дальнейшей синхронизации данных. Можно выделить следующие типы конфликтов репликации:
Naming conflicts (ADD) — возникают при попытке добавить запись с DN, который уже существует в каталоге.
Attribute conflicts — различия в атрибутах экземпляров одной и той же записи на разных серверах.
Modification conflicts — одновременное изменение экземпляров одной и той же записи на разных серверах.
Обнаружение конфликтов репликации
Получение доменного суффикса
Доменный суффикс используется в командах поиска конфликтов репликации. Для получения доменного суффикса на любом контроллере домена выполнить следующие действия:
- Получить (обновить) билет Kerberos администратора домена (по умолчанию имя администратора домена — admin, для получения билета потребуется ввести пароль администратора домена):kinit admin
- Выполнить команды:ldapsearch -Q -LLL -s base | awk '/^dn:/{print $2}'
Получение списка конфликтов репликации
Для проверки наличия конфликтов выполнить на контроллере домена команду:
/usr/sbin/dsconf ldap://`hostname` -D "cn=Directory Manager" repl-conflict list <доменный_суффикс>
Эта команда выведет список всех записей, участвующих в конфликтах репликации.
Важно
Практические примеры представлены в главах
Разрешение конфликтов
Устранение ошибок типа namingConflict (ADD)
Для конфликтов добавления рекомендуется сохранять валидные записи и удалять конфликтующие:
dsconf ldap://<имя_КД> -D "cn=Directory Manager" repl-conflict delete <dn конфликтующей записи>
Валидными считаются записи:
созданные корректным образом (через официальные API или UI);
имеющие все обязательные атрибуты;
соответствующие схеме данных;
принадлежащие "авторитетному" серверу (обычно первому КД в топологии).
Определение валидных записей:
- Сравнить конфликтующие записи:
dsconf ldap://<имя_КД> -D "cn=Directory Manager" repl-conflict compare <dn конфликтующей записи>
Проверить временные метки (атрибут
modifyTimestamp).Учесть бизнес-логику (учесть, какая запись реально используется) (выходит за рамки настоящей статьи).
Другие типы конфликтов
Ситуации, где:
конфликт затрагивает критичные данные (например, учётные записи администраторов);
несколько атрибутов одновременно расходятся между репликами;
автоматическое разрешение может нарушить целостность данных;
конфликт затрагивает связанные записи (например, группы и их участники).
Пример:
Одновременное изменение номера телефона пользователя на двух разных КД, где оба изменения технически корректны, но нужно выбрать актуальное. Порядок действий для решения конфликта
- Сравнить конфликтующие записи:
dsconf ldap://<имя_КД> -D "cn=Directory Manager" repl-conflict compare <dn конфликтующей записи>
- Примите решение:
Удалить конфликтующую запись (как выше)
Или сделать ее действующей:
dsconf ldap://<имя_КД> -D "cn=Directory Manager" repl-conflict swap <dn конфликтующей записи>
Проверка работы репликации
После разрешения конфликтов убедитесь в корректной работе репликации:
- Создайте тестовую запись или измените атрибут существующей, например создайте пользователя через Портал управления.
- Выполните глубокую проверку репликации:
ds-replcheck online -D "cn=Directory Manager" -W -m ldap://<имя_первого_КД>:389 -r ldap://<имя_реплики>:389 -b <доменный_суффикс> -i memberof,idnssoaserial,entryusn,krblastsuccessfulauth,krblastfailedauth,krbloginfailedcount
Данная проверка, это сравнение не только базовых атрибутов, но и:
Служебных метаданных (
entryusn,modifyTimestamp)Вторичных индексов (
memberof)Критичных для безопасности атрибутов (
krblastfailedauth)DNS-зон (
idnssoaserial)
Чем отличается от обычной проверки:
Обычный ldapsearch или dsconf показывает только данные, тогда как ds-replcheck анализирует внутренние механизмы репликации.
Диагностика проблем репликации
При обнаружении проблем можно включить расширенное логирование:
dsconf -D "cn=Directory Manager" ldap://<имя_КД> config replace nsslapd-errorlog-level=24576
И анализировать логи в /var/log/dirsrv/<имя_инстанса>/errors.
Например /var/log/dirsrv/slapd-EXAMPLE-COM/errors
Моделирование ошибок описано в раскрывающемся меню:
Результат моделирования и выполнения команды ds-replcheck:
Отчет показывает расхождения между серверами dc01.ald250.pro (Supplier) и dc02.ald250.pro (Replica). Разберем ключевые проблемы:
1. Состояние репликации (Database RUV's)
Replica is behind Supplier by: 95456 секунд (~26.5 часов) - реплика серьезно отстает
Расхождения в RUV (Replica Update Vectors):
Для replica 4 (dc01):
687a55c1000100040000 68934c91000000040000(Supplier) vs687a55c1000100040000 6891d7b1000000040000(Replica)
2. Количественные расхождения
Записей: 3703 (Supplier) vs 3813 (Replica) - на реплике больше записей
3. Конфликтующие записи
Обнаружено 2 конфликтующие записи (те, что мы создавали)
4. Отсутствующие записи
На реплике отсутствуют (9 записей):
3 записи в users_history (a1_9tpl..., a2_dyj..., ansible)
2 удаленных пользователя (uid=a1, uid=a2) (создавались и удалились отдельно вне воспроизведения)
Роль test_role (создавалась отдельно, вне воспроизведения)
Запись журнала journal.ald250.pro
Запись аудита login
На основном сервере отсутствуют (52 записи):
Структура compat (пользователи, группы)
Записи sudoers
5. Несоответствия атрибутов
Для пользователя conflict_user:
SID: S-1-5-21-...-1010 (Supplier) vs S-1-5-21-...-101500 (Replica)
Пароли: разные хеши PBKDF2-SHA512
UID/GID: 1213200010 vs 1213300500
Данные Kerberos: krbLastPwdChange, krbExtraData различаются
Имена: "conflict User" vs "conflicted User"
Для компьютера journal.ald250.pro:
Отсутствуют атрибуты rbtaSubsystem* на реплике
Различия в objectClass (на Supplier больше классов)
Для repl keep alive:
Метки времени: 20250806123737Z (Supplier) vs 20250805093737Z (Replica)
Для DNA-плагина:
dnaRemainingValues: 100489 (Supplier) vs 199992 (Replica)
Для пользователя testuser:
Атрибут 'telephonenumber': +111111111 (Supplier) vs +33333333 (Replica)
Практическое решение проблем репликации
Начнем с вывода и решения конфликтов, которые показывает dsconf:
dn: nsuniqueid=adc2dc01-71ea11f0-816fe86f-aa36b0da+uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
cn: conflicted User
displayName: conflicted User
gecos: conflicted User
gidNumber: 1213300500
givenName: conflicted
homeDirectory: /home/conflict_user
initials: cU
ipaNTSecurityIdentifier: S-1-5-21-196329585-3226835358-3389735258-101500
ipaUniqueID: c173c7be-71ea-11f0-a685-02000a452904
krbCanonicalName: conflict_user@ALD250.PRO
krbExtraData:: AAI445Focm9vdC9hZG1pbkBBTEQyNTAuUFJPAA==
krbLastPwdChange: 20250805105552Z
krbPasswordExpiration: 20250805105552Z
krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBBjQjo4PD1ZLVBIfEI0KitroUkwR6ADAgESoUAEPiAAXxsWn7SM64uMNXVBzUsCpN1JZOObIc/h+tt+/vlGqWrfFMcF2en4vgPJJo/qtKx0+886arhXPkdPAv4bMFigGzAZoAMCAQShEgQQNTBRWS07MXNTUFZpcCZVJKE5MDegAwIBEaEwBC4QAFnNxLdgMlcm6rpsMIqgh6CN2IWb/cTk6Jj/sKQYGZkU8KlkJHuelUVz0bSk
krbPrincipalName: conflict_user@ALD250.PRO
loginShell: /bin/bash
mail: conflict_user@ald250.pro
mepManagedEntry: cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro
nsds5replconflict: namingConflict (ADD) uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: x-ald-user
objectClass: x-ald-user-parsec14
objectClass: x-ald-audit-policy
objectClass: rbta-unit
objectClass: rbta-address
objectClass: rbtaCustomUserAttrs
objectClass: rbta-inetorgperson-ext
objectClass: ruPostMailAccount
objectClass: rbtaUserMeta
objectClass: ipaSshGroupOfPubKeys
objectClass: ldapsubentry
objectClass: mepOriginEntry
objectClass: ipantuserattrs
proxyAddresses: SMTP:CONFLICT_USER@ALD250.PRO
rbtadp: ou=ald250.pro,cn=orgunits,cn=accounts,dc=ald250,dc=pro
rbtaou: ald250.pro
sn: User
uid: conflict_user
uidNumber: 1213300500
userPassword: {PBKDF2-SHA512}10000$uPEJ8l/mnTsjJkckyxqqJRIQx/X2OrOI$Wzm9wddHKCb9JOLl4UVQLUk/czorLTUqEOYE6QBT/l4t+B+pXgJ8xXrVmkdnKYyREYmXrpf2XyNPsOoEbzbz8A==
x-ald-user-mac: 0:0x0:0:0x0
xaldusermacmax: 0
xaldusermacmin: 0
dn: cn=conflict_user+nsuniqueid=adc2dc05-71ea11f0-816fe86f-aa36b0da,cn=groups,cn=accounts,dc=ald250,dc=pro
cn: conflict_user
description: User private group for conflict_user
gidNumber: 1213300500
ipaUniqueID: c1a7f6d8-71ea-11f0-a685-02000a452904
mepManagedBy: uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
nsds5replconflict: namingConflict (ADD) cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro
objectClass: posixgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: top
objectClass: ldapsubentry
Посмотрим конфликты для cn=conflict_user+nsuniqueid=adc2dc05-71ea11f0-816fe86f-aa36b0da,cn=groups,cn=accounts,dc=ald250,dc=pro
dsconf ldap://dc01.ald250.pro -D "cn=Directory Manager" repl-conflict compare cn=conflict_user+nsuniqueid=adc2dc05-71ea11f0-816fe86f-aa36b0da,cn=groups,cn=accounts,dc=ald250,dc=pro
Conflict Entry: dn: cn=conflict_user+nsuniqueid=adc2dc05-71ea11f0-816fe86f-aa36b0da,cn=groups,cn=accounts,dc=ald250,dc=pro cn: conflict_user description: User private group for conflict_user gidNumber: 1213300500 ipaUniqueID: c1a7f6d8-71ea-11f0-a685-02000a452904 mepManagedBy: uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro nsds5replconflict: namingConflict (ADD) cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top objectClass: ldapsubentry Valid Entry: dn: cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro cn: conflict_user description: User private group for conflict_user gidNumber: 1213200010 ipaUniqueID: accda578-71ea-11f0-8dec-02000a452902 mepManagedBy: uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro objectClass: posixgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: top
Оставим только cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro:
dsconf ldap://dc01.ald250.pro -D "cn=Directory Manager" repl-conflict delete cn=conflict_user+nsuniqueid=adc2dc05-71ea11f0-816fe86f-aa36b0da,cn=groups,cn=accounts,dc=ald250,dc=pro
По такому же принципу разрешим 2й конфликт:
root@dc01:~# dsconf ldap://dc01.ald250.pro -D "cn=Directory Manager" repl-conflict compare nsuniqueid=adc2dc01-71ea11f0-816fe86f-aa36b0da+uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
Enter password for cn=Directory Manager on ldap://dc01.ald250.pro:
Conflict Entry:
dn: nsuniqueid=adc2dc01-71ea11f0-816fe86f-aa36b0da+uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
cn: conflicted User
displayName: conflicted User
gecos: conflicted User
gidNumber: 1213300500
givenName: conflicted
homeDirectory: /home/conflict_user
initials: cU
ipaNTSecurityIdentifier: S-1-5-21-196329585-3226835358-3389735258-101500
ipaUniqueID: c173c7be-71ea-11f0-a685-02000a452904
krbCanonicalName: conflict_user@ALD250.PRO
krbExtraData:: AAI445Focm9vdC9hZG1pbkBBTEQyNTAuUFJPAA==
krbLastPwdChange: 20250805105552Z
krbPasswordExpiration: 20250805105552Z
krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBBjQjo4PD1ZLVBIfEI0KitroUkwR6ADAgESoUAEPiAAXxsWn7SM64uMNXVBzUsCpN1JZOObIc/h+tt+/vlGqWrfFMcF2en4vgPJJo/qtKx0+886arhXPkdPAv4bMFigGzAZoAMCAQShEgQQNTBRWS07MXNTUFZpcCZVJKE5MDegAwIBEaEwBC4QAFnNxLdgMlcm6rpsMIqgh6CN2IWb/cTk6Jj/sKQYGZkU8KlkJHuelUVz0bSk
krbPrincipalName: conflict_user@ALD250.PRO
loginShell: /bin/bash
mail: conflict_user@ald250.pro
mepManagedEntry: cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro
nsds5replconflict: namingConflict (ADD) uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: x-ald-user
objectClass: x-ald-user-parsec14
objectClass: x-ald-audit-policy
objectClass: rbta-unit
objectClass: rbta-address
objectClass: rbtaCustomUserAttrs
objectClass: rbta-inetorgperson-ext
objectClass: ruPostMailAccount
objectClass: rbtaUserMeta
objectClass: ipaSshGroupOfPubKeys
objectClass: ldapsubentry
objectClass: mepOriginEntry
objectClass: ipantuserattrs
proxyAddresses: SMTP:CONFLICT_USER@ALD250.PRO
rbtadp: ou=ald250.pro,cn=orgunits,cn=accounts,dc=ald250,dc=pro
rbtaou: ald250.pro
sn: User
uid: conflict_user
uidNumber: 1213300500
userPassword: {PBKDF2-SHA512}10000$uPEJ8l/mnTsjJkckyxqqJRIQx/X2OrOI$Wzm9wddHKCb9JOLl4UVQLUk/czorLTUqEOYE6QBT/l4t+B+pXgJ8xXrVmkdnKYyREYmXrpf2XyNPsOoEbzbz8A==
x-ald-user-mac: 0:0x0:0:0x0
xaldusermacmax: 0
xaldusermacmin: 0
Valid Entry:
dn: uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
cn: conflict User
displayName: conflict User
gecos: conflict User
gidNumber: 1213200010
givenName: conflict
homeDirectory: /home/conflict_user
initials: cU
ipaNTSecurityIdentifier: S-1-5-21-196329585-3226835358-3389735258-1010
ipaUniqueID: acbf75f2-71ea-11f0-8dec-02000a452902
krbCanonicalName: conflict_user@ALD250.PRO
krbExtraData:: AAIV45Focm9vdC9hZG1pbkBBTEQyNTAuUFJPAA==
krbLastPwdChange: 20250805105517Z
krbPasswordExpiration: 20250805105517Z
krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBBlWVFiX0VGQy0pWD5lSEQ3oUkwR6ADAgESoUAEPiAAzbHqRTVBdHb5wmDrl77TO8VUARRi0rHmJ/98XoVsTBAvYLNRjJVPh9G0b3ghLu0PONdXZiIpu2ErHi8xMFigGzAZoAMCAQShEgQQTUZ7PTopVktRfGZFaW8+LaE5MDegAwIBEaEwBC4QAM3dD4hlnDrfq/XuK10ieoM4yAPEMA+MM+R9CW4OdIsThk9Sx36VOtIOIhSh
krbPrincipalName: conflict_user@ALD250.PRO
loginShell: /bin/bash
mail: conflict_user@ald250.pro
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=ald250,dc=pro
memberOf: cn=ALDPRO - Organization units,cn=roles,cn=accounts,dc=ald250,dc=pro
memberOf: cn=Organization units,cn=privileges,cn=pbac,dc=ald250,dc=pro
memberOf: cn=Organization units - Read - Relations,cn=permissions,cn=pbac,dc=ald250,dc=pro
memberOf: cn=Organization units - Read - OU,cn=permissions,cn=pbac,dc=ald250,dc=pro
memberOf: cn=conflict_user_3m98nnfmo7u7d2rsx,cn=users_history,cn=accounts,dc=ald250,dc=pro
memberOf: cn=conflict_user_fow3ooa2q7q3vkvui,cn=users_history,cn=accounts,dc=ald250,dc=pro
memberOf: cn=test_role,cn=roles,cn=accounts,dc=ald250,dc=pro
memberOf: cn=ALDPRO ROCO Attributes Mapping - Read,cn=privileges,cn=pbac,dc=ald250,dc=pro
memberOf: cn=ALDPRO ROCO Attributes Mapping - Read,cn=permissions,cn=pbac,dc=ald250,dc=pro
memberOf: cn=ALDPRO ROCO Attributes Mapping - Manage,cn=privileges,cn=pbac,dc=ald250,dc=pro
memberOf: cn=ALDPRO ROCO Attributes Mapping - Manage,cn=permissions,cn=pbac,dc=ald250,dc=pro
mepManagedEntry: cn=conflict_user,cn=groups,cn=accounts,dc=ald250,dc=pro
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: x-ald-user
objectClass: x-ald-user-parsec14
objectClass: x-ald-audit-policy
objectClass: rbta-unit
objectClass: rbta-address
objectClass: rbtaCustomUserAttrs
objectClass: rbta-inetorgperson-ext
objectClass: ruPostMailAccount
objectClass: rbtaUserMeta
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
objectClass: ipantuserattrs
proxyAddresses: SMTP:CONFLICT_USER@ALD250.PRO
rbtadp: ou=ald250.pro,cn=orgunits,cn=accounts,dc=ald250,dc=pro
rbtaou: ald250.pro
sn: User
uid: conflict_user
uidNumber: 1213200010
userPassword: {PBKDF2-SHA512}10000$+mn7IoPU4om7kLc9I3PS1opkiHJteGzy$uEHe5EuvMJ4c4KOukivH8+46Ohqvx8PuvSamj18k3uQnzgZ1KBl7brBq4yEGzxJc5Y6Ssl0hkxDZ2D0cMPCOLA==
x-ald-user-mac: 0:0x0:0:0x0
xaldusermacmax: 0
xaldusermacmin: 0
root@dc01:~# dsconf ldap://dc01.ald250.pro -D "cn=Directory Manager" repl-conflict delete nsuniqueid=adc2dc01-71ea11f0-816fe86f-aa36b0da+uid=conflict_user,cn=users,cn=accounts,dc=ald250,dc=pro
Enter password for cn=Directory Manager on ldap://dc01.ald250.pro:
root@dc01:~# dsconf ldap://dc01.ald250.pro -D "cn=Directory Manager" repl-conflict list dc=ald250,dc=pro
Enter password for cn=Directory Manager on ldap://dc01.ald250.pro:
There were no conflict entries found under the suffix
Перезагружаем dirsrv и проверяем вывод ds-replcheck:
Видим сообщение Replication State: Supplier and Replica are in perfect synchronization, означающее что синхронизация прошла успешно.
Остальные конфликтующие записи разрешились самостоятельно, вывод команды говорит о расхождении записей каталога compat - на реплике записи присутствуют, а на 1КД - нет.
Данные записи не влияют на работу ALD Pro, они относятся к плагину Schema Compatibility и этот плагин можно отключить. Данная структура не переносится при реинициализации реплики.
Отключим плагин на 2м КД и перезагрузим dirsrv:
root@dc02:~# ipa-compat-manage disable Directory Manager password: Disabling plugin This setting will not take effect until you restart Directory Server. root@dc02:~# systemctl restart dirsrv@*
И при выполнении команды ds-replcheck получаем идеальный результат:
root@dc01:~# ds-replcheck online -D "cn=Directory Manager" -W -m ldap://dc01:389 -r ldap://dc02:389 -b "dc=ald250,dc=pro" -i memberof,idnssoaserial,entryusn,krblastsuccessfulauth,krblastfailedauth,krbloginfailedcount
Enter password:
================================================================================
Replication Synchronization Report (Thu Aug 7 12:11:57 2025)
================================================================================
Database RUV's
=====================================================
Supplier RUV:
{replica 3 ldap://dc02.ald250.pro:389} 687a55d0000100030000 68946d16000200030000
{replica 4 ldap://dc01.ald250.pro:389} 687a55c1000100040000 68946cc6000100040000
{replicageneration} 687a55c1000000040000
Replica RUV:
{replica 3 ldap://dc02.ald250.pro:389} 687a55d0000100030000 68946d16000200030000
{replica 4 ldap://dc01.ald250.pro:389} 687a55c1000100040000 68946cc6000100040000
{replicageneration} 687a55c1000000040000
Replication State: Supplier and Replica are in perfect synchronization
Entry Counts
=====================================================
Supplier: 3724
Replica: 3724
Tombstones
=====================================================
Supplier: 41
Replica: 41
Result
=====================================================
No replication differences between Supplier and Replica
Реинициализация реплики
В сложных случаях может потребоваться полная реинициализация реплики:
- Создайте резервную копию:
ipa-backup -vd --online --data
- Выполните реинициализацию на 2м КД:
ipa-replica-manage -dv re-initialize --from <имя_первого_КД>
- Проверьте идентичность данных:
ds-replcheck online -D "cn=Directory Manager" -W -m ldap://<имя_первого_КД>:389 -r ldap://<имя_реплики>:389 -b <доменный_суффикс> -i memberof,idnssoaserial,entryusn,krblastsuccessfulauth,krblastfailedauth,krbloginfailedcount
Почему сразу не делать реинициализацию?
Причины:
Производительность: Реинициализация требует полной пересылки всех данных (часы простоя для больших каталогов).
Риски: Может привести к потере локальных изменений, если выполнена некорректно.
Маскировка проблем: Не устраняет корневые причины конфликтов (например, неправильную топологию репликации).
Когда точно нужна реинициализация:
После сбоя жёсткого диска на реплике
При расхождениях в более чем 5-10% записей
После изменения схемы данных
Что проверять при сравнении данных после реинициализации?
В выводе ds-replcheck должно быть:
Replication State: Supplier and Replica are in perfect synchronization No replication differences between Supplier and Replica
Критичные параметры:
memberof- должно совпадать членство в группахidnssoaserial- идентичность DNS-зонkrblastfailedauth- чтобы не блокировать легитимных пользователей
Полезные команды
Проверка расхождений записей пользователей, компьютеров и подразделений:
base_dn=$(ldapsearch -Q -LLL -s base | awk '/^dn:/{print $2}')
password="<PASSWORD>"
# Для пользователей
ipa-replica-manage list 2>/dev/null | grep -E '^[a-zA-Z0-9.-]+:' | awk -F: '{print $1}' | xargs -I{} bash -c 'echo "=== Проверка пользователей на реплике: {} ==="; ldapsearch -x -h {} -b "cn=users,cn=accounts,'"$base_dn"'" -s onelevel -D "cn=Directory Manager" -w "'"$password"'" "(uid=*)" dn 2>/dev/null | grep -c "^dn:" || echo "Ошибка подключения к {}"'
# Для компьютеров
ipa-replica-manage list 2>/dev/null | grep -E '^[a-zA-Z0-9.-]+:' | awk -F: '{print $1}' | xargs -I{} bash -c 'echo "=== Проверка компьютеров на реплике: {} ==="; ldapsearch -x -h {} -b "cn=computers,cn=accounts,'"$base_dn"'" -s onelevel -D "cn=Directory Manager" -w "'"$password"'" "(fqdn=*)" dn 2>/dev/null | grep -c "^dn:" || echo "Ошибка подключения к {}"'
# Для подразделений
ipa-replica-manage list 2>/dev/null | grep -E '^[a-zA-Z0-9.-]+:' | awk -F: '{print $1}' | xargs -I{} bash -c 'echo "=== Проверка подразделений на реплике: {} ==="; ldapsearch -x -h {} -b "cn=orgunits,cn=accounts,'"$base_dn"'" -s onelevel -D "cn=Directory Manager" -w "'"$password"'" "(ou=*)" dn 2>/dev/null | grep -c "^dn:" || echo "Ошибка подключения к {}"'
Где <PASSWORD> - пароль УЗ Directory Manager
Вывести служебную информацию Replica Update Vectors (RUV), о состоянии репликации между серверами FreeIPA :
ipa-replica-manage list-ruv
Проверка статуса репликации между всеми серверами:
dsconf $(ldapsearch -Q -LLL -s base | awk '/nisDomain:/{gsub(/\./,"-",$2); print toupper($2)}') replication monitor
На вопрос Enter a bind DN for <server>:389 ответьте cn="Directory Manager"
Вывести информацию о группе узлов ipaservers:
ipa hostgroup-show ipaservers
Удаление всех конфликтов:
Данная команда удалит все конфликты, данные могут быть повреждены!
Используйте ее с осторожностью.
domain=$(ldapsearch -Q -LLL -s base | awk '/nisDomain:/{gsub(/\./,"-",$2); print toupper($2)}'); dsconf $domain repl-conflict list $(ldapsearch -Q -LLL -s base | awk '/^dn:/{print $2}') | awk '/^dn: /{print substr($0,5)}' | xargs -I [] dsconf $domain repl-conflict delete []
Заключение
Регулярный мониторинг и соблюдение рекомендаций по разрешению конфликтов помогут избежать проблем с согласованностью данных.