Problème de réplication sur un annuaire Sun Directory Server

J'ai eu récomment un souci lors d'un "refresh" de la production vers la pré-production, sur un "consumer" LDAP, dans une architecture Sun DSEE répliquée (2 master, 2 hub et 2 consumers). Dans le fichier errors, on voit les lignes suivantes :

[13/Sep/2016:02:15:19 +0200] - ERROR<8277> - Replication  - conn=1686572 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.
[13/Sep/2016:02:15:19 +0200] - ERROR<8277> - Replication  - conn=1686574 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.
[13/Sep/2016:02:15:20 +0200] - ERROR<8277> - Replication  - conn=1686575 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.
[13/Sep/2016:02:15:20 +0200] - ERROR<8277> - Replication  - conn=1686576 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.
[13/Sep/2016:02:15:20 +0200] - ERROR<8277> - Replication  - conn=1686577 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.
[13/Sep/2016:02:15:20 +0200] - ERROR<8277> - Replication  - conn=1686578 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.
[13/Sep/2016:02:15:20 +0200] - ERROR<8277> - Replication  - conn=1686579 op=2 msgId=3 - No such Replica Failed to start Replication Session for suffix o=corp.mycompany.com.

Lorsque je me connecte à l'annuaire via ldapBrowser, j'ai un comportement bizarre :

Après plusieurs tentatives, je redémarre l'annuaire :

[13/Sep/2016:17:18:34 +0200] - Sun-Directory-Server/11.1.1.3.0 B2010.0630.2355 (64-bit) starting up
[13/Sep/2016:17:18:35 +0200] - ERROR<20508> - Backend Database - conn=-1 op=-1 msgId=-1 -  Database under /home5/dsee7/slapd-holding/db/ocorpmycompanycom is corrupt and being marked unavailable. Either re-import or delete the database.
[13/Sep/2016:17:18:35 +0200] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 -  _replica_configure_ruv: failed to create replica ruv tombstone entry (o=corp.mycompany.com); LDAP error - 1
[13/Sep/2016:17:18:35 +0200] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 -  Unable to configure replica o=corp.mycompany.com: 
[13/Sep/2016:17:18:35 +0200] - Listening on all interfaces port 389 for LDAP requests
[13/Sep/2016:17:18:35 +0200] - Listening on all interfaces port 636 for LDAPS requests

On se rend compte qu'il s'agit d'un problème de base de données corrompue. Pour résoudre ce souci, il suffit de supprimer la base, puis de réimporter les données à partir du master.

Attention, ceci est uniquement possible car on a un annuaire maître qui contient les données correctes !

/etc/init.d/slapd stop
cd /home5/dsee7/slapd-holding/
mv db db_corrupt
mkdir db
chown dsuser:dsgroup db
/etc/init.d/slapd start

Note : je fais un rename du répertoire db pour pouvoir revenir en arrière le cas échéant. On pourrait aussi supprimer le répertoire

On regarde dans les logs :

tail /home3/dsee7/slapd-holding/errors
[13/Sep/2016:18:00:37 +0200] - Listening on all interfaces port 636 for LDAPS requests
[13/Sep/2016:18:00:37 +0200] - slapd started. 
[13/Sep/2016:18:00:37 +0200] - INFO: 0 entries in the directory database.
[13/Sep/2016:18:00:37 +0200] - INFO: add:0, modify:0, modrdn:0, search:0, delete:0, compare:0, bind:0 since startup.

A priori, pas de problème, l'annuaire démarre bien ; mais il est vide... Sur le serveur maitre, on utilise un script pour mettre en place la réplication.

#!/bin/sh
MGRPASS="Dir3ct0rym@nag3r"
echo $MGRPASS > /tmp/$$

echo Repm@nag3r > /tmp/pass

echo Creation de l'agrément de réplication
dsconf create-repl-agmt -D "cn=Directory manager" -w /tmp/$$ -p 389 o=corp.mycompany.com  srvautb01.corp.mycompany.com:389

echo Liste des agréments
dsconf list-repl-agmts -D "cn=Directory Manager" -w /tmp/$$

dsconf accord-repl-agmt o=corp.mycompany.com srvautb01.corp.mycompany.com:389

echo Set Bind DN and Password pour la réplication

dsconf set-repl-agmt-prop -D 'cn=Directory Manager' -w /tmp/$$ -p 389  o=corp.mycompany.com srvautb01.corp.mycompany.com:389 auth-bind-dn:"cn=replication manager,cn=replication,cn=config"
dsconf set-repl-agmt-prop -D 'cn=Directory Manager' -w /tmp/$$ -p 389  o=corp.mycompany.com srvautb01.corp.mycompany.com:389 auth-pwd-file:/tmp/pass

echo Initialisation de la réplication 
dsconf init-repl-dest -p 389 -D "cn=Directory manager" -w /tmp/$$ o=corp.mycompany.com srvautb01.corp.mycompany.com:389

echo Statut de l'agrément
dsconf show-repl-agmt-status -D "cn=Directory manager" -w /tmp/$$ o=corp.mycompany.com srvautb01.corp.mycompany.com:389

Sur le serveur esclave, on vérifie dans les logs

[13/Sep/2016:18:01:37 +0200] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 -  _replica_reap_tombstones_main: failed when searching for tombstones in replica o=corp.mycompany.com: No such object. Will try again in 300 seconds.
[13/Sep/2016:18:01:47 +0200] - INFORMATION - NSMMReplicationPlugin - conn=-1 op=-1 msgId=-1 -  multimaster_be_state_change: replica o=corp.mycompany.com is going offline; disabling replication
[13/Sep/2016:18:01:47 +0200] - import ocorpmycompanycom: Index buffering enabled with bucket size 100
[13/Sep/2016:18:01:47 +0200] - import ocorpmycompanycom: Beginning import job...
[13/Sep/2016:18:01:47 +0200] - import ocorpmycompanycom: Starting to process and index entries
[13/Sep/2016:18:02:07 +0200] - import ocorpmycompanycom: Processed 35448 entries -- average rate 1772.5/sec, recent rate 1772.4/sec, hit ratio 0% -- written to database.

Au final, après quelques minutes, l'annuaire esclave est remis à jour.
Il aurait également été possible de le recharger avec un fichier LDIF, puis de démarrer la réplication, pour limiter le trafic réseau entre les 2 machines.

Catégorie: 

Tag: 

Add new comment