On 05/08/2015 05:30 PM, Rob Crittenden wrote:
Janelle wrote:
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to
decode
thread), if you are sure that's not any live replica server behind
this id than just try "cleanallruv.pl -w XXXXX -b "dc=...." -r 9"
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle <janellenicol...@gmail.com>
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove
these?
unable to decode: {replica 9} 553ef80e000100090000
55402c39000000090000
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec64000400160000 553eec64000400160000
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state
seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm
to have a
higher CPU load as based on "uptime". Interesting.
Thanks
~J
See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
hopefully it does, if not maybe Mark can help to get rid of it
It would be nice to know if this style of RUV could be acted on by
ipa-replica-manage. I added this bit as a catch-all so no RUV would be
invisibly skipped if it didn't match the regex I wrote. If this kind
of RUV could indeed still be cleaned it would be nice to know and we
could make that possible.
I think this kind of RUV should never exist, strange enough we have a
hard time to reproduce it in the lab, but out in the real world they
seem to proliferate.
Any help to reproduce is greatly appreciated.
Ludwig
rob
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
