[389-users] Replication issue

Tue Oct 18 14:57:40 UTC 2011

On 10/18/2011 08:42 AM, Reinhard Nappert wrote:
> ok, I will.
> Do I have to worry about it, though? It looks like replication is 
> working, but I want to make sure ....
No, you don't have to worry about it.
> -Reinhard
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [mailto:rmeggins at redhat.com]
> *Sent:* Tuesday, October 18, 2011 10:39 AM
> *To:* Reinhard Nappert
> *Cc:* General discussion list for the 389 Directory server project.; 
> Marc Sauton
> *Subject:* Re: [389-users] Replication issue
>
> On 10/18/2011 08:13 AM, Reinhard Nappert wrote:
>> Hi Rich,
>> actually just restarting srvA seems to have cleared the replication 
>> issue. It looks like replication is working fine now,
>> but I see now the following error log:
>>
>> [18/Oct/2011:13:09:57 +0000] NSMMReplicationPlugin - 
>> agmt="cn=srvAtosrvB" (srvB:389): changelog iteration code returned a 
>> dummy entry with csn 4e9d7bc2000000080000, skipping ...
>>
>> I think that we can ignore this message, right? But, how can I get rid of this message, since it is generated quite often?
> Unfortunately, you can't get rid of that message.  Please file a bug.
>>
>> Any ideas?
>> -Reinhard
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [mailto:rmeggins at redhat.com]
>> *Sent:* Wednesday, October 12, 2011 4:29 PM
>> *To:* Reinhard Nappert
>> *Cc:* General discussion list for the 389 Directory server project.; 
>> Marc Sauton
>> *Subject:* Re: [389-users] Replication issue
>>
>> On 10/12/2011 02:16 PM, Reinhard Nappert wrote:
>>> Good.
>>> what about the different generation ID message? Is it possible that 
>>> this could be caused by a re-initialize?
>> Yes.
>>> But then, I thought a re-initialize would fix this error, if it occurs.
>> In this case, it should fix this problem.
>>> -Reinhard
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [mailto:rmeggins at redhat.com]
>>> *Sent:* Wednesday, October 12, 2011 4:11 PM
>>> *To:* Reinhard Nappert
>>> *Cc:* General discussion list for the 389 Directory server project.; 
>>> Marc Sauton
>>> *Subject:* Re: [389-users] Replication issue
>>>
>>> On 10/12/2011 02:08 PM, Reinhard Nappert wrote:
>>>> Rich,
>>>> I was thinking about the "Replica has a different generation ID 
>>>> than the local data." error, because I have seen this before. If 
>>>> possible, I want to avoid that I have to go though each box and 
>>>> re-initialize.
>>>> So, you suggest I take let's say D (or A) and re-initialize B with 
>>>> D's data. Then, I would have to re-initialize F from B, right?
>>> Right.
>>>> Let's go a bit further: If I had an agreement from A to F (and vice 
>>>> versa), I would not even have to re-initialize F from B. Is this 
>>>> correct?
>>> Assuming the AtoF agreement is not complaining about "unable to find 
>>> CSN" and "data reload", then yes.
>>>> -Reinhard
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Rich Megginson [mailto:rmeggins at redhat.com]
>>>> *Sent:* Wednesday, October 12, 2011 4:00 PM
>>>> *To:* General discussion list for the 389 Directory server project.
>>>> *Cc:* Reinhard Nappert; Marc Sauton
>>>> *Subject:* Re: [389-users] Replication issue
>>>>
>>>> On 10/11/2011 02:41 PM, Reinhard Nappert wrote:
>>>>> How do I do this manually on server A?
>>>>> The other question is, what kind of impact does it have when I 
>>>>> re-iitialize server B? To be more precise, my replication 
>>>>> environment is more complex than just server A and server B. In 
>>>>> fact, I have a setup like the following:
>>>>> srv C <--> srv A <--> srv B <--> srv D <--> srv C
>>>>>                  /\             /\
>>>>>                  |               |
>>>>>                 \/              \/
>>>>>               srv E          srv F
>>>>> I don't want to end up to re-initialize all boxes in my environment.
>>>> Assuming C and D are up to date and don't have any problems, 
>>>> reinitializing B should affect only B and F.
>>>>> Thanks,
>>>>> -Reinhard
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Marc Sauton [mailto:msauton at redhat.com]
>>>>> *Sent:* Tuesday, October 11, 2011 4:36 PM
>>>>> *To:* General discussion list for the 389 Directory server project.
>>>>> *Cc:* Reinhard Nappert
>>>>> *Subject:* Re: [389-users] Replication issue
>>>>>
>>>>> On 10/11/2011 01:22 PM, Reinhard Nappert wrote:
>>>>>> Hi,
>>>>>> I encountered the following logs in the errors:
>>>>>> [06/Oct/2011:10:11:57 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=srvAtosrvB" (srvB:389): CSN 4e8d804a0000000c0000 not found, we aren't as up to date, or we purged
>>>>>> [06/Oct/2011:10:11:57 +0000] NSMMReplicationPlugin - agmt="cn=srvAtosrvB" (srvB:389): Data required to update replica has been purged. The replica must be reinitialized.
>>>>>> [06/Oct/2011:10:11:57 +0000] NSMMReplicationPlugin - agmt="cn=srvAtosrvB" (srvB:389): Incremental update failed and requires administrator action
>>>>>>   
>>>>>> Does anyone have  an idea, what could have caused this and more importantly, how to fix this?
>>>>>>   
>>>>>> Thanks
>>>>>> -Reinhard
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users at lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>> On server A, read a changelog to manually run the changes on server B.
>>>>> May be tune up nsds5ReplicaPurgeDelay if such errors somehow 
>>>>> appears regularly.
>>>>> Otherwise, like the errors log says, the change was 
>>>>> purged/removed, and replica need a re-init.
>>>>> M.
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users at lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20111018/8f1bec93/attachment.html>