[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Antw: Re: Question on replication files.
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
>>> <espeake@oreillyauto.com> 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 <quanah@zimbra.com>
> To: espeake@oreillyauto.com
> Cc: openldap-technical@openldap.org
> Date: 03/17/2014 10:40 PM
> Subject: Re: Question on replication files.
> Sent by: openldap-technical-bounces@OpenLDAP.org
>
>
>
>
>
> --On March 17, 2014 at 10:02:33 PM -0500 espeake@oreillyauto.com 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.