[Freeipa-users] more replication fun
Janelle
janellenicole80 at gmail.com
Fri May 8 15:22:57 UTC 2015
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 <janellenicole80 at 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 seem to have a
higher CPU load as based on "uptime". Interesting.
Thanks
~J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150508/c3f7630b/attachment.htm>
More information about the Freeipa-users
mailing list