Emmanuel Lecharny wrote:
Quanah Gibson-Mount wrote:
--On Thursday, January 15, 2009 1:28 AM +0100 Emmanuel Lecharny
<[email protected]> wrote:
The queue will be limited in size, obviously. I can even be empty, all
the modification being stored on disk.
However, we don't necessarily have to keep a track of pending modify for
disconnect replicas, as it's easy to know which entries has not been
replicated since the last time the replica was on. The connecting
replica
could send the last entryCSN received, and then a search can be done on
the server for every CSN with a higher CSN. Then you don't need to keep
any modification on disk, as they are already stored in the DiT.
Sounds a lot like syncrepl. ;)
yeah, this is what I realized :)
That search doesn't sound like it handles deletes though, which is
always a PITA.
it does. Any modification done somewhere which might impact the elements
you are supposed to get back from this persistent search will be send
back to the recipient. The way Mitosis works atm is to keep the deleted
entries in the DiT with a added attribute telling if the entry has been
deleted, so we keep them in the DiT ( but not available for standard
operations) until all the replicas has been updated. So a disconnected
replicas which reconnect will get the deleted entry info when it connect
back.
Tombstones. Yuck. If you're leaving the entry in the DIT, what do you do if an
entry with the same DN is added again? Just resurrect the deleted entry and
replace its values with the newly added attributes? Will anyone care if a
replica never sees the delete, in this case?
How to handle the real deletion is the problem, as we have to keep a
state of each replica...
Don't leave the tombstone in the original location, move it to a reserved area
of the DIT. That will make housekeeping a lot simpler later; you can just
purge entries older than X under that particular branch rather than having to
search the entire DIT for cleanup targets.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
