[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: CSN too old, ignoring - and therefore not syncing
That's only important if replicating cn=config though.
On 23/12/2008, Oliver Liebel <oliver@itc.li> wrote:
> Pat Riehecky schrieb:
>> On Tue, 2008-12-23 at 14:33 +0100, Dieter Kluenter wrote:
>>
>>> Pat Riehecky <prieheck@iwu.edu> writes:
>>>
>>>
>>>> Here is the quick and dirty what I am trying to do:
>>>>
>>>> ldap1 and ldap2 are supposed to be in MultiMaster. They are time synced
>>>> to pool.ntp.org and each other (if they drift I would rather they sorta
>>>> drift together, but pool should be keeping that in check).
>>>>
>>>> Right now I am just beating them up to see how 2.4.13 performs. (So far
>>>> VERY well, minus this little problem)
>>>>
>>>> I have a rather small ldif (41 entries) that just wont sync (I'm
>>>> starting small). Debug gives me
>>>>
>>>> ber_scanf fmt (m}) ber:
>>>> ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62
>>>> 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30
>>>> 30 .<rid=001,sid=00
>>>> 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37
>>>> 2,csn=2008122217
>>>> 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30
>>>> 4721.855904Z#000
>>>> 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30
>>>> 000#001#000000
>>>> do_syncrep2:
>>>> cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000
>>>> do_syncrep2: rid=001 CSN too old, ignoring
>>>> 20081222174721.855904Z#000000#001#000000
>>>> ldap_msgfree
>>>>
>>>> I am not exactly sure how it gotten to be "too old." The ldif I am
>>>> importing is not the result of a slapcat or anything that would preserve
>>>> the CSN or UUID attributes (not that syncrepl uses UUID). I am loading
>>>> one single file with ldapadd which, in my understanding, sets up the CSN
>>>> and wouldn't let me import one anyway.
>>>>
>>>> Each server has no entries until I load the one, so there shouldn't be
>>>> any weird stale CSNs causing this. They are "sync'ed" almost instantly
>>>> after the one system is loaded - I just don't have everything.
>>>>
>>>> After a sync:
>>>> ldap1 - slapcat |grep dn: |wc -l = 41
>>>> ldap2 - slapcat |grep dn: |wc -l = 18
>>>>
>>>> Right now I can get them in sync with a slapcat/slapadd, but when the go
>>>> into production I wont be able to say for certain which one is
>>>> authoritative. That is the purpose of multi-master....
>>>>
>>>> OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux 32 bit
>>>>
>>>> Any ideas as to what I can do to stop this from happening?
>>>>
>>> I noticed same behaviour if add a url to serverID and this url is the
>>> local host address, thus pointing to itself.
>>>
>>> serverID 1 192.168.100.23 # this is the local address
>>> serverID 2 192.168.100.24
>>> serverID 3 192.168.100 25
>>>
>>> If I omit the url it works fine.
>>>
>>> -Dieter
>>>
>>
>> Sort of an unrelated question, but why would you do this? I will freely
>> admit a lack of understanding in this area.... Is there a benefit that
>> I have over looked to replicating to one's self or is it more a about
>> maintainable copy pastable config?
>>
>> Pat
>>
>>
> its recommended to use the complete serverid-string (serverid [id + url])
> for every server that is part of your mmr-set. take a look into the admin
> guide:
> http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%20replication
>>
>>
>
>
--
Sent from my mobile device
http://www.suretecsystems.com/services/openldap/