[Fedora-directory-users] Replication - consumer failed to replay change

[Richard Megginson]

Kevin M. Myer wrote:

> Quoting Richard Megginson <rmeggins at redhat.com>:
>
>> Kevin M. Myer wrote:
>>
>>> Quoting David Boreham <david_list at boreham.org>:
>>>
>>>> Try looking in the access and error logs on the replica server (the 
>>>> server that is receiving this update).
>>>> That should tell us which operation is failing. Exactly what is 
>>>> going on I'm not sure, I've not seen a
>>>> problem like this before. Perhaps someone else on the list has.
>>>
>>>
>>>
>>> Here's the action its trying to perform:
>>>
>>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=3 EXT 
>>> oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session"
>>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=3 RESULT err=0 tag=120 
>>> nentries=0 etime=0
>>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=4 DEL 
>>> dn="uid=<username>,ou=people,dc=base"
>>> [16/Dec/2005:09:06:16 -0500] conn=900959 op=4 RESULT err=1 tag=107 
>>> nentries=0 etime=0 csn=43a2c9d8000000010000
>>> [16/Dec/2005:09:06:18 -0500] conn=900959 op=5 EXT 
>>> oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session"
>>>
>>> The replication to the slave (garnet) did occur properly for the 
>>> account that was being deleted.
>>
>>
>> Is this the access log from one of the masters?
>
>
> Yes, its from the master that the changes were sent to.
>
>>> Its also not inhibiting other changes from occuring in the the same 
>>> replication session.  I just made a minor modification to my account 
>>> and it replicated while the deletion of the account giving errors 
>>> failed.  I restarted the server that was receiving the changes, and 
>>> now the deletion operation that was failing isn't occuring at all :/ 
>>>  So I guess I'll just manually delete the account, since the one 
>>> master seems to be convinced that the change went through.
>>
>>
>> So after the restart, everything is ok?
>
>
> Unfortunately, no.  What has stopped is the attempt to do the 
> replication from the master where the initial change was committed.  
> Further, if I try to manually delete the entry from the master the 
> changes were to be replicated to, I get the same operation error.
>
> [17/Dec/2005:14:07:41 -0500] conn=471 fd=210 slot=210 connection from 
> XX.XX.XX.XX to XX.XX.XX.XX
> [17/Dec/2005:14:07:41 -0500] conn=471 op=0 BIND dn="cn=Directory 
> Manager" method=128 version=3
> [17/Dec/2005:14:07:41 -0500] conn=471 op=0 RESULT err=0 tag=97 
> nentries=0 etime=0 dn="cn=directory manager"
> [17/Dec/2005:14:07:41 -0500] conn=471 op=1 DEL 
> dn="uid=<username>,ou=People,dc=base"
> [17/Dec/2005:14:07:41 -0500] conn=471 op=1 RESULT err=1 tag=107 
> nentries=0 etime=0 csn=43a461fe000000650000
> [17/Dec/2005:14:07:41 -0500] conn=471 op=2 UNBIND
> [17/Dec/2005:14:07:41 -0500] conn=471 op=2 fd=210 closed - U1
>
> Now to the best of my knowledge, this server has not gone down 
> uncleanly, and its only this one entry that is causing problems.  So 
> ideas on what to try next, or how I might fix it?

I think you should just re-initialize it e.g. reinit this master from 
the other master.

>
> Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20051219/e3fdea4e/attachment.bin>