On Monday 11 August 2008 17:06:38 Pat Riehecky wrote:
I have gotten two boxes setup in multi master and was loading up my test data when I noticed everything isn't being replicated.
In particular the entire ou=idmap tree is being sent, but not recorded. When I put slapd into debug I can see the system receiving the entire tree, but it doesn't seem to be trying to insert it into the database.
After it pulls the data over I get an error
do_syncrep2: cookie=rid=001,sid=002,csn=20080807221724.788347Z#000000#001#000000 do_syncrep2: rid=001 CSN too old, ignoring 20080807221724.788347Z#000000#001#000000 ldap_msgfree
Which is telling me the entry is being flagged as older than it should be for getting transferred over. Slapd is doing the efficient thing and skipping entries that /should/ be on the other system already. My problem is that it isn't on the other system.
I realize that the replication work is done off of the UUID and CSN, but about 30% of my replication test came back with the CSN too old message.
But, how did you get into this situation?
I am just sort of wondering, is there a way to have openldap say, "Hey, I realize this CSN is old and everything, but this is a dn on the one of us that isn't on the other."
No, because this isn't supposed to happen under normal circumstances. If it does occur, the circumstances are most likely the problem.
Is there something I can do to bulk update the CSNs (fully expecting downtime and horrid performance as loads of needless replications happen)?
No, but you can reset the contextCSN on the server. See the slapd man page.
From my perspective, I would rather have rather horrid performance and a trustworthy mirror than it run like a dream and not have my trust.
Well, you haven't provided any configuration details at all, so we can hardly provide an answer on whether you will be able to trust it in future ...
Regards, Buchan