On Thu, Jul 16, 2015 at 10:32:59AM +0200, Ludwig Krispenz wrote:
> Thank you for the data, I think I understand now what is going on.
> In the error logs we see only message like (from my test env):
> [16/Jul/2015:10:12:40 +0200] NSMMReplicationPlugin - agmt="cn=100-300"
> (localhost:9759): replay_update: modifys operation (dn="dc=example,dc=com"
> csn=55a82a29000100640000) not sent - empty
> [16/Jul/2015:10:12:40 +0200] NSMMReplicationPlugin - agmt="cn=100-300"
> (localhost:9759): replay_update: Consumer successfully sent operation with
> csn 55a82a29000100640000
> [16/Jul/2015:10:12:40 +0200] NSMMReplicationPlugin - agmt="cn=100-300"
> (localhost:9759): Skipping update operation with no message_id (uniqueid
> 7507cb26-e8ac11e2-b2898005-8430f734, CSN 55a82a29000100640000):
> This happens if fractional replication is configured as IPA does and the
> changes affect only attributes which will NOT be replicated. So teh local
> RUV will be updated, but since no change is really sent, the consumer RUV is
> not updated and replciation will always set off from an very old starting
> csn. It is a rare scenario where a server receives only mods which are not
> replicated.
> I have opened a ticket for this: https://fedorahosted.org/389/ticket/48225
> As  a workaround can you try to apply a mod on m14-26 which will not be
> stripped, either create a dummy user or add a description attribute to an
> existing object. Repliciation will once again iterate thru all the changes
> (which can take a while), but then should replay this latest change and
> define a new offset

Excellent. I can confirm your workaround fixed the issue. I updated a
users email address (on m14-26) and the load came down back to normal
within a few minutes. 

Thanks very much for all your help debugging this.



> Regards,
> Ludwig

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to