[389-devel] requirements for replica removal robustness
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
In the short term, we need to identify exactly what happens when a replica is deleted - what gets replicated, how the RUV is handled on the supplier and consumer, what changelog db interactions there are, what the effects on replication are, and how to recover from this situation.
In the long term, we need to make replication much more resilient and robust despite replica removal.
One solution is to somehow "mark" the RUV element e.g. use a port number of 0 or some other "magic" value, or use a special max CSN. The goal here is to do something that won't break older replicas - users must be able to have a mixed old and new replication topology - solutions that begin with "upgrade all servers simultaneously" are non-starters.
Longer term, we should investigate if it is possible to "replicate" the CLEANRUV operation. Or allow explicit operations on the RUV tombstone entry that could be replicated. We could change the RUV or RUV element format to add a version field, and add a field that explicitly marks an RUV element as deleted. We already have code in the replication supplier to get the "capabilities" of the consumer, we would just need to extend this, to know if the consumer understands "versioned" RUVs.
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Fedora Directory Announce] [Older Fedora Users Mail] [Home] [Fedora Advisory Board] [Fedora Security] [Fedora Maintainers] [Fedora Devel Java] [Fedora Legacy] [Fedora Desktop] [iPod Nano] [ATA RAID] [Fedora Bible] [Fedora Marketing] [Fedora Mentors] [Fedora Package Review] [Fedora Art] [Fedora Music] [Fedora Packaging] [Centos] [Fedora SELinux] [Tux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools] [Fedora Art] [Fedora Docs]