Re: 389ds + modrdn + NSMMReplicationPlugin - Consumer failed to replay change

[Rich Megginson <rmeggins@xxxxxxxxxx>]

On 11/14/2012 05:04 PM, Derek Belcher wrote:

Rich, 

"Not that I know of.  What you will have to do is dump your database to ldif and reload it, then reinitialize all of your replicas and winsync agreements."

Does this mean that I do not have to stop replication? 

So basically I would follow the following steps:

cd /usr/lib64/dirsrv/slapd-my-ldap/

./db2ldif -n userRoot -a /var/tmp/mydb.ldif

Yes

service dirsrv stop

Not required

Delete the database out of the GUI in the Configuration / data / dc=company,dc=net

re-create the database dc=company,dc=net (userRoot)

No

./ldif2db -n userRoot -i /var/tmp/mydb.ldif

You can use ldif2db.pl while the server is running

service dirsrv start

See above

Then right click and reinitialize each sync agreement for the multimasters and consumers

Yes

Also reinitialize the winsync agreement

Yes

Does this sound right? Not sure if I need to delete the database or not, from what i am reading it looks like ldif2db will clobber the existing entries in the database. Is this correct?

Yes.

Thanks -Derek

 

On Wed, Nov 14, 2012 at 1:59 PM, Derek Belcher <jderekbelcher@xxxxxxxxx> wrote:

Thank you for all of your help Rich. I have opened a ticket with fedorahosted.org/389

Ticket # 521

--Derek

On Wed, Nov 14, 2012 at 10:16 AM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:

On 11/14/2012 08:56 AM, Derek Belcher wrote:

This master is bi-directionally syncing with my Active Directory server. On the AD server, I have created a customer filtered view for the time this started, 11/12/2014 between 1pm and 2pm, included all possible windows log sources and I am not seeing any errors. I believe this is due to 389ds, pulls and pushes updates, and AD is not really aware of 389ds.

Correct.

So I am thinking that the modrdn command is not able to make the changes on the AD side? But if 389ds is pushing changes...

It should be, but AD is more restrictive of the types of modrdn and entry move operations it will allow.

What is also interesting is that you can in AD "move" a users to a different DN and 389ds will replicate that change to all of its multi-masters and consumers. Just does not seem to work when you do DN changes on the 389ds side and it pushes to AD.

It should work - does this happen with any modrdn entry move operation?

Is there a way to remove this offending entry in the change log?

Not that I know of.  What you will have to do is dump your database to ldif and reload it, then reinitialize all of your replicas and winsync agreements.

Please file a ticket at https://fedorahosted.org/389 - this is definitely a bug.

On Wed, Nov 14, 2012 at 9:22 AM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:

On 11/14/2012 08:18 AM, Derek Belcher wrote:

Good morning Rich,

# rpm -q 389-ds-base

389-ds-base-1.2.9.14-1.el6_2.2.x86_64

What does it say in the consumer access and errors log for this change replay attempt?

Look in the consumer access log for 50a150a4000000020000, see what the timestamp is, then look in the errors log at around that timestamp.

Thank you

On Wed, Nov 14, 2012 at 8:58 AM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:

On 11/13/2012 07:21 PM, Derek Belcher wrote:

Here is the error message that I am receiving in /var/log/dirsrv/slap-xxxx/errors : 

[13/Nov/2012:20:13:27 -0600] NSMMReplicationPlugin - agmt="cn=sync001" (AD1.company.net:636): Consumer failed to replay change (uniqueid 754ce981-e4d411e1-b828c127-7d7e145e, CSN 50a150a4000000020000): Server is unwilling to perform. Will retry later.

Thanks again for your time.

rpm -q 389-ds-base

On Tue, Nov 13, 2012 at 5:38 PM, Derek Belcher <jderekbelcher@xxxxxxxxx> wrote:

Good evening, 

I am requesting some help from the community, I have an issue that I can not seem to resolve. 

Yesterday I committed a change on a users DN and today I noticed replication issues in my logs. The logs told me the uniqueid # and CSN #

So I used cl-dump to dump the changelog into a file. Here are the results of what I grep'ed out:

[root@ds]# grep "50a150a4000000020000" -B2 -A13 /var/tmp/change.dump 

changetype: modrdn

replgen: 4ff8a4c0000000010000

csn: 50a150a4000000020000

nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e

dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net

newrdn: uid=auser

deleteoldrdn: false

newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net

change::

replace: modifiersname

modifiersname: cn=directory manager

-

replace: modifytimestamp

modifytimestamp: 20121112194019Z

-

So now that I know what entry NSMReplicationPlugin is complaining about, I don't know what to do in order to fix it and get replication back on track.

I really appreciate any help on this matter, Thank you

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users