Hi, I was discussing with some staff here in BNE about replication. It seems a common case is that admins with 2 or 3 servers in MMR (both DS and IPA) will do this: * Setup all three masters A, B, C (replica id 1,2,3 respectively) * Run them for a while in replication * Remove C from replication * Delete data, change the system * Re-add C with the same replica id. Supposedly this can cause duplicate RUV entries for id 3 in masters A and B. Of course, this means that replication has all kinds of insane issues at this point .... On one hand, this is the admins fault. But on the other, we should handle this. Consider an admin who re-uses an IPA replica setup file, without running CLEANALLRUV So, an have some idea for this. Any change to a replication agreement, should trigger a CLEANALLRUV, before we start the agreement. This means on our local master we have removed the bad RUV first, then we can add the RUV of the newly added master when needed .... What do you think? I think that we must handle this better, and it should be a non-issue to admins. We can't prevent an admin from intentionally adding duplicate ID's to the topology though. So making it so that the ID's are not admin controlled would prevent this, but I haven't any good ideas about this (yet) -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
