|
Hi German, you are right that IPA is on the safe side, they maintain the last used replicaID and when creating a server instance only a higher replicaid is used, also when a server is removed, the removal triggers a cleanallruv, either from the script or by the topology plugin (>4.3). This is because in IPA all server instance creation and removal is managed by IPA cammands. This framework is not there by default for "admion managed" DS deployments, and that's what William wants to get improved. William, I'm not sure that the scenario you describe is really so bad as you think. If a server is removed and the RID is not cleaned, it's component remains in the RUV, but this is just an overhead in examining ruvs, but should not block replication to continue. If a new server with the old, removed replicaID is installed, the ruv component should be reused, the URL replaced, and replication continue as if there haven't been updates for this replica ID for a long time. I'm saying "should", since there mioght be some cases where the changelog was purged and an anchor csn for the old/new replicaid cannot be found. So we need to do some tests and it would be good to make this safe. One option would be to maintain already used replicaids, so at the init of a new server there could not only be a check for the same database generation, but also for a valid RUV I think it is difficult to find a trigger for an automated cleanallruv, we would have to maintain something like a topology view of the deployment, like the topology plugin in IPA does But it is definitely worth to think about solutions for thi sproblem Ludwig On 06/13/2016 10:21 AM, German Parente
wrote:
-- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander |
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
