[Freeipa-users] more replication fun

[Ludwig Krispenz]

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 <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 
>> 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
>