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.