Hi! I guess once you identified the entries out of sync, do a dummy change with ldapmodify the doesn't change a value (i.e. replace an attribute's value with the current value) on a master server. Then watch whether the other servers get updated... If that doesn't work, hunt for the bug...
Regards, Ulrich >>> <[email protected]> schrieb am 18.03.2014 um 13:32 in Nachricht <OFFF997815.9C450A54-ON86257C9F.00448AFA-86257C9F.0044D5F1@LocalDomain>: > Yes all of our servers are sync'd very tightly. In going through all of > our user data and diff'ing it out. I see in most instances the information > is current on two of three servers when there is a discrepancy. So I have > correct data on the servers and back to my original question, is there a > way to make the nodes go through compare and update the data? How can I > force a manual sync between the nodes? > > Thanks, > Eric Speake > Web Systems Administrator > O'Reilly Auto Parts > (417) 862-2674 Ext. 1975 > > > > From: Quanah Gibson-Mount <[email protected]> > To: [email protected] > Cc: [email protected] > Date: 03/17/2014 10:40 PM > Subject: Re: Question on replication files. > Sent by: [email protected] > > > > > > --On March 17, 2014 at 10:02:33 PM -0500 [email protected] wrote: > >> The date on the CSN is tomorrow's date. This was taken from the log >> shortly before 10 PM CST. >> >> do_syncrep2: rid=005 CSN too old, ignoring >> 20140318025932.803264Z#000000#002#000000 >> >> So how can the CSN be too old? > > Well, since the CSN is based off timezone "Z" > (< > http://www.timeanddate.com/library/abbreviations/timezones/military/z.html >>) > that should give you some idea. I imagine you can figure it out from > there. I also assume you keep your systems clocks tightly sync'd, as that > is a documented requirement for syncreplication. > > --Quanah > > > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- > This message has been scanned for viruses and dangerous content, > and is believed to be clean. > Message id: 0A81160141D.AC6CA > > > > > 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.
