To: openldap-technical@openldap.org
From: Abdelhamid Meddeb
Sent by: "openldap-technical"
Date: 06/13/2015 12:58AM
Subject: Re: Syncrepl issue with one node

Hi,

In the same situation I've solved the issue by dropping data in the
server 1, and retrieve them from the other servers:

Server 1:
1. Stop
2. Drop data in db (keep the DB_CONFIG file)
3. Start it

Hope this helps.

Cheers.

Le 11/06/2015 15:59, espeake@oreillyauto.com a écrit :
>
>
>
> From: Quanah Gibson-Mount <quanah@zimbra.com>
> To: espeake@oreillyauto.com, openldap-technical@openldap.org
> Date: 06/10/2015 04:09 PM
> Subject: Re: Syncrepl issue with one node
>
>
>
>
> b) Not enough information provided here to go on. Are all server IDs
> unique? Are all syncrepl clauses unique per DB? Personally I've never
> found ntpd particularly good at keeping clocks in sync. I've generally
> resorted to running ntpdate frequently out of cron, particularly for VMs.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
> All of the nodes have unique ID's:
>
> olcServerID: 1 ldap://tn-ldap-a-1.mydomain.com
> olcServerID: 2 ldap://tn-ldap-a-2.mydomain.com
> olcServerID: 3 ldap://tn-ldap-a-3.mydomain.com
>
> Each database has it's one Syncrepl clause 001, 002,& 003 rids sync
> configuraiton changes, and 004,005, & 006 sync the user data.
>
> All configuration changes replicate with no issue. Data changed on servers
> 2&3 replicate between each other, but server 1 gives the CSN too old error.
> If I change user data on node 1 it replicates to nodes 2 & 3 with no
> issues.
>
> I stopped the ntp service on the offending node and ran ntpdate-debian. I
> still get the CSN too old errors in the logs.
>
> Is there a setting in the syncrepl that I can use to expand out the window
> for a CSN "age"? Below is the configuration I have for user data.
>
> olcSyncrepl: {0}rid=004 provider=ldap://tn-ldap-a-1.mtdomain.com
> binddn="uid=admin,dc=mydomain,dc=com" bindmethod=simple credentials=secret
> searchbase="dc=mydomain,dc=com" type=refreshAndPersist retry="5 5 5 +"
> timeout=1
>
> Thank you,
> Eric
>
> This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
>
>

--
*Abdelhamid Meddeb*
http://www.meddeb.net

After being able to fox the timing the issue I noticed that I was still getting the CSN too old error. Upon further review of the logs this would be expected behavior I believe. With 3 nodes in MMR the node that the change is happening on sends out the notice of the change. The other servers pick this change up and apply it. Then when node 2 advertises it has a change from node 3 to node 1, node 1 responds that with the CSN too old to let that node know that it already has the change. At least I hope that is what it's doing. Right now all modified records are being replicated to all of the nodes.

Thank you,

Eric