[Freeipa-users] more replication fun

[Rob Crittenden]

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

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.

rob